メリークリスマイエスキューエル！ （と、1日）
この記事は GMOペパボエンジニア Advent Calendar 2020 の26日目の記事のつもりです。
ちなみに私の中の人は GMOペパボではない会社 に勤めています。
最近 pt-table-checksum にお世話になる機会が多くなって、使い方をまとめておこうと思ったメモです。
公式ドキュメントはこちら。
pt-table-checksum 自体は簡単に説明した昔の記事が出てきた。
シンプルな例えにすると、 pt-table-checksum はこんな感じに binlog_format＝STATEMENT にしてクエリーを実行します。
mysql57 19> SET SESSION binlog_format = STATEMENT;
Query OK, 0 rows affected (0.00 sec)
mysql57 19> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql57 19> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
| 3 |
+----------+
1 row in set (0.00 sec)
mysql57 19> INSERT INTO checksum (table_name, master_cnt, this_cnd) SELECT 't1', 3, COUNT(*) FROM t1;
binlog_format=STATEMENT を押し込むことで INSERT INTO .. SELECT .. は「 master_cnt はリテラルでマスターの値がそのまま入り、 this_cnt はレプリカで SELECT が再実行されるためレプリカでの値が入る」ことになります。
master_crc, this_crc も同じように「マスターで計算済みのリテラルを入れるカラムとレプリカでリプレイされて計算された値を入れるカラム」に分けられて記録されます。
チェック対象のテーブルはチャンクに分けられて実行されます。1チャンクが1トランザクションで処理されるため、各チャンクをまたいだデータの一貫性はありません（2チャンク目を計算している間に1チャンク目の行の数が変わっているかもしれない、ということ）
バイナリログ直列化の恩恵を受けられるため、マスターの1チャンク目とレプリカの1チャンク目は「同じスナップショット」であることが期待できます。先の例だと、マスターで1チャンク目を更新したあとに1チャンク目に新しく行が追加されても、レプリカはその新しい行が追加される前のスナップショットでチャンクを再計算するため、よほどレアなケースでない限り(もともと binlog_format = STATEMENT && 非決定性関数が頻繁に使われている環境でない限り)計算済みのチャンクで新たな不整合が発生する可能性は低いはずです。
チャンク分けしているのはたぶん、 INSERT .. SELECT .. は SELECT 対象のテーブルの行に共有ロックを置くためロックの範囲が大きくなりすぎないようにとか、そんなにでっかくするとチェックサムを計算するのにレプリケーションが遅れるからとかそういうのの配慮だと思います。
で、俺のよく使うオプションはこんな感じでした。
$ pt-table-checksum \
> --host xxxx --port 3306 \
> --user pt_tcs --password 'xxxx' \
> --ignore-databases mysql,sys \
> --replicate pt.pt_tcs \
> --chunk-size=1000 \
> --recursion-method=processlist \
> --no-check-binlog-format \
> --pause-file=/tmp/pt_tcs.pause \
> --truncate-replicate-table
--host, --port はマスターのもの。--user, --password もマスターのものですが、レプリカ監視用のアカウントを瞬間的に払い出すと楽です。
マスターとレプリカの間でバージョンが違う場合、 --ignore-databases=mysql,sys は必須です( information_schema, performance_schema は pt-table-checksum が勝手に除けます )pt-table-checksum のクエリーは個々のテーブルのカラムを全て参照するため、 マスターとレプリカでカラムの数が違ったりマスターにあってレプリカにないテーブルがあると転けます 。
転けるのはpt-table-checksumのみではなく、レプリケーションそのものが止まります 。
--replicate は「チェックサムの結果を記録するテーブル」を指定します。これを指定しないと、マスターで SELECT だけ投げて終わるのでレプリカとの比較ができません（更新止まってればできるだろうけど）
--chunk-size はチャンク分けする時の基本サイズです。特に何も出なければそのまま1000でいいんですが、「チャンク分けが上手くいかずにこのテーブルはスキップするよ！」みたいなワーニングが出ることがあるので、その時はこの --chunk-size を大きくしてから --tables でそのテーブルを指定して流しなおします。
--recursion-method は3306以外のポートを使っている時は hosts が便利ですが、3306だけなら processlist で問題ないです。
--no-check-binlog-format は「レプリカの binlog_format <> STATEMENT 」な時にスクリプトを実行する時に必要なオプションです。
↓を読むと「マスターとレプリカの binlog_format が違ったらスクリプトを実行させない」のように見えますが、マスターには既に SET SESSION binlog_format = STATEMENT が実行されているので、レプリカの binlog_format = STATEMENT でない限り必ず引っ掛かります。
--replicate で指定したテーブルにFKやTriggerを仕掛けるようなことをしていない限りは(そんなもの好きな人もいないと思う)特に問題ない気がしますが、まあエラーメッセージの通り If you understand the risks, specify --no-check-binlog-format to disable this check. という感じでお願いします。
--pause-file を指定しておくと、そのパスに「ファイルが存在している間はスクリプトがsleepする」ようになります。 pt-online-schema-change と違って実行中ずっと貼りついて見守っていないと不安になるようなスクリプトではないですが、明示的に止めたい時に便利です。 --continue でもいいんですけどね。
--truncate-replicate-table を指定すると、 --replicate で指定したテーブルの中身を1回 TRUNCATE します。これをやらないと過去の行が残るので、前に pt-table-checksum を同じコマンドで流した場合に前の結果の残骸が残ることがあります（書き込み自体は REPLACE INTO なので、過去にも今にも存在するチャンクの情報は上書きされるけれど、過去にあって今ないチャンクの情報が消えない）
--truncate-replicate-table を指定 しない 場合、前の情報が残っているので --continue が使えます。
これはCtrl+Cとかで pt-table-checksum を止めた場合、「その手前までは --replicate で指定したテーブルにチャンクのチェックサムが残っているはず」ということで、テーブルに載っていないチャンクから処理を再開させることができるオプションです。
なお俺は何度か --truncate-replicate-table と --continue を同時に指定して「あれーおかしいなーまた先頭からチェックサム取ってるなー」とかやってたことがあります。我ながらアホだ。
それでは、良いお年を！
0 件のコメント :
コメントを投稿