[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