4

私たちが知っているように、mysql はレプリケーションを非同期で行います。
同期レプリケーションを行うには追加のプラグインが必要だと聞きました。

それでは、非同期レプリケーションの状況を考えてみましょう。マスターはイベントをバイナリ ログに書き込みますが、master2 がそれらを取得して処理したかどうか、またはいつ処理したかはわかりません。非同期レプリケーションでは、 master1 がクラッシュした場合、コミットされたトランザクションが master2 に送信されていない可能性があります。

私の質問は、後で master1 が再起動したときに、これらのトランザクションが最終的に master2 に複製されるかどうかです。そうでない場合、それは大きな矛盾の問題です。

私の質問は、マスターとスレーブのレプリケーションについても同じで、マスターは同じ状況でダウンしています。

自動的に実行するには、特別な構成パラメーターが必要ですか?

または、master1 からデータを手動でダンプして master2 などにインポートする必要がありますか?

======

更新: 上記の「クラッシュ」という言葉を誤って使用した可能性があります。master1 が一定期間、他のユーザーとデータを同期できなかったという状況に言及したいだけです。以下の返信 (感謝) は 2 つのケースをカバーしています: たとえば、ディスク障害による実際の回復不可能なクラッシュ、またはネットワークの問題などによる一時的なオフラインの問題です。

4

2 に答える 2

4

master1 が中断後にオンラインに戻り、バイナリログが失われていない場合、レプリカは見逃したバイナリログをダウンロードできます。この説明では、master2 はレプリカです。

もちろん、master1 のクラッシュが深刻でバイナリログが破損したり失われたりした場合は、運が悪くなります。

また、master1 がデータベースに変更を書き込んだが、バイナリ ログ エントリがクラッシュで失われた場合もあります。このリスクを解決するsync_binlog=1には、master1 のトランザクションで、それぞれの binlog エントリがディスク上で安全でなければトランザクションを完了できないように設定できます。

しかし、COMMIT ごとにバイナリログをディスクに同期するとオーバーヘッドが発生し、多くのサイトではデータの安全性よりもパフォーマンスの方が優先されます。一部のワークロードでは、1 秒あたりのトランザクション率が高すぎてこれができないことは事実です。つまり、1 秒あたりのディスク同期数には物理的な上限があります。解決策は、より高速なディスク (または SSD) を入手するか、ワークロードを複数のサーバーに分散することです。

また、逆の状況も見てきました。binlog エントリが master1 のファイルシステム キャッシュに書き込まれ、レプリカがその binlog エントリをダウンロードし、レプリカがそれを適用しますが、ディスクが原因で、そのエントリは master1 のディスクに作成されません。断続的な障害が発生していました。皮肉なことに、レプリカは、マスターのディスクにコミットされなかった変更を処理していました!

同期レプリケーションの可能性について言及しました。MySQL には実際にはこのオプションがありません。最も近いのは準同期レプリケーションです。これは、少なくとも 1 つの半同期レプリカがトランザクションの binlog エントリを受信したことを確認するまで、master1 のトランザクションをコミットできないことを意味します。これは、上記のような不一致が発生しないことを意味します。ただし、これにより、すべての COMMIT にレイテンシが追加されます。

なぜ「半」同期なのですか? master1 の COMMIT は、トランザクションがレプリカで実行されるのを待つ必要がないため、レプリカが binlog イベントの受信を確認するのを待つだけで済みます。レプリカはまだ遅れる可能性があります。

@ceejayoz からのコメントはPercona XtraDB Clusterに言及しています。これは準同期レプリケーションとほぼ同じように機能します。COMMIT 中に、ライター ノードはそのトランザクションのログをクラスタ内の他のすべてのノードに送信する必要があります。したがって、レイテンシーは、最も遅いノードがイベントの受信を確認する速度です。

于 2014-01-17T21:56:02.747 に答える
1

master1がクラッシュした場合、コミットされたトランザクションはログファイルで利用可能になり、再び起動するとすぐにスレーブ (この場合はmaster2 ) に配信されます。構成によって、master1がダウンしている間にmaster2が同一の主キー値をコミットする可能性がある場合、不整合の問題が発生します。

サーバーごとに異なる主キーを割り当てることで、これを防ぐことができます。たとえば、一方は奇数のみを書き込み、もう一方は偶数を書き込みます。または、サーバー ID を使用する構成された主キーですらあります。

于 2014-01-17T21:58:22.517 に答える