TL;DR
- 完全崩壊した時の復旧シナリオを考えたりするには、やっぱり崩壊した状態を再現させられると便利だよね
cluster.switchToMultiPrimaryMode()してから2つの別のノードに「1回目は成功するけど2回流すと必ず失敗するALTER TABLE」を投げると崩壊させられる
- 日々の覚書: CentOS 7のAMIでEC2を起動してGroup Replicationを組むところまでを何も考えずにのスクリプトで3台のInnoDB Clusterを立てておく
- sysbenchで雑に100万行くらいのテーブルを作る
- 2回実行したら必ず失敗するようなALTER TABLEを投げる
- サポート外なのは知っていて、Group Replicationを 崩壊させるのが目的なので良いのだ
node1> ALTER TABLE sbtest.sbtest1 ADD KEY idx_pad (pad);
Query OK, 0 rows affected, 1 warning (10.36 sec)
Records: 0 Duplicates: 0 Warnings: 1
-- 5秒くらい待つ
node2> ALTER TABLE sbtest.sbtest1 ADD KEY idx_pad (pad);
Query OK, 0 rows affected, 1 warning (10.60 sec)
Records: 0 Duplicates: 0 Warnings: 1
node1のALTER TABLEが終わり、node2とnode3に渡されるnode2では手で打ったALTER TABLEがメタデータをロックしているのでnode1から渡ってきたALTER TABLEは待たされるnode3ではnode1由来のALTER TABLEが実行されるnode2の手で打ったALTER TABLEが終わり、node1由来のALTER TABLEを適用しようとするが同じ名前のインデックスは作成できないのでエラーnode2由来のALTER TABLEがnode1とnode3に到達して、やっぱり同じ名前のインデックスは作成できないのでエラー
結果として完全崩壊する。
### node1
$ mysql -e "SELECT member_host, member_state, member_role FROM performance_schema.replication_group_members"
+------------------------------+--------------+-------------+
| member_host | member_state | member_role |
+------------------------------+--------------+-------------+
| node1 | ERROR | |
| node2 | ONLINE | PRIMARY |
| node3 | ONLINE | PRIMARY |
+------------------------------+--------------+-------------+
### node2
$ mysql -e "SELECT member_host, member_state, member_role FROM performance_schema.replication_group_members"
+-----------------------------+--------------+-------------+
| member_host | member_state | member_role |
+-----------------------------+--------------+-------------+
| node2 | ONLINE | PRIMARY |
+-----------------------------+--------------+-------------+
### node3
$ mysql -e "SELECT member_host, member_state, member_role FROM performance_schema.replication_group_members"
+------------------------------+--------------+-------------+
| member_host | member_state | member_role |
+------------------------------+--------------+-------------+
| node1 | ONLINE | PRIMARY |
| node2 | ONLINE | PRIMARY |
| node3 | ERROR | |
+------------------------------+--------------+-------------+
エラーログはどのノードも同じようなことを言っていた。
2020-02-21T09:10:32.562676Z 13 [ERROR] [MY-011451] [Repl] Plugin group_replication reported: 'The applier thread execution was aborted. Unable to process more transactions, this member will now leave the group.'
2020-02-21T09:10:32.562690Z 13 [ERROR] [MY-010586] [Repl] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'FIRST' position 0
2020-02-21T09:10:32.562921Z 9 [ERROR] [MY-011452] [Repl] Plugin group_replication reported: 'Fatal error during execution on the Applier process of Group Replication. The server will now leave the group.'
2020-02-21T09:10:32.562975Z 9 [ERROR] [MY-011712] [Repl] Plugin group_replication reported: 'The server was automatically set into read only mode after an error was detected.'
ここまで来るともうまともにMySQL ShellやGroup Replication関連のステートメントが使えなくなるので、たっぷり復旧方法を考えたり試したりできる。