[Openstack-operators] Galera setup testing

Kevin Benton blak111 at gmail.com
Tue Dec 8 22:47:23 UTC 2015


Probably, but it's not something currently tested in the gate so I don't
know how we would prevent regressions.

On Mon, Dec 7, 2015 at 6:56 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> Awsome news. Should there be a tag added for gallera multimaster safe to
> let us ops know about these things?
>
> Thanks,
> Kevin
>
> ------------------------------
> *From:* Kevin Benton
> *Sent:* Monday, December 07, 2015 6:08:12 PM
> *To:* Matteo Panella
> *Cc:* OpenStack Operators
> *Subject:* Re: [Openstack-operators] Galera setup testing
>
> Neutron has protection against these now as of liberty with API level
> retry operations so this shouldn't be a problem for neutron any more.
> On Dec 7, 2015 4:06 PM, "Matteo Panella" <matteo.panella at cnaf.infn.it>
> wrote:
>
>> On 2015-12-07 22:45, James Dempsey wrote:
>>
>>> +1 for designating one node as primary.  This helped us reduce some
>>> deadlocks that we were seeing when balancing sessions between DB hosts.
>>>
>>
>> Keystone most likely won't be affected by writeset certification failures,
>> but other services (especially Neutron) are going to be hit by one sooner
>> or later.
>>
>> Unfortunately, Galera doesn't take very kindly "SELECT ... FOR UPDATE", so
>> you can't really do proper load balancing (aside from designating a
>> different node
>> as master in multiple listen stanzas, each one for a different set of
>> services).
>>
>> Regards,
>> --
>> Matteo Panella
>> INFN CNAF
>> Via Ranzani 13/2 c - 40127 Bologna, Italy
>> Phone: +39 051 609 2903
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151208/2794f544/attachment.html>


More information about the OpenStack-operators mailing list