はじめに：
現在最も一般的に使用されているMySQLデータベースは、高可用性アーキテクチャは、ほとんどのマスタ - スレーブ・アーキテクチャを介して進化マスタ - スレーブ・アーキテクチャです。しかし、そのような誤用のようなアーキテクチャから長い実行時間後にデータの不整合を起こしやすいマスターは、その上の書き込みやバグが原因ライブラリからコピーすることができ、この記事では、メインの矛盾とどのようにこの問題を解決するから出てくる詳細に検討します。
一貫性のない原因となった主な理由から、1
いくつかの簡単なリスト次の原因の主な原因から、多くの矛盾があります。
- マスタースレーブに同期を実行するためのライブラリーからメインライブラリのbinlogフォーマットステートメントは、一貫性のない恐れがあります。
- メインライブラリは= 0、メインライブラリが記録されませんbinlogのSQL_LOG_BIN設定して実行する前に、データベースからのデータのこの部分を変更することはできません、変更を行います。
- ノードが読み取り専用、書き込みデータから提供されていないことは誤りです。
- メインライブラリまたは計画外のダウンタイムのライブラリーから、ダウンタイムは、マスタースレーブ矛盾につながる、バイナリログまたはrelaylogファイルが破損している原因になります。
- マスタからの一貫性のないバージョンの例として、マスターバージョンが特に高い、場合より低いバージョン、メインデータベースによってサポートされる上記の機能は、データベースは、上記の機能をサポートしていなくてもよいです。
- MySQLのバグ自体が原因。
メイン矛盾補修方法2.
ここでは、一貫性のない修理からの主な方法です。この話は、マスタ・スレーブ同期エラーからの不整合を修復するのではなく、マスターを修復することであることに注意してください。
矛盾したマスタースレーブを修正するには、まずメインの矛盾から見つける必要があり、さまざまな状況に応じて適切な修復方法が与えられます。
最初のケースは：より速く実行するために、スクリプトを実行する場合、例えば、スクリプトは、設定SQL_LOG_BIN = 0を付加します。そして、すべてのデータがスクリプトをライブラリに適用されません変更のマスタデータが矛盾しているから、この時間は、解決策は、最初のマスターコピーから停止し、その後、手動で最後に開かれているこのスクリプトライブラリ、マスタースレーブのレプリケーションを実行していますことができます。
第2の状況：アーキテクチャが明確ではないので、あなたが同僚からの読み取り専用のライブラリーを設定していないことが、この状況は、タイムリーなフィードバックもして解決する必要があり、データベースからの書き込みデータにつながったミスを犯しました。解決策：あなたは本当にこれらのステートメントを実行する必要がある場合は、メインのライブラリセットSQL_LOG_BIN = 0、その文が実行される中で行うことが可能であり、あなたがこれらのステートメントを実行しない場合は、前の誤用のバックアウトライブラリーからロールバックする必要があります。
時々の状況はそれほど単純ではありません、あなたはより多くの例があるが発生する可能性がありしかし：すでに長時間実行されているマスター・スレーブ2つのインスタンスを、1日の整合性チェックは、マスタからの矛盾を発見し、特定の不整合が発生する原因と時間を見つけることは困難です。だから、今回はそれを行う方法である必要があり、これが解決策ですが、それは、ライブラリから再度やり直し、と言われたが、このプログラムに遅い回復時間、そして時には図書館からも急いで再構築することができないのクエリの一部を負担します。次の次の話に焦点を当て、この場合に固定してください。
支援するためにpercona-ツールキットのツールを使用してください。
PTキットは主に同じ不整合および修復から主データか否かを検出するために、PT-テーブルチェックサム、およびPT-テーブル同期2つのツールを含んでいます。このプログラムは、修理の高速が特徴あなたはこのツールを使用する可能性が低いがあった場合、セカンダリからプライマリに停止する必要が、欠点は、知識の蓄積の必要性は、それは、学ぶために時間がかかる場合がありますテストするために、特に本番環境で、または注意する、ではありません使用しています。
使用方法については、以下のリンクを参照してください。
https://www.cnblogs.com/feiren/p/7777218.html手動で一貫性のないテーブルを再構築します。
例えば、我々はライブラリとメインライブラリデータの不整合からいくつかのテーブルを見つけ、少数の比較的大きなデータ・テーブル、手動アラインメント非現実的なデータの量、およびライブラリ全体をやり直すが比較的遅いこと、これだけの時間は、あなたがそれをやり直すことができますマスターからのいくつかのテーブルには、不整合を修復します。例：マスター・データの不整合から、これら3つのテーブルC1 A1、B1、我々はこれを行うことができます。
ライブラリからスレーブレプリケーションを停止するには1、
MySQLの>停止スレーブ;図2は、POSバイナリログメインデータベースにこれら3つのテーブルをダンプし、同期点を記録し、
mysqldumpを-uroot -p123456 -q --singleトランザクション--master -data = 2 yourdb A1、B1、C1> ./a1_b1_c1.sql図3に示すように、ファイルビューa1_b1_c1.sql、特定したレコードバイナリログPOS点
よりa1_b1_c1.sql
例えばMASTER_LOG_FILE = 'のMySQL-bin.002974'、 MASTER_LOG_POS = 55056952。4、a1_b1_c1.sqlは、スレーブマシンにコピーし、ポイントするマスターを変更してください
mysqlの> MASTER_LOG_FILE =「までのスレーブを起動するのmysql-bin.002974」、= 55056952 MASTER_LOG_POS;
注：私が説明し、このステップは何を意味するかです。データの他のテーブルの保護が失われない、ダンプがスナップショットを生成された前の同期は、その時点の終わり、データA1、B1、C1テーブルまで終了し、同期された、我々だけ入力して、[開くように同期させるためにインポートする必要があります。5、a1_b1_c1.sqlスレーブ機械導入に（高速とするために導入バイナリログを作るために、ライブラリから開いた第SQL_LOG_BIN = 0 SETを実行する）
のMySQL -uroot - p123456 yourdb <./ a1_b1_c1.sqlインポートが完了した後6、あなたはライブラリから同期を開くことができます。
MySQLの>スレーブを起動します。だから我々は3つのテーブルを復元し、同期も固定されています。欠点は、このプログラムは、ライブラリからのインポートのコピー中に停止する必要はなく、許容できるということです。
そこ比較や他のツールのような同期のNavicatなどの他の修正、であってもよいが、これらのツールは、少量のデータのみを適用し、データの数千万人が存在する場合には、このアプローチは現実的ではないことがあります。あなたは似たような経験を持っていますか、あなたも共有でメッセージを残すことができます。
3.マスターからの不整合を回避する方法
上記の説明を通して、あなたはおそらく修正が容易ではありません知っているかもしれませんので、我々は、我々はそれのマスターから矛盾を避けるか、どのようにソースを回避するために必要な、ここでいくつかの提案であり、私はあなたに役立つ願っています。
- ROWビンログ形式を使用して、メインのライブラリ。
- インスタンスデータベースのバージョンからの主な一貫性。
- メインライブラリのチェックアカウント権限はセットSQL_LOG_BIN = 0を実行していない、制御することができます。
- オープン読み取り専用のライブラリーから、人々は書くことはできません。
- メインの一貫性から定期検査。
要約：
この記事では、矛盾の主な理由の原因の詳細を修理する方法と主要矛盾から矛盾を回避する方法。特定の矛盾補修方法では、他のソリューション、修理の適切な方法を選択するために、実際の状況を考慮する必要があるかもしれません。元は容易ではない、私たちがサポートできることを願っています。