PerconaToolkitで使用されるPt-table-sync
Pt Table Sync Used Percona Toolkit
pt-table-syncの機能は、MySQLテーブルデータを効果的に同期することです。
使用法は次のとおりです。
pt-table-sync [OPTIONS] DSN [DSN]Pt-table-syncは、MySQLテーブル間でデータを効果的に同期します。
このツールはデータを変更するため、可能な限り安全にするために、使用する前にデータをバックアップすることをお勧めします。 --replicateまたは--sync-to-masterを使用してレプリケーションスレーブサーバーを同期する場合、スレーブを直接変更するのではなく、常にレプリケーションマスターに変更を加えます。一般的に、これはレプリカをマスターと同期する唯一の安全な方法であり、レプリカを直接変更することが問題の根本原因です。ただし、マスターで行われた変更は、データを変更せずに現在の値に変更することです。これは、レプリカにのみ影響します。
①host1のdb.tblをhost2に同期します。
pt-table-sync --execute h=host1,D=db,t=tbl h=host2②host1のすべてのテーブルをhost2およびhost3に同期します。
pt-table-sync --execute host1 host2 host3③slave1とそのレプリケーションマスターに同じデータを持たせます。
pt-table-sync --execute --sync-to-master slave1④解はpt-table-checksum（ https://blog.csdn.net/sweeper_freedoman/article/details/80201492 ）ツールによって検出されたmaster1のすべてのスレーブの不整合。
pt-table-sync --execute --replicate test.checksum master1⑤上記と同じですが、slave1の不整合のみを解決します。
pt-table-sync --execute --replicate test.checksum --sync-to-master slave1⑥マスターレプリケーション構成でmaster2を同期します（master2のdb.tblのコピーが既知であるか、正しくないと思われます）。
pt-table-sync --execute --sync-to-master h=master2,D=db,t=tblマスター-マスターレプリケーション構成では、以下はmaster2への変更に直接影響し、レプリケーションを逆流してmaster1のデータを変更するため、期待どおりに機能しないことに注意してください。
# Don't do this in a master-master setup! pt-table-sync --execute h=master1,D=db,t=tbl master2警告 ：Pt-table-syncデータを変更してください！このツールを使用する前に、次のことを行ってください。
- ツールのドキュメントを読む
- ツールの既知のバグを表示する
- 非実稼働サーバーでのテストツール
- 本番サーバーをバックアップし、バックアップを確認します
pt-table-syncは成熟しており、現実の世界で実証されており、十分にテストされています。しかし、不適切に使用すると、望ましくない結果につながる可能性があります。常に最初に同期をテストするには、-dry-runおよび--printオプションを使用してください。
Pt-table-syncは、テーブルデータの一方向および双方向の同期を実行します。テーブル構造、インデックス、またはその他のフレームワークオブジェクトは同期されません。一方向の同期については、以下で説明します。
このツールは複雑で、いくつかの異なる方法で機能します。安全かつ効果的に使用するには、-replicateオプションの目的、不整合の検出、およびホストの指定という3つのポイントを理解する必要があります。これらの3つの概念は密接に関連しており、ツールの動作方法を決定します。以下は疑似ロジックです。
if DSN has a t part, sync only that table: if 1 DSN: if --sync-to-master: The DSN is a slave. Connect to its master and sync. if more than 1 DSN: The first DSN is the source. Sync each DSN in turn. else if --replicate: if --sync-to-master: The DSN is a slave. Connect to its master, find records of differences, and fix. else: The DSN is the master. Find slaves and connect to each, find records of differences, and fix. else: if only 1 DSN and --sync-to-master: The DSN is a slave. Connect to its master, find tables and filter with --databases etc, and sync each table to the master. else: find tables, filtering with --databases etc, and sync each DSN to the first.Pt-table-syncは、-replicateオプションを使用する方法と--replicateオプションを使用しない方法の2つの方法で実行できます。デフォルトでは、-replicateオプションを指定せずに実行します。これにより、pt-table-syncがいくつかのアルゴリズムの1つを使用して、不整合を効果的に自動的に検出できるようになります。または、-replicateオプションで値が指定されている場合、pt-table-syncは、以前にpt-table-checksumによって独自の--replicateオプションで実行された不整合を使用します。厳密に言えば、pt-table-syncは不整合を見つける可能性があるため、-replicateオプションを使用する必要はありませんが、たとえば、pt-table-checksumを使用して定期的にチェックしてから使用する場合、多くの人が--replicateを使用します。 pt-table -syncは、必要に応じて不整合を修正します。よくわからない場合は、各ツールのドキュメントを注意深く読んで自分で決めるか、専門家に相談してください。
--replicateオプションを使用するかどうかに加えて、同期するホストを指定する必要があります。 --sync-to-masterオプションを使用する方法と--sync-to-masterオプションを使用しない方法の2つがあります。 --sync-to-masterを使用すると、pt-table-syncはコマンドラインで唯一のスレーブDSN（MySQL接続アクセス）のみを受け入れます。ツールは自動的にスレーブのマスターを見つけてから同期して、データをそのマスターと一致させます。これは、マスターに変更を加えてから、レプリケーションインフローを介してスレーブを更新し、その不整合を解決することで実現されます。ただし、注意してください：このオプションは単一のスレーブのみを指定して同期しますが、マスターに他のスレーブ接続がある場合、それらをコピーすると、同期しようとしているスレーブの変更も受信されます。
さらに、-sync-to-masterオプションを指定しない場合、コマンドラインで指定された最初のDSN（MySQL接続アクセス）がソースホストになります。ソースホストは1つだけ存在できます。 --replicateオプションを指定しない場合は、宛先ホストとして少なくとも1つの他のDSN（MySQL接続アクセス）を指定する必要があります。 1つ以上の宛先ホストが存在する可能性があります。送信元ホストと宛先ホストは互いに独立している必要があり、同じレプリケーショントポロジに含めることはできません。宛先ホストがスレーブであることが検出された場合、変更は宛先ホストに直接書き込まれるため、pt-table-syncはエラーを報告して終了します（スレーブに直接書き込むことは安全ではありません）。または、-replicateオプションを指定した場合（--sync-to-masterオプションは指定しません）、pt-table-syncはコマンドラインで唯一のマスターDSN（MySQL接続アクセス）を受け入れます。このツールは、マスターのすべてのスレーブを自動的に検出し、それらをマスターと同期します。これは、複数の（すべての）スレーブを一度に同期する唯一の方法です（--sync-to-masterオプションでは1つのスレーブしか指定できないため）。
コマンドラインの各ホストは、DSN（MySQL接続アクセス）によって指定されます。最初のDSN（または--sync-to-masterのような単一のDSNの場合）は、これらのDSNがコマンドラインで指定されているかツールによって自動的に検出されているかに関係なく、他のDSNのデフォルト値を提供します。したがって、この例では、host2DSNはhost1DSNからuとpの部分を継承します。 --explain-hostsオプションを使用して、pt-table-syncがコマンドラインで指定されたDSNをどのように解析するかを確認します。
pt-table-sync --execute h=host1,u=msandbox,p=msandbox h=host2pt-table-syncを--sync-to-masterオプションまたは--replicateオプションとともに使用する場合、ステートメントベースのレプリケーションが必要です。したがって、必要に応じて、マスターのbinlog_format = STATEMENTをセッションレベルで設定します。これを行うには、ユーザーはSUPER権限を持っている必要があります。
--verboseオプションを指定すると、テーブル間で一貫性のない情報が表示されます。テーブルごとに1行。各サーバーは別々に印刷されます。例えば：
# Syncing h=host1,D=test,t=test1 # DELETE REPLACE INSERT UPDATE ALGORITHM START END EXIT DATABASE.TABLE # 0 0 3 0 Chunk 13:00:00 13:00:17 2 test.test1host1のtest.test1テーブルは、同期するために3つのINSERTステートメントを必要とし、チャンクアルゴリズムを使用します。このテーブルの同期操作は13:00:00に開始し、17秒後に終了します（時間はソースホストのNOW（）から取得されます）。不整合が見つかったため、その終了ステータスは2です。
--printオプションを指定すると、スクリプトがテーブルを同期するために使用する実際のSQLステートメントが表示されます（--executeオプションも指定されている場合）。
pt-table-syncがブロック、ニブル、レコードなどを照会するために使用するSQLステートメントを表示する場合は、-printオプションを1回指定してから、-verboseオプションを2回指定します。ただし、注意してください。これにより、多くのSQLステートメントが出力されます。
一意キー制約に違反しません。 INSERT、UPDATE、またはDELETEステートメントの組み合わせでは、不整合を解決できません。たとえば、aフィールドに主キーがあり、bフィールドに一意のインデックスがあるとすると、次の2つのテーブルをUPDATEステートメントと直接同期することはできません。
+---+---+ +---+---+ | a | b | | a | b | +---+---+ +---+---+ | 1 | 2 | | 1 | 1 | | 2 | 1 | | 2 | 2 | +---+---+ +---+---+この場合、ツールはクエリをDELETEおよびREPLACEとして書き換えます。これは、最初のインデックス制約が解除された後に自動的に処理されるため、心配する必要はありません。
マスターマスターレプリケーション設定でpt-table-syncを使用する場合は注意してください。マスター-マスターレプリケーションは本質的に複雑であるため、エラーが発生しやすくなります。マスターマスターレプリケーションには、このツールを正しく使用する必要があります。
また、ONDELETEまたはONUPDATEの外部キー制約定義を持つテーブルにも注意してください。これらは、サブテーブルに予期しない変更を引き起こす可能性があるためです。 -[no] check-child-tablesオプションを参照してください。
一般的に、このツールは、テーブルに主キーまたは一意のインデックスがある場合に最適です。主キーまたは一意のインデックスを持たないテーブル間でデータを同期することもできますが、このデータを他の方法で同期することをお勧めします。
一般的に言って、レプリケーションアーキテクチャでマスターとスレーブを安全に同期することは簡単な問題ではありません。データを変更する他のプロセス、スレーブ上のデータを変更しようとするプロセス、ソースホストとターゲットホストがマスターとマスターのペアであるかどうかなど、考慮すべきさまざまな状況があります。
通常、この操作を実行する安全な方法は、マスター上のデータを変更してから、他の変更と同様に、これらの変更をレプリケーションを通じてスレーブに流すことです。ただし、これは、マスターのテーブルへのREPLACE書き込みを実行できる場合にのみ機能します。 REPLACEは、テーブルに一意のインデックスがある場合にのみ有効です（それ以外の場合は、通常のINSERTの役割のみを果たします）。
テーブルに一意のインデックスが含まれている場合は、-sync-to-masterおよび/または--replicateオプションを使用して、スレーブをそのマスターに同期する必要があります。これは通常正しいことをします。テーブルに一意のインデックスがない場合、スレーブのデータを変更する以外に選択肢はありません。 pt-table-syncはあなたがそうしたいことを見つけるでしょう。 --no-check-slaveオプションを指定しない限り、文句を言って死にます。
マスターとマスターのペアで主キーまたは一意のインデックスのないテーブルを同期する場合は、宛先サーバーのデータを変更する必要があります。したがって、セキュリティのために--no-bin-logオプションを指定する必要があります。そうでない場合、宛先サーバーで行った変更はソースサーバーにコピーされ、そこでのデータが変更されます。
宛先サーバーのデータを変更しないように、マスターとマスターのペアで--sync-to-masterオプションを使用するのが一般的に安全です。また、pt-table-syncがスレーブ上のデータの変更について文句を言わないように、-no-check-slaveを指定する必要があります。
Pt-table-syncには、さまざまなアルゴリズムを使用して不整合を見つける一般的なデータ同期フレームワークが含まれています。ツールは、-algorithmsオプションで指定されたインデックス、フィールドタイプ、およびアルゴリズムパラメータの選択に基づいて、各テーブルに最適なアルゴリズムを自動的に選択します。以下は、使用可能なアルゴリズムであり、デフォルトの優先順位でリストされています。
①チャンク
最初のフィールドが数値（日付と時刻のタイプを含む）であるインデックスを見つけてから、フィールドの値の範囲を--chunk-size行レコードごとに1つのブロックに分割します。ブロック全体の単位でチェックサムを実行し、ブロックを1つずつ同期します。ソースと宛先のブロックに一貫性がない場合、ブロック内の各行でチェックサムが実行され、一貫性のないレコードが検出されます。
これは、フィールドにブロックを最終的に適切なサイズにするのに十分なカーディナリティが含まれている場合に効果的です。
各ブロックの初期チェックサムは非常に小さいため、ネットワークトラフィックとメモリ消費が最小限に抑えられます。ブロック内のレコードをチェックする必要がある場合は、レコード行全体ではなく、主キーフィールドとチェックサムクエリのみがネットワーク経由で送信されます。レコードに一貫性がないことが判明した場合、行全体が取得されますが、以前は取得されません。
同じ文字で始まるすべてのデータでcharフィールドをブロックする場合、アルゴリズムは機能しないことに注意してください。この時点で、ツールは終了し、別のアルゴリズムを提案します。
②ニブル
インデックスを見つけ、-chunk-size行を使用して、固定サイズのニブルとして記録します。非バックトラッキングアルゴリズムを使用して、インデックスを「クライミング」します。pt-archiver（ https://www.percona.com/doc/percona-toolkit/LATEST/pt-archiver.html ）アルゴリズムの詳細をご覧ください。これは「チャンク」アルゴリズムと非常に似ていますが、インデックスのカーディナリティに基づいてテーブル内の各ブロックの境界を事前に計算する代わりに、LIMITを使用して各ニブルの上限を定義し、次に下限を定義する前のニブル。
これは段階的に機能します。1つのクエリでニブルの次の上限を定義するレコードを検索し、次のクエリでニブル全体をチェックサムします。ソースと宛先の間のニブルに一貫性がない場合は、「チャンク」アルゴリズムと同様に、ニブルを1行ずつチェックします。
③GroupBy
すべてのフィールドのグループでテーブル全体をクエリし、COUNT（*）フィールドを追加します。すべてのフィールドを比較します。同じ場合は、COUNT（*）フィールドの値を比較して、宛先に挿入または削除された行の数を判別します。主キーまたは一意のインデックスのないテーブルで作業します。
④ストリーム
巨大なストリームでテーブル全体をクエリし、すべてのフィールドを比較します。すべてのフィールドをクエリします。これは他のアルゴリズムよりもはるかに効率が低く、使用するのに適したインデックスがない場合に機能します。
以下は、pt-table-syncが終了および終了したときの終了ステータス（戻り値または戻りコードとも呼ばれます）です。
STATUS MEANING ====== ======================================================= 0 Success. 1 Internal error. 2 At least one table differed on the destination. 3 Combination of 1 and 2.以下は、個人のローカル環境のテストデータです。具体的には、以前はpt-table-checksumを使用していました（ https://blog.csdn.net/sweeper_freedoman/article/details/80201492 ）マスターとスレーブの間で見つかったデータに一貫性がありません（スレーブに5つのデータがありません）。
まず、不整合を修復するために実行されるステートメントを確認します。
root@xxxxx:~# pt-table-sync h=192.168.112.129, P=3306, u=root, p=123456 h=192.168.112.128, P=3306, u=root, p=123456 -dplayer --replicate=percona.checksums --print REPLACE INTO `player`.`player_def`(`id`, `number`, `name`, `role`) VALUES ('1', '1', 'hachi', 'GK') /*percona-toolkit src_db:player src_tbl:player_def src_dsn:h=192.168.112.129 dst_db:player dst_tbl:player_def dst_dsn:h=192.168.112.128 lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3972 user:root host:ubuntu*/ REPLACE INTO `player`.`player_def`(`id`, `number`, `name`, `role`) VALUES ('2', '2', 'ni', 'left back') /*percona-toolkit src_db:player src_tbl:player_def src_dsn:h=192.168.112.129 dst_db:player dst_tbl:player_def dst_dsn:h=192.168.112.128 lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3972 user:root host:ubuntu*/ REPLACE INTO `player`.`player_def`(`id`, `number`, `name`, `role`) VALUES ('3', '3', 'san', 'center back') /*percona-toolkit src_db:player src_tbl:player_def src_dsn:h=192.168.112.129 dst_db:player dst_tbl:player_def dst_dsn:h=192.168.112.128 lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3972 user:root host:ubuntu*/ REPLACE INTO `player`.`player_def`(`id`, `number`, `name`, `role`) VALUES ('4', '4', 'yon', 'center back') /*percona-toolkit src_db:player src_tbl:player_def src_dsn:h=192.168.112.129 dst_db:player dst_tbl:player_def dst_dsn:h=192.168.112.128 lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3972 user:root host:ubuntu*/ REPLACE INTO `player`.`player_def`(`id`, `number`, `name`, `role`) VALUES ('5', '5', 'go', 'right back') /*percona-toolkit src_db:player src_tbl:player_def src_dsn:h=192.168.112.129 dst_db:player dst_tbl:player_def dst_dsn:h=192.168.112.128 lock:1 transaction:1 changing_src:percona.checksums replicate:percona.checksums bidirectional:0 pid:3972 user:root host:ubuntu*/ root@xxxxx:~# DML（5つの完全なREPLACE INTOステートメント）に問題がないことを確認してから、直接修復を実行します。
root@xxxxx:~# pt-table-sync h=192.168.112.129, P=3306, u=root, p=123456 h=192.168.112.128, P=3306, u=root, p=123456 -dplayer --replicate=percona.checksums --execute root@xxxxx:~#
参照：
https://www.percona.com/doc/percona-toolkit/LATEST/pt-table-sync.html