MySQL coincé sur "WSREP: initier la réplication pour l'écriture SET (-1)"

Question

J'ai couru dans une situation avec MySQL récemment que je n'avais pas vu auparavant. Nous avons un cluster de Percona avec 3 nœuds. Le maître a cessé de traiter les requêtes et le PHP FPM que l'hôte de l'hôte est devenu insensible. Quand j'ai vérifié SHOW PROCESSLIST, les processus MySQL ont été bloqués dans l'état: wsrep: initiating replication for write set (-1)

C'était le cas sur le primaire, où PHP dirigeait toutes les requêtes, ainsi que l'un des deux secondaires. Voici la sortie que j'ai vue de SHOW PROCESSLIST:

mysql> show processlist; +-------+-------------+--------------------+-----------------+---------+-------+--------------------------------------------------------+--------------------------------------------------------------------------------------+-----------+---------------+ | Id | User | Host | db | Command | Time | State | Info | Rows_sent | Rows_examined | +-------+-------------+--------------------+-----------------+---------+-------+--------------------------------------------------------+--------------------------------------------------------------------------------------+-----------+---------------+ | 1 | system user | | NULL | Sleep | 2171 | wsrep: committing write set (542480920) | NULL | 0 | 0 | | 2 | system user | | NULL | Sleep | 17169 | wsrep: aborter idle | NULL | 0 | 0 | | 4 | system user | | NULL | Sleep | 3250 | wsrep: deleting row for write-set (542480919) | NULL | 0 | 0 | | 46944 | $user1 | 172.24.62.92:54004 | $user1_db1 | Query | 2158 | wsrep: initiating pre-commit for write set (542481004) | delete from $table where $col < '$val' | 0 | 1 | | 47126 | $user1 | 172.24.62.92:54745 | $user1_db2 | Query | 2096 | wsrep: initiating replication for write set (-1) | update $table2 set $col = current_timestamp where $col2 = 393 and $col3 = 176935 | 0 | 1 | | 47155 | $user1 | 172.24.62.92:54841 | $user1_db3 | Query | 2089 | wsrep: initiating replication for write set (-1) | UPDATE $table SET $col5 = 'something' WHERE $somecol = '$someval' | 0 | 1 | | 47416 | $user1 | 172.24.62.92:55891 | $user1_db3 | Query | 1950 | wsrep: initiating replication for write set (-1) | UPDATE $table SET $col5 = 'something' WHERE $somecol = 's' | 0 | 1 | | 47576 | $user1 | 172.24.62.92:56493 | $user1_db3 | Query | 1849 | wsrep: initiating replication for write set (-1) | INSERT INTO $table3 ($column6, $column7, $column8, $column9, $column10 ... | 0 | 0 | | 47654 | $user1 | 172.24.62.92:56808 | $user1_db2 | Query | 1924 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 43625 a | 0 | 1 | | 48036 | $user1 | 172.24.62.92:58343 | $user1_db2 | Query | 1795 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 248528 | 0 | 1 | | 48936 | $user1 | 172.24.62.92:61929 | $user1_db2 | Query | 1495 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 156001 | 0 | 1 | | 48952 | $user1 | 172.24.62.92:61982 | $user1_db2 | Query | 1490 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 205495 | 0 | 1 | | 49497 | $user1 | 172.24.62.92:64167 | $user1_db2 | Query | 1306 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 234457 | 0 | 1 | | 49510 | $user1 | 172.24.62.92:64218 | $user1_db2 | Query | 1302 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 209489 | 0 | 1 | | 49839 | $user1 | 172.24.62.92:65534 | $user1_db2 | Query | 1192 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 70958 a | 0 | 1 | | 49970 | $user1 | 172.24.62.92:1539 | $user1_db2 | Query | 1096 | wsrep: initiating replication for write set (-1) | update $table set $col11 = $col11 + 1 where id = $val | 0 | 1 | | 50292 | $user1 | 172.24.62.92:2819 | $user1_db2 | Query | 1041 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 193078 | 0 | 1 | | 50398 | $user1 | 172.24.62.92:3240 | $user1_db2 | Query | 1006 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 242842 | 0 | 1 | | 51120 | $user1 | 172.24.62.92:6135 | $user1_db2 | Query | 763 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 173382 | 0 | 1 | | 51453 | $user1 | 172.24.62.92:7456 | $user1_db1 | Query | 653 | wsrep: initiating replication for write set (-1) | delete from $table5 where expiry < 1496379436 | 0 | 2 | | 51460 | $user1 | 172.24.62.92:7475 | $user1_db1 | Query | 651 | wsrep: initiating replication for write set (-1) | insert into $table5 values ('... | 0 | 0 | | 51504 | $user1 | 172.24.62.92:7646 | $user1_db1 | Query | 587 | wsrep: initiating replication for write set (-1) | insert into $table5 values ('... | 0 | 0 | | 51525 | $user1 | 172.24.62.92:7721 | $user1_db1 | Query | 631 | wsrep: initiating replication for write set (-1) | insert into $table5 values ('... | 0 | 0 | | 51998 | $user1 | 172.24.62.92:9585 | $user1_db2 | Query | 475 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 203223 | 0 | 1 | | 52290 | $user1 | 172.24.62.92:10759 | $user1_db2 | Query | 377 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 185874 | 0 | 1 | | 53055 | $user1 | 172.24.62.92:13797 | $user1_db2 | Query | 123 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 89879 a | 0 | 1 | | 53303 | $user1 | 172.24.62.92:14793 | $user1_db2 | Query | 39 | wsrep: initiating replication for write set (-1) | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 146551 | 0 | 1 | | 53396 | $user1 | 172.24.62.92:15176 | $user1_db2 | Query | 7 | updating | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 146551 | 0 | 0 | | 53403 | $user1 | 172.24.62.92:15205 | $user1_db2 | Query | 5 | updating | update $table4 set $col11 = current_timestamp where $col12 = 393 and $col1 = 146551 | 0 | 0 | | 53410 | root | localhost | NULL | Query | 0 | starting | show processlist | 0 | 0 | +-------+-------------+--------------------+-----------------+---------+-------+--------------------------------------------------------+--------------------------------------------------------------------------------------+-----------+---------------+ 30 rows in set (0.00 sec)

(noms de table et de colonne modifiés pour protéger l'innocent)

J'étais incapable de comprendre comment se remettre de cette situation et nous avons fini par avoir à redémarrer l'ensemble du cluster (redémarrage roulé) et re-bootstratp le cluster utilisant service mysql bootstrap-pxc

Nous venions de récemment mis à niveau vers Percona 5.7 ... Nous avions également modifié les transactions définies via SET GLOBAL tx_isolation='READ-COMMITTED'; comme référencé par MySQL DOCS afin d'essayer d'améliorer les performances des sélections. Nous ne savons pas que l'une de ces personnes aurait pu causer la situation que nous avons rencontrée.

Qu'est-ce que cela signifie si MySQL est coincé dans l'état wsrep: initiating replication for write set (-1) et quelles sont certaines causes possibles (et corrections) pour cela?

tobixen · Answer

Il semble que des crashs totaux tels que ceux-ci puissent avoir été dû à un bogue, probablement introduit en 5.7.17 et probablement fixé en 5.7.20, ref https://jira.percona.com/browse/pxc-877

J'ai remarqué "Blip" dans nos systèmes avec de nombreuses requêtes suspendues au même message de statut, mais le problème se résolut dans une minute ou deux, donc probablement pas le même bogue. Il semble que cela se produit avec un (ou plus) des maîtres si un autre maître fait une grande opération d'écriture. J'ai effectivement supprimé l'ensemble du cluster pour essayer d'effacer l'arriéré - c'était une erreur, a causé de nombreuses temps d'arrêt, plus la solution est appropriée aurait été de rediriger le trafic MySQL sur le serveur One qui n'était pas obstrué et attendre les autres à se calmer seuls.

$ MYSQLD --VERSION MYSQLD VER 5.7.23-23-57 pour Linux sur X86_64 (PARCONA XTRADB Cluster (GPL), version Rel23, révision F5578F0, WSREP version 31.31, WSREP_31.31)

Rick James · Answer

(Cela ne répond pas à la question posée, mais cela peut éliminer le problème.)

On dirait que vous manquez le composite INDEX($col1, $col2) (dans l'un ou l'autre ordre).

Et la table est plutôt grande.

Entre les deux, chacun UPDATE semble prendre une minute ou deux, bloquant apparemment le prochain UPDATE.