[openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

Florian Engelmann florian.engelmann at everyware.ch
Tue Oct 9 10:34:51 UTC 2018

Am 10/9/18 um 11:41 AM schrieb Jay Pipes:
> On 10/09/2018 04:34 AM, Christian Berendt wrote:
>>> On 8. Oct 2018, at 19:48, Jay Pipes <jaypipes at gmail.com> wrote:
>>> Why not send all read and all write traffic to a single haproxy 
>>> endpoint and just have haproxy spread all traffic across each Galera 
>>> node?
>>> Galera, after all, is multi-master synchronous replication... so it 
>>> shouldn't matter which node in the Galera cluster you send traffic to.
>> Probably because of MySQL deadlocks in Galera:
>> —snip—
>> Galera cluster has known limitations, one of them is that it uses 
>> cluster-wide optimistic locking. This may cause some transactions to 
>> rollback. With an increasing number of writeable masters, the 
>> transaction rollback rate may increase, especially if there is write 
>> contention on the same dataset. It is of course possible to retry the 
>> transaction and perhaps it will COMMIT in the retries, but this will 
>> add to the transaction latency. However, some designs are deadlock 
>> prone, e.g sequence tables.
>> —snap—
>> Source: 
>> https://severalnines.com/resources/tutorials/mysql-load-balancing-haproxy-tutorial 
> Have you seen the above in production?

Yes of course. Just depends on the application and how high the workload 

Please read about deadloks and nova in the following report by Intel:


If just Nova is affected we could also create an additional HAProxy 
listener using all Galera nodes with round-robin for all other services?

Anyway - proxySQL would be a great extension.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5210 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20181009/e208d4ec/attachment.bin>

More information about the OpenStack-dev mailing list