[openstack-dev] [Keystone] Cockroachdb for Keystone Multi-master
agrebennikov at mirantis.com
Thu Jun 1 20:46:29 UTC 2017
We had a very similar conversation multiple times with Keystone cores
Geo-rep Galera was suggested first and it was immediately declined (one of
the reasons was the case of complete corruption of Keystone DB everywhere
in case of accidental table corrupt in one site) by me as well as current
Right after that I was told many times that federation is the only right
way to go nowadays.
Is this statement still valid?
On Thu, Jun 1, 2017 at 12:51 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 05/31/2017 11:06 PM, Mike Bayer wrote:
>> I'd also throw in, there's lots of versions of Galera with different
>> bugfixes / improvements as we go along, not to mention configuration
>> settings.... if Jay observes it working great on a distributed cluster and
>> Clint observes it working terribly, it could be that these were not the
>> same Galera versions being used.
> Agreed. The version of Galera we were using IIRC was Percona XtraDB
> Cluster 5.6. And, remember that the wsrep_provider_options do make a big
> difference, especially in WAN-replicated setups.
> We also increased the tolerance settings for network disruption so that
> the cluster operated without hiccups over the WAN. I think the
> wsrep_provider_options setting was evs.inactive_timeout=PT30Sm
> evs.suspect_timeout=PT15S, and evs.join_retrans_period=PT1S.
> Also, regardless of settings, if your network sucks, none of these
> distributed databases are going to be fun to operate :)
> At AT&T, we jumped through a lot of hoops to ensure multiple levels of
> redundancy and high performance for the network links inside and between
> datacenters. It really makes a huge difference when your network rocks.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Principal Deployment Engineer
Mirantis Inc, Austin TX
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev