PDO + mysql — & gt; случайные тупики, требующие сброса соединения

Прошу прощения за длинный текст, я думаю, что страдаю ошибкой в ​​базе данных mysql или внутри PDO / mysqli и пытаюсь объяснить ситуацию настолько хорошо, насколько могу.
Я намеренно не публиковал код, это не имеет отношения к делу.

У меня довольно занятый сервер MySQL с 1000 запросов в секунду в среднем и около 1 миллиона соединений в день.

Я запускаю MySQL 5.5.42 и PHP 5.6.33
Я хотел бы обновить, но это производственная среда, я не хочу рисковать во время обновления.

Я использую Innodb в качестве движка базы данных (50 ГБ памяти для буферов)

Теперь моя проблема в том, что у меня есть случайные, повторяющиеся тупики без параллельных запросов и без использования транзакций.
Это влияет на несколько таблиц и скриптов.

Блокировки случаются во время вставки и обновления.
Я сузил некоторые локации и из теории mysql не может быть тупиков ни в одном из случаев.
Не используются транзакции, простые INSERT или UPDATE для одного (первичного) идентификатора в предложении WHERE.
Я понимаю, как могут возникать тупики, и ни один из случаев, когда я их получаю, не подвергается риску.

Я отладил эту проблему, так как это иногда приводит к полной остановке моих сценариев.
Я попытался сделать sleep () после Deadlock и просто вставить / обновить снова, однако я могу сделать это тысячу раз, и это не сработает, оно навсегда заблокируется.
Если я сделаю это в то же время на улице в новой сессии MySQL, запрос работает!

Единственное решение этой проблемы — обнаружить взаимоблокировки, закрыть соединение PDO ($ pdo = null;), повторно подключиться к базе данных и повторить запрос.

Хотя это работает, довольно сложно внедрять эту логику везде.

Я просматривал Интернет, я не мог найти ничего похожего на мои упомянутые проблемы. Все тупики, как правило, правильные с понятной причиной.

Вторая связанная проблема:
Этот более редкий, но, кажется, связанный, это неверная ошибка DUPLICATE KEY на INSERT. Это происходит в одном из миллиона вкладышей, так что это действительно редко.
Но в этих случаях только переподключение PDO решает проблему.

Я хотел бы получить некоторую информацию, может быть, кто-то понимает проблему или решил ее без взлома, как переподключение.

Подводя итог: никакие транзакции вообще не используются (автоматическая фиксация по умолчанию), НЕТ одновременных запросов, используется innodb, простые одиночные запросы INSERT или UPDATE с WHERE id = 1234;
Взаимные блокировки влияют только на случайные строки.

Кажется, что это ошибка в базе данных mysql, возможно, некоторые повреждения сессии.

Вот тупиковые логи:
Первая таблица тоже имеет проблему взаимоблокировки один раз в час.
Я мог бы отследить его до некоторых очень простых запросов ОБНОВЛЕНИЯ, которые выполняются раз в час, для выполнения которых требуется около 0,05 секунды.
И другой журнал ошибок с сотнями записей, без каких-либо подробностей.

    RECORD LOCKS space id 1983 page no 32800 n bits 1616 index start of table `db`.`jobs` trx id 2083002285 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 859 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259d6; asc   Y ;;

Record lock, heap no 860 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259d7; asc   Y ;;

Record lock, heap no 861 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259d8; asc   Y ;;

Record lock, heap no 862 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259d9; asc   Y ;;

Record lock, heap no 863 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259da; asc   Y ;;

Record lock, heap no 864 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259db; asc   Y ;;

Record lock, heap no 865 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259dc; asc   Y ;;

Record lock, heap no 866 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259dd; asc   Y ;;

Record lock, heap no 867 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259de; asc   Y ;;

Record lock, heap no 868 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc  ;;
1: len 4; hex 800259df; asc   Y ;;

Innodb Статус:

InnoDB
=====================================
2018-02-07 17:21:27 0x7f5b0d32d700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 22 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 64463 srv_active, 0 srv_shutdown, 21 srv_idle
srv_master_thread log flush and writes: 64472
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 2040099
OS WAIT ARRAY INFO: signal count 3213946
RW-shared spins 0, rounds 2165320, OS waits 554744
RW-excl spins 0, rounds 40616534, OS waits 873123
RW-sx spins 532360, rounds 9261545, OS waits 97422
Spin rounds per wait: 2165320.00 RW-shared, 40616534.00 RW-excl, 17.40 RW-sx
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-02-07 17:15:05 0x7f5af7924700
*** (1) TRANSACTION:
TRANSACTION 2109880254, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 147614, OS thread handle 140029031933696, query id 36166552 localhost website Searching rows for update
UPDATE task SET result_delivered=1, result_data='DISABLED', result_gathered=1 WHERE result_data is NULL AND (assigned_counter >= 4 OR other_counter> 1)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 591 page no 20571555 n bits 88 index PRIMARY of table `db`.`task` trx id 2109880254 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 24; compact format; info bits 0
0: len 4; hex 8611338d; asc 3 ;;
1: len 6; hex 00007dc237bc; asc } 7 ;;
2: len 7; hex 3300070012073a; asc 3 :;;
3: len 4; hex 800085dc; asc ;;
4: len 30; hex 226973742064617320776569c39f652042726175746b6c656964206e6963; asc "ist das wei e nic; (total 46 bytes);
5: len 7; hex 44656661756c74; asc Default;;
6: len 2; hex 656e; asc en;;
7: len 0; hex ; asc ;;
8: len 2; hex 8032; asc 2;;
9: len 1; hex b2; asc ;;
10: len 2; hex 8001; asc ;;
11: len 4; hex 80030ea7; asc ;;
12: len 19; hex 692d3036626437323830373833326335656230; asc i-06bd72807832c5eb0;;
13: SQL NULL;
14: len 30; hex 7b22636f756e745f6f7267616e6963223a31332c22636f756e745f637265; asc {"count_organic":13,"count_cre; (total 5060 bytes);
15: len 4; hex 5a7b3419; asc Z{4 ;;
16: len 1; hex 81; asc ;;
17: len 1; hex 80; asc ;;
18: len 1; hex 80; asc ;;
19: len 3; hex 80000d; asc ;;
20: len 3; hex 800000; asc ;;
21: len 1; hex 80; asc ;;
22: len 1; hex 81; asc ;;
23: len 1; hex 80; asc ;;

*** (2) TRANSACTION:
TRANSACTION 2109880252, ACTIVE 0 sec updating or deleting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 146705, OS thread handle 140028677342976, query id 36166547 localhost ss updating
UPDATE task SET result_count_creative='0'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 591 page no 20571555 n bits 88 index PRIMARY of table `db`.`task` trx id 2109880252 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: n_fields 24; compact format; info bits 0
0: len 4; hex 8611338d; asc 3 ;;
1: len 6; hex 00007dc237bc; asc } 7 ;;
2: len 7; hex 3300070012073a; asc 3 :;;
3: len 4; hex 800085dc; asc ;;
4: len 30; hex 226973742064617320776569c39f652042726175746b6c656964206e6963; asc "ist das wei e nic; (total 46 bytes);
5: len 7; hex 44656661756c74; asc Default;;
6: len 2; hex 656e; asc en;;
7: len 0; hex ; asc ;;
8: len 2; hex 8032; asc 2;;
9: len 1; hex b2; asc ;;
10: len 2; hex 8001; asc ;;
11: len 4; hex 80030ea7; asc ;;
12: len 19; hex 692d3036626437323830373833326335656230; asc i-06bd72807832c5eb0;;
13: SQL NULL;
14: len 30; hex 7b22636f756e745f6f7267616e6963223a31332c22636f756e745f637265; asc {"count_organic":13,"count_cre; (total 5060 bytes);
15: len 4; hex 5a7b3419; asc Z{4 ;;
16: len 1; hex 81; asc ;;
17: len 1; hex 80; asc ;;
18: len 1; hex 80; asc ;;\

0

Решение

ОБНОВЛЕНИЕ задачи SET result_count_creative = ‘0’

имеет возможность добавить в таблицу индекс для result_count_creative и изменить свой запрос на:

ОБНОВЛЕНИЕ задачи SET result_count_creative = ‘0’ WHERE result_count_creative> ‘0’

EXPLAIN EXTENDED SELECT SQL_NO_CACHE ….. должен показывать SCAN, использованный при первом обновлении, и не SCAN при втором обновлении. Избегу многих блокировок строк.
ПОКАЗАТЬ ПРЕДУПРЕЖДЕНИЯ;

сразу в сеансе покажет вам, как оптимизатор переставляет запросы.

Это минимизирует только часть ваших тупиков. Еще нужно вчера запросить SCT и SHIF, когда у вас будет время, пожалуйста.

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]