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関連のステートメントが使えなくなるので、たっぷり復旧方法を考えたり試したりできる。

日々の覚書

GA

2020/02/21

MultiPrimaryModeのGroup Replication環境を崩壊させるテスト

TL;DR

0 件のコメント :

コメントを投稿