この記事は MySQL Casual Advent Calendar 2017 の8日目の記事です！
1週間前の記事、 日々の覚書: これが多分最後の「MySQL Fabricつらい」 でお焚き上げをしたMySQL Fabricですが、 世の中の物好きな会社 がMySQL Fabricをフォークして mikasafabric for MySQL として使っています。
今日はそのmikasafabric つらい つらくない話をします。ハンカチの用意はよろしいでしょうか。
取り敢えずぶっちゃけた話をするとPythonつらい。
- どこにクローズ漏れがあるのか ファイルディスクリプターをリーク する
max_open_filesの値まで突っ込む- 監視が
Too many open filesで転ける - フェイルオーバーしようとする
- フェイルオーバー操作も
Too many open filesで転ける - しかもタイミングによっては
open_filesに空きができるのでフェイルオーバー操作が 一部だけ成功する という
＿人人人人人人人人人人人＿
＞ 控えめに言って地獄 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^￣
＞ 控えめに言って地獄 ＜
￣Y^Y^Y^Y^Y^Y^Y^Y^￣
接続しているMySQL Routerの数にある程度依存しているような気がしたので、 MySQL Procotolをしゃべっているところ をゴニョゴニョしているものの改善せず…。ボスけて。
↑のバグを踏んだ時、
Too many open files で処理が中途半端に転けたがためにクラスターとして変な状態になっちゃって、「バッキングストアのレコードを直接書き換えることによってフェイルオーバー」させる実績を解除した。つらい。
誰の役にも立たないと思いますが、
servers.mode と servers.status をUPDATEするだけでは足りなくて、 groups.master_uuid もUPDATEしてあげないと promote がAssertion Failureで転けます。
しかもバッキングストアに永続化されているので何度再起動しても転けます。これを知らずにこの状態に陥った場合、大した台数でなければ teardown して再登録した方が速いかも知れません。mysql> SELECT * FROM servers;
+--------------------------------------+-----------------+------+--------+--------+----------+
| server_uuid | server_address | mode | status | weight | group_id |
+--------------------------------------+-----------------+------+--------+--------+----------+
| a95d3771-d667-11e7-acc6-0242ac110002 | 172.17.0.2:3306 | 3 | 3 | 1 | myfabric |
| ab07f0b9-d667-11e7-abd0-0242ac110003 | 172.17.0.3:3306 | 1 | 2 | 1 | myfabric |
| ae8c0955-d667-11e7-ad65-0242ac110004 | 172.17.0.4:3306 | 1 | 2 | 1 | myfabric |
+--------------------------------------+-----------------+------+--------+--------+----------+
3 rows in set (0.00 sec)
mysql> SELECT * FROM groups;
+----------+-------------+--------------------------------------+----------------------------+--------+
| group_id | description | master_uuid | master_defined | status |
+----------+-------------+--------------------------------------+----------------------------+--------+
| myfabric | NULL | a95d3771-d667-11e7-acc6-0242ac110002 | 2017-12-01 07:17:18.000000 | |
+----------+-------------+--------------------------------------+----------------------------+--------+
1 row in set (0.01 sec)
あと、
groups.status は実はBIT型なので↑では NULL でもないのに表示がおかしいとかmysql> desc groups;
+----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+-------+
| group_id | varchar(64) | NO | PRI | NULL | |
| description | varchar(256) | YES | | NULL | |
| master_uuid | varchar(40) | YES | MUL | NULL | |
| master_defined | timestamp(6) | YES | | NULL | |
| status | bit(1) | NO | | NULL | |
+----------------+--------------+------+-----+---------+-------+
5 rows in set (0.00 sec)
mysql> SELECT CAST(status AS signed) FROM groups;
+------------------------+
| CAST(status AS signed) |
+------------------------+
| 1 |
+------------------------+
1 row in set (0.00 sec)
暗黙のキャストに期待して
UPDATE groups SET status = '0' とかやるとmysql> UPDATE groups SET status = '0' WHERE group_id = 'myfabric';
ERROR 1406 (22001): Data too long for column 'status' at row 1
mysql> UPDATE groups SET status = 0 WHERE group_id = 'myfabric';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE groups SET status = b'1' WHERE group_id = 'myfabric';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE groups SET status = 0b0 WHERE group_id = 'myfabric';
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
「あーINTからBITのキャストは出来るけど文字列だと直接BITにキャストできないのかー」とか「そういえば
b'010111' みたいな記法あったよね」とか知ることができて新鮮です。
あとはMySQL Routerさんが
MySQL Fabric support was removed.
MySQL :: MySQL Router Release Notes :: Changes in MySQL Router 2.1.2 (2017-03-06, Release Candidate)
サポートやめちゃったので、今後MySQL Router 2.1以降に追随していくためにはこっちにもパッチを当てないといけない。
（ そもそもコンフィグパーサーから
fabric+cache:// のハンドルが削り取られているので、シンタックスエラーとして扱われる。かなしい）
あー、課題は山積みだわー、つらいわー、mikasafabricほんとつらいわー（棒）
明日は @atsuizoさん で 「SELECT文をタイムアウト強制終了させる「MAX_EXECUTION_TIME」使ってる？」です！