0

私たちは標準の Mysql マスター/スレーブ レプリケーション システムを実行しており、これは数年間うまく機能しています。実際、サーバーの停止 (マスターをオフラインにした) から、スレーブ DB を使用して (マスターに変えた後) 復旧できました。

とにかく、問題の原因となっている問題は、サーバーを復旧し、元のマスターをマスターに戻し、元のスレーブをスレーブに戻した後に発生しました。

それは私が馬鹿だったことが原因でした - 他の何のせいでもありません!

基本的に、書き込みはスレーブで発生しました。つまり、マスターの同じテーブルへの書き込みは、重複した主キー エラーのためにレプリケートできません。

私が言ったように、私のせいです。

そこに誤って書き込まれたスレーブからレコードを削除できます。したがって、競合する ID をスレーブから削除しますが、マスター DB からレコードが必要です。

私の質問は次のとおりです。(SQL_SLAVE_SKIP_COUNTER を 1 に設定することにより) マスターから関連するクエリをスキップすることでレプリケーションを「修正」できることはわかっていますが、それはマスターからのレコードを失うことを意味します。

では、エラーが発生したレプリケーション書き込みを「再生」する方法はありますか? 基本的に、レプリケーションを1つのクエリに戻すことを指していますか?

それとも、スレーブを削除し、最後に成功したバックアップから再投入し、再びスレーブに設定するという、すべての困難を経験する必要がありますか?

よろしくお願いします。

4

2 に答える 2

0

単純な変更/更新/...の場合は、スレーブのスレーブプロセスをオフにして、マスターで（手動で、またはスレーブバイナリログがある場合はスレーブバイナリログから取得して）単純に再生してから、新しいレプリケーションポインターを設定してください。 (ファイル & 位置) スレーブ (マスター ステータスを表示; マスター上)、およびスレーブを再起動しますか?

于 2012-08-30T02:38:40.303 に答える
0

答えは実際に私の顔を見つめていました (いつもではありません!)。

主キーの重複エラーは、スレーブで挿入を行い、マスターで同じテーブルに挿入したことが原因で発生しました。つまり、両方の新しいレコードに同じ ID がありました。

幸いなことに、スレーブに挿入する必要はなかったので、単純に削除しました。つまり、主キー値を持つレコードは 1 つしかありませんでした。

レコードを複製しようとするレプリケーションを取得する方法が必要だっただけで、これは簡単でした。

スレーブを再起動するだけです!

そう：

mysql root:(none)>START SLAVE;
Query OK, 0 rows affected (0.03 sec)

mysql root:(none)> _
于 2012-08-30T09:27:17.537 に答える