Pt-table-checksum(PTC)に従ってマスターとスレーブでいくつかの違いを示している表があります。それ以上の違いを確認するものをいくつか見つけました。
ミックス内の特定のテーブルには複合主キーがありますが、PTCには十分に機能しますが、pt-table-sync(PTS)では違いを見つけようとはしません。 PTSは、複合キー検索の深さを制限するPTCの新しいオプションを尊重していないようです。最終結果は、5.5MrowテーブルがPTSで何時間も回転し続けることです。出力が同じ正確なレコード(この時点では他に何もない)の修正を繰り返し吐き出し始めたので、PTSに無限ループバグがあると確信しています。
つまり、この投稿は、このツールを正しく実行することを試みるよりも、代替手段についての詳細です。
頭に浮かぶ最も簡単な方法は、マスターに読み取りロックを設定してテーブルをフラッシュすることです。マスターとスレーブのoutfileに*を選択します。ロックを解除して比較。ただし、このテーブルはかなりアクティブであり、その間マスターでロックアウトされる余裕はありません。
繰り返し可能な読み取り分離レベルでトランザクションを開始し、そこでマスターから選択するようなことをしたいと思っていました。しかし、マスターと同様にトランザクション履歴の特定の時点でスレーブを停止させる方法を見つけることができません。 show master statusのようなものはトランザクションを開始した後も更新され続けるので、それまでは単純にスレーブを開始することはできません。
「マスターステータスの表示、開始」を「すばやく」実行することの原子性についての保証はありません。
非ブロッキングメソッドの他の唯一の解決策は、PTSタイプの処理をより効率的に実行できるが、問題のテーブルの列の生成方法に関するアプリケーション固有のドメイン知識を備えたカスタムスクリプトを作成することです。
PTSのようなプリビルドホイールの丸みが希望どおりにならない場合は、より一般化された将来のソリューションを見つけたいと思っていました。
これは、一時的にスレーブをロックしますが、マスターのサービスを中断しない方法です。
スレーブを停止します。
mysql> STOP SLAVE;
繰り返し可能な読み取りトランザクションのmysqldumpを使用して、マスター上の問題のあるテーブルをダンプします。出力にバイナリログ座標を含めます(--master-data
)。行ごとに1つのINSERTを出力します(--skip-extended-insert
)。
$ mysqldump --single-transaction --master-data=2 --skip-extended-insert
mydatabase myoffendingtable > master-dump.sql
ダンプファイルのbinlog座標に注意し、マスターのダンプファイルに示される座標までスレーブを開始します。
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxx' MASTER_LOG_POS=yyyy;
スレーブスレッドがその位置に追いつき、停止するまで待ちます。これには時間がかかりません。
mysql> SELECT MASTER_POS_WAIT('xxxx', yyyy);
スレーブごとにテーブルをダンプします。これもINSERTごとに1行です。
$ mysqldump --skip-extended-insert mydatabase myoffendingtable > slave-dump.sql
レプリケーションを再開します。
mysql> START SLAVE;
これで、ダンプファイルを比較して、変更のストリーム内でまったく同じ論理ポイントを表すことが保証されます。これにより、データの不一致を見つけることができます。
合理的な説明があります。
VARCHARストレージが一貫性のないCHECKSUMを生成する場合があります。
私はあなたのポストの前とあなたのポストの後にこれについて議論しました
Mar 14, 2014
: ネイティブチェックサムテーブルは違いがあると言っていますが、pt-table-checksumは違いますNov 16, 2012
: Maatkitは1つのテーブルにMySQLレプリケーションエラーを表示しますが、修正しませんあなたができる唯一のことは次のいずれかです
SUGGESTION #1
:mysqldumpを使用して問題のあるテーブルをリロードしますSUGGESTION #2
:マスターとスレーブで行カウントを実行します(一致することを願います)。SUGGESTION #1
これには1つまたは複数のスレーブが関与しているものの、実際には同期に関する十分に文書化されたバグがあります。
一部の状況では、外部キーの変更や主キーのデータ形式を含む、大量の変更テーブルを実行すると、すべてのマスターが同期されますが、スレーブは同期されません。
実は「なぜ?」はありません。回答。