MySQLが「wsrep：書き込みセット（-1）のレプリケーションを開始中」でスタックしました

Question

最近、MySQLでこれまで見たことのない状況に遭遇しました。 3つのノードを持つPerconaクラスターがあります。マスターがクエリの処理を停止し、ホストしているPHP FPM Webアプリケーションが応答しなくなりました。_SHOW PROCESSLIST_をチェックすると、MySQLプロセスがwsrep: initiating replication for write set (-1)

これは、PHPがすべてのクエリを転送していたプライマリと、2つのセカンダリの1つに当てはまります。ここに_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) _

（罪のない人を保護するためにテーブルと列の名前が変更されました）

この状況から回復する方法を理解できなかったため、クラスター全体を再起動（ローリングリブート）し、_service mysql bootstrap-pxc_を使用してクラスターを再ブートしなければなりませんでした

最近Percona 5.7にアップグレードしました... SELECTのパフォーマンスを向上させるために、 MySQL Docs によって参照される_SET GLOBAL tx_isolation='READ-COMMITTED';_を介したSet Transactionsも変更しました。これらのいずれかが、発生した状況を引き起こしたのかどうかは不明です。

MySQLがwsrep: initiating replication for write set (-1)の状態で動かなくなった場合、それはどういう意味ですか？その原因として考えられる原因（および修正）は何ですか？

tobixen · Answer

このような完全なクラッシュは、何らかのバグが原因である可能性があるようです。おそらく5.7.17で導入され、おそらく5.7.20で修正されています。ref https://jira.percona.com/browse/PXC-877

同じステータスメッセージで多数のクエリがハングするシステムの「ブリップ」に気づきましたが、問題は1〜2分以内に解決したため、おそらく同じバグではありません。これは、別のマスターが大きな書き込み操作を行っている場合、1つ（または複数）のマスターで発生するようです。実際にクラスター全体を一度停止してバックログをクリアしようとしました-これは間違いであり、かなりのダウンタイムが発生しました。より適切な修正は、mysqlトラフィックを詰まっていなかった1つのサーバーにリダイレクトして待機することでした。他の人たちは自分で落ち着くために。

$ mysqld --version mysqld Ver 5.7.23-23-57 for Linux on x86_64（Percona XtraDB Cluster（GPL）、リリースrel23、リビジョンf5578f0、WSREPバージョン31.31、wsrep_31.31）

Rick James · Answer

（これは尋ねられた質問には答えませんが、問題を解消するかもしれません。）

composite INDEX($col1, $col2)（どちらの順序でも）が足りないようです。

そして、テーブルはかなり大きいです。

それらの両方の間で、各UPDATEには1〜2分かかるようで、次のUPDATEをブロックしているようです。