[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 
gets.

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

http://galeracluster.com/wp-content/uploads/2017/06/performance_analysis_and_tuning_in_china_mobiles_openstack_production_cloud_2.pdf

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