11

これがシナリオです。同一のテーブルを持つ 2 つの mysql データベースを持つ 2 つの別々の場所にある 2 つの Web サーバー。テーブル内のデータもリアルタイムで同一であることが期待されます。

これが問題です。以下の最初の 2 つの表に示されているように、いずれかの場所のユーザーが同一のテーブルに新しいレコードを同時に入力した場合、各テーブルの 3 番目のレコードは異なる人によって同時に入力されています。テーブル内のデータはもはや同一ではありません。更新が行われる場所に関係なく、下の 3 番目の表に示されているように、データがリアルタイムで同じままであることを維持するための最良の方法はどれですか? 以下の図では、各テーブルに 3 行で終わるのではなく、新しいレコードが双方向に複製され、両方のテーブルに挿入されて、今度は 4 列の 2 つの同一のテーブルが再び作成されます。

Server A in Location A
==============

Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | John  |
|-----------|

Server B in Location B
==============
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
|-----------|
| 3 | Peter |
|-----------|


Expected Scenario
===========
Table Names
| ID| NAME  |
|-----------|
| 1 | Tom   |
| 2 | Scott |
| 3 | Peter |
| 4 | John  |
|-----------|
4

4 に答える 4

11

データベースを 2 つのマスターにレプリケートしても、パフォーマンスはあまり向上しません。ただし、アプリケーションを正しくコーディングすると、気の利いたフェールオーバーがあります。

マスター - マスターのセットアップは、基本的にスレーブ - マスターのセットアップと同じですが、両方のスレーブが開始され、各ボックスの構成ファイルに重要な変更が加えられています。

マスター MySQL 1:

auto_increment_increment = 2
auto_increment_offset = 1

マスター MySQL 2:

auto_increment_increment = 2
auto_increment_offset = 2

これらの 2 つのパラメーターにより、2 つのサーバーが何らかの理由で主キーをめぐって競合している場合に、それらが複製されず、複製が強制終了されないことが保証されます。1 ずつインクリメントする代わりに、自動インクリメント フィールドはデフォルトで 2 ずつインクリメントします。1 つのボックスでは、1 からオフセットを開始し、1 3 5 7 9 11 13 などのシーケンスを実行します。2 番目のボックスでは、オフセットを 2 から開始します。 2 4 6 8 10 12 などに沿って実行されます。現在のテストから、自動インクリメントは、前に残った番号ではなく、次の空き番号を取るように見えます。
たとえば、サーバー 1 が最初の 3 つのレコード (1 3 と 5) を挿入し、サーバー 2 が 4 番目のレコードを挿入する場合、6 のキーが与えられます (未使用のままの 2 ではありません)。

設定したら、両方をスレーブとして起動します。
次に、両方が正常に機能していることを確認するために、両方のマシンに接続してコマンドを実行します。各ボックスで両方とも「YES」と表示されているSHOW SLAVE STATUSことに注意してください。Slave_IO_RunningSlave_SQL_Running

次に、もちろん、テーブルにいくつかのレコードを作成し、1 つのボックスが奇数番号の主キーのみを挿入し、もう 1 つのボックスが偶数番号の主キーのみをインクリメントするようにします。

次に、すべてのテストを実行して、各ボックスですべての標準アプリケーションを実行し、他のボックスに複製できることを確認します。

やってみると比較的簡単です。
しかし、前述のように、MySQL はそれを思いとどまらせており、アプリケーション コードを記述するときにこの機能に注意するようにアドバイスしています。

編集:オフセットが正しいことなどを確認すれば、理論的にはマスターを追加することは可能だと思います。ただし、より現実的には、スレーブを追加することもできます。

于 2008-11-28T14:13:53.997 に答える
2

MySQL は同期レプリケーションをサポートしていませんが、サポートしていたとしても、おそらくそれを使用したくないでしょう (トランザクション コミットごとに他のサーバーが同期するのを待つというパフォーマンス ヒットを受け入れることができません)。

それに対するより適切なアーキテクチャ上の解決策を検討する必要があります - マージを行い、事前に決められた方法で競合を解決するサードパーティ製品があります - これが本当に唯一の方法です。

アーキテクチャがこのように機能することを期待するのは単純です。MySQL だけでなく、どのデータベースにも「簡単な修正」はありません。

于 2008-11-28T13:57:32.203 に答える
1

UID が同じであることは重要ですか? または、リモート UID をローカル UID にマッピングするテーブルまたはカラムを用意し、レプリケートしたいオブジェクトのカスタム同期コードを記述して、外部キー カラムなどの UID の必要なマッピングを行うという考えを楽しませますか?

于 2008-11-28T13:49:40.677 に答える
0

テーブルが確実に同期されるようにする唯一の方法は、データベース間で双方向のレプリケーションをセットアップすることです。

ただし、MySQL は一方向のレプリケーションしか許可しないため、この構成で問題を単純に解決することはできません。

明確にするために、双方向レプリケーションを「セットアップ」できますが、MySQL ABはこれを推奨していません。

于 2008-11-28T13:45:45.707 に答える