面接問題:MySQL主従データが一致しない原因は?

生命は小川のようだ.風雨はもっと広がるだけ
主従の不一致の原因をもたらす

プライマリ・ライブラリbinlog形式はStatementであり、ライブラリから実行されるまで同期するとプライマリ・スレーブが一致しない可能性があります.

メインライブラリ変更を実行する前にset sql_を実行するlog_bin=0では、メインライブラリにbinlogが記録されず、ライブラリからこのデータを変更することはできません.

ノードから読み取り専用が設定、誤動作書き込みデータ

.

プライマリ・ライブラリまたはスレーブ・ライブラリが予期せぬダウンタイムを発生し、ダウンタイムによりbinlogまたはrelaylogファイルが破損し、プライマリ・スレーブが一致しない

マスタスレーブインスタンスバージョンが一致しない、特に高バージョンがマスタであり、低バージョンがスレーブの場合、マスタデータベース上でサポートされている機能は、データベース上からサポートされていない可能性がある

.

MySQL自身のバグによる

主従不一致修復方法
ライブラリから再実装

これも解決策ですが、このスキームのリカバリ時間は遅く、ライブラリからもクエリー操作の一部を引き受けている場合があり、簡単に再構築できない場合があります.

percona-toolkitツールを使用してPTツールパッケージにpt-table-checksumとpt-table-syncの2つのツールが含まれています.主に主従が一致しているかどうか、データの不一致を修復するかどうかを検出するために使用されます.この案の利点は修復速度が速く、主従補助を停止する必要がないことであり、欠点は知識の蓄積が必要であり、学習、テスト、特に生産環境では、注意して使用する必要があることである.
不一致テーブルの手動再構築

ライブラリから発見されたいくつかのテーブルはメインライブラリのデータと一致しないが、これらのテーブルのデータ量も比較的大きく、手作業でデータを比較するのは現実的ではなく、

である.

ライブラリ全体のやり直しも遅いので、このときはこの数枚のテーブルだけをやり直して主従の不一致

を修復することができます.
このシナリオの欠点は、インポートの実行中にライブラリからのレプリケーションを一時的に停止する必要があることですが、許容できます.
例:A,B,Cの3つのテーブルの主従データが一致しない

1、    Slave  
mysql>stop slave;

2、    dump    ，       binlog POS 
mysqldump -uroot -pmagedu -q --single-transaction --master-data=2 testdb A B 
C >/backup/A_B_C.sql

3、  A_B_C.sql  ，     binlog POS 
head A_B_C.sql
  :MASTERLOGFILE='mysql-bin.888888', MASTERLOGPOS=666666;
#                  ，           ，A,B,C           
        ，       ，        

4、 A_B_C.sql   Slave   ，       
mysql>start slave until MASTERLOGFILE='mysql-bin.888888', 
MASTERLOGPOS=666666;

5、 Slave     A_B_C.sql
mysql -uroot -pmagedu testdb 
mysql>set sql_log_bin=0;
mysql>source /backup/A_B_C.sql
mysql>set sql_log_bin=1;

6、     ，        。
mysql>start slave;

主従の不一致を回避する方法

メインライブラリbinlogはROW形式

を採用

プライマリ・スレーブ・インスタンス・データベース・バージョンは、

の一貫性を維持します.

メインライブラリはアカウントの権限をしっかりとコントロールして、set sqlを実行することができませんlog_bin=0

ライブラリから読み取り専用をオンにし、

への人為的な書き込みは許可する.

定期的に主従一致性検査

を行う.