Почему я все еще получаю взаимоблокировки даже после установки действительно высокого значения wsrep_retry_autocommit?

Question

У меня есть кластер из 3 серверов percona xtradb 5.5.34-55, и, поскольку все они доступны для записи, я получаю ошибки взаимоблокировки при любой существенной нагрузке. Увеличение wsrep_retry_autocommit переменная помогла с этим в некоторой степени, но ER_LOCK_DEADLOCK не исчез полностью Итак, я попытался установить wsrep_retry_autocommit до 10000 (кажется, максимум), думая, что это будет делать некоторые запросы очень медленно, но ни один из них не потерпит неудачу с ER_LOCK_DEADLOCK:

mysql-shm -ss -e 'show global variables like "%wsrep_retry_auto%"'
wsrep_retry_autocommit  10000

------------------------
LATEST DETECTED DEADLOCK
------------------------
140414 10:29:23
*** (1) TRANSACTION:
TRANSACTION 72D8, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s), undo log entries 1
MySQL thread id 34, OS thread handle 0x7f11840d4700, query id 982 localhost shm update
REPLACE INTO metric(host, name, userid, sampleid, type, priority) VALUES
('localhost','cpu-3/cpu-nice',8,0,0,0),('localhost','cpu-3/cpu-system',8,0,0,0),
('localhost','cpu-3/cpu-idle',8,0,0,0),('localhost','cpu-3/cpu-wait',8,0,0,0),
('localhost','cpu-3/cpu-interrupt',8,0,0,0),('localhost','cpu-3/cpu-softirq',8,0,0,0),
('localhost','cpu-3/cpu-steal',8,0,0,0),('localhost','cpu-4/cpu-user',8,0,0,0),
('localhost','cpu-4/cpu-nice',8,0,0,0),('localhost','cpu-4/cpu-system',8,0,0,0),
('localhost','cpu-4/cpu-idle',8,0,0,0),('localhost','cpu-4/cpu-wait',8,0,0,0),
('localhost','cpu-4/cpu-interrupt',8,0,0,0),('localhost','cpu-4/cpu-softirq',8,0,0,0),
('localhost','cpu-4/cpu-steal',8,0,0,0)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 344 n bits 488 index `unique-metric` of
table `shm`.`metric` trx id 72D8 lock_mode X waiting
*** (2) TRANSACTION:
TRANSACTION 72D7, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
7 lock struct(s), heap size 3112, 141 row lock(s), undo log entries 40
MySQL thread id 50, OS thread handle 0x7f1184115700, query id 980 localhost shm update
REPLACE INTO metric(host, name, userid, sampleid, type, priority) VALUES
('localhost','cpu-3/cpu-nice',8,0,0,0),('localhost','cpu-3/cpu-system',8,0,0,0),
('localhost','cpu-3/cpu-idle',8,0,0,0),('localhost','cpu-3/cpu-wait',8,0,0,0),
('localhost','cpu-3/cpu-interrupt',8,0,0,0),('localhost','cpu-3/cpu-softirq',8,0,0,0),
('localhost','cpu-3/cpu-steal',8,0,0,0),('localhost','cpu-4/cpu-user',8,0,0,0),
('localhost','cpu-4/cpu-nice',8,0,0,0),('localhost','cpu-4/cpu-system',8,0,0,0),
('localhost','cpu-4/cpu-idle',8,0,0,0),('localhost','cpu-4/cpu-wait',8,0,0,0),
('localhost','cpu-4/cpu-interrupt',8,0,0,0),('localhost','cpu-4/cpu-softirq',8,0,0,0),
('localhost','cpu-4/cpu-steal',8,0,0,0),('localhost','cpu-3/cpu-nice',8,0,0,0),
('localhost','cpu-3/cpu-system',8,0,0,0),('localhost','cpu-3/cpu-idle',8,0,0,0),
('localhost','cpu-3/cpu-wait',8,0,0,0),('localhost','cpu-3/cpu-interrupt',8,0,0,0),
('localhost','cpu-3/cpu-softirq',8,0,0,0),('localhost'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 344 n bits 488 index `unique-metric` of table 
`shm`.`metric` trx id 72D7 lock_mode X
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 344 n bits 504 index `unique-metric` of table 
`shm`.`metric` trx id 72D7 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (1)

Разве это не должно быть повторено вместо этого? Есть ли способ проверить, действительно ли Percona повторил запрос 10000 раз?

Answer 1

У меня нет точного ответа на ваш вопрос, но для любых нагрузок с интенсивной записью (если вы пытаетесь вставить те же данные, что и проклятый Drupal), то возникают взаимные блокировки, и единственное решение для меня (все еще жду, чтобы подтвердить это Решение 100% OK)- это использование haproxy перед узлами galera и определение первого узла (определение бэкенда haproxy), который будет использоваться, и двух других узлов, которые будут использоваться в качестве резервной копии.

Таким образом весь трафик mysql будет передаваться от клиентов через haproxy к одному узлу galera, и в случае сбоя этого узла будет использоваться какой-то другой узел.

Надеюсь, это поможет... Андрия

Answer 2

В вашем ответе проблема масштабируемости, так как мы находимся в кластере, но использование только одного узла - это очень плохое использование ресурсов. Таким образом, альтернативы будут, вы можете использовать любой loadbalancer, если его haproxy вы можете создать 2 слушателя на двух портах, скажем, 3306 и 3305; тогда скажи
lind bind для 3306 получает все запросы на запись от приложения, его бэкэнд будет иметь узел 1, а затем узел 2 и узел 3 в качестве резервной копии; В списке привязки к 3305 будут все запросы на чтение из приложения, в бэкэнде которого все узлы будут указаны как обычно. Таким образом, нет масштабируемого чтения и записи с ограниченной масштабируемостью, где тупиковая ситуация может быть значительно уменьшена.