スタートポロジのMySQL

Question

MySQL5.1のすべてのデータを含む1つの中央データベースがあります-lastest-stable。マスターとマスターの関係で複数のクライアントを接続したいと思います。

質問
1つのクライアントでの変更が最初に伝播されるように、複数のクライアントデータベースを備えた中央に1つの中央サーバーを備えたスタートポロジをセットアップするにはどうすればよいですか中央サーバーに、そこから他のすべてのクライアントデータベースに？

データベース情報
すべてのテーブルにinno-dbを使用しており、バイナリログを有効にしました。
それ以外に、データベース間でマスターマスターを実行する方法を学びました。
すべてのテーブルには、主キーの主整数の自動インクリメントがあります。自動インクリメントのオフセットと開始が異なるクライアントに合わせて調整されている場合、データベースで主キーの競合が発生することはありません。

なぜこれが欲しいのですか
ラップトップ上のローカルMySQLデータベースに接続するクライアントソフトウェア（WebサイトやPHPではない）があります。これは中央データベースに同期する必要があります。これにより、ラップトップでプログラムを使用するすべての人が他のすべてを見ることができます。他の人々が行う変更。
ラップトップと中央データベースの間でインターネット接続が切断されるとアプリケーションが停止するため、中央データベースに直接接続したくありません。
このセットアップでは、アプリケーションは続行され、中央データベースへの接続が再確立されるまで、ラップトップは他の人から更新を取得しません。

RolandoMySQLDBA · Accepted Answer

あなたが提案したことをMyISAMとInnoDBで達成することが不可能である特定の理由があります。

スタートポロジは、マスターがスレーブではなく宇宙の中心であることを保証します。 MySQL Replicationは、スレーブが複数のマスターから同時に読み取られるようには設計されていません。一度に1つのマスターからのみ読み取ることができます。 CHANGE MASTER TO コマンドは、スレーブを1つだけのマスターに接続します。

本によると MySQL Internalsを理解する、小見出しの下の219ページの段落2 "マルチマスター」は次のように述べています。

MySQLレプリケーションは、もともとマルチマスターサポートを念頭に置いて作成されたものではありません。スレーブは、ネイティブで1つのマスターのみを複製できます。非常に単純なパッチを作成して、1つのスレーブが競合を解決せずに複数のマスターから更新を収集できるようにすることができます。これは一度に実行されましたが、いくつかの理由により、ソースツリーのメインブランチになりませんでした。ある時点で、いくつかの競合解決を可能にするより複雑なパッチが計画されましたが、いくつかの理由で開発に至りませんでした。将来的に実装される可能性があります。

この本 高性能MySQL：最適化、バックアップ、レプリケーションなど は、364ページ（第8章）の上部にボックスがあります。：レプリケーショントポロジ）タイトルが "MySQLはマルチマスターレプリケーションをサポートしていません"。ボックスには次の段落があります。

マルチマスターレプリケーションという用語は、複数のマスターを持つスレーブを表すために非常に具体的に使用されます。あなたが言われたかもしれないことに関係なく、MySQLは（他のいくつかのデータベースサーバーとは異なり）現在、図8-6に示されている構成をサポートしていません。ただし、この章の後半でマルチマスターレプリケーションをエミュレートするいくつかの方法を示します。

残念ながら、多くの人がこの用語を何気なく使用して、この章の後半で示す「ツリー」トポロジなど、トポロジ全体に複数のマスターが存在するセットアップを説明しています。サーバーが相互にマスターとスレーブであるレプリケーション。

これらの用語の問題は多くの混乱や議論さえも引き起こすので、名前には注意するのが最善だと思います。 MySQLが2つのマスターを持つスレーブのサポートを追加した場合、通信がどれほど難しいか想像してみてください。目的のために「マルチマスターレプリケーション」を予約していない場合、どの用語を使用して説明しますか？

「マルチマスターレプリケーションのエミュレート」という小見出しの下にある373〜375ページに記載されているエミュレーション手法は、理論的には可能であり（BLACKHOLEストレージエンジンを使用）、2つのマスターのみをエミュレートするように他のユーザーによって正常に実装されていますが、提案された特定のトポロジをサポートすることはできません。。

私は 前のこの質問 に対処しました。実際、私がそこで与えた答えは、常に成功しています。これが、保険のセールスマンがラップトップを人の家に持ってきて、保険を申請している人の保険データを収集できる理由です。セールスマンは最終的に中央コンピュータに接続して、新しいクライアントのアプリケーションをダウンロードします。次に、中央コンピュータは最新の保険数理情報をダウンロードして、保険契約が申請者にかかる費用を按分することができます。ラップトップを中央のコンピューターに接続する場合と同じ前提で、一度に1台のラップトップで動作します。

lg. · Answer

それは可能ではありません、Mysqlはマルチマスター-マスター循環レプリケーションのみをサポートします。

この記事このレプリケーションについてよく説明しています。

Kromey · Answer

重要な更新私は訂正されたままです。理論的には、ここで述べたことはすべて健全で有効ですが、MySQLは、私が知らない理由により、実際にはマルチマスターレプリケーションをサポートしていません。ただし、他のデータベースサーバーはこの種のトポロジをサポートしているため、真のマスターマスタースタートポロジが必要な場合は、別のサーバーに変更する必要があります。

私は@lgに同意しません、それは可能だと思います。（この「答え」には詳細が欠けていることを事前に申し訳ありません。私の前にMySQLデータベースがなく、これまでにこれを行ったことがありませんが、コメントに収まる以上のものがあります。）

MySQLマスターマスターレプリケーションでは、両方のサーバーがマスターとスレーブの両方の役割を果たします。同様に、master-master-etcの循環反復では、すべてのサーバーが再びマスターとスレーブの両方になります。

別の角度から見ると、MySQLは1つのマスターサーバーを複数のスレーブに複製することができます。これは前の仕事でセットアップしました（マスターから3つのスレーブ）。

マスターもスレーブになることができ、マスターが複数のスレーブを持つことができること、および複製されたステートメントを（次のスレーブが取得するために）binlogに入れることができることを（循環レプリケーションの仕組みから）知っているためです。）andサーバーは、自身のマスターのbinlogで自身のステートメントを識別できます（これにより、循環レプリケーションシナリオで「最初の」サーバーが維持されます）自身のステートメントを再度複製し、それらを無限ループに保つことから）、複数のマスターのスレーブである複数のスレーブにサービスを提供する単一のマスターをセットアップできることは非常に合理的です（これも可能ですが、 MySQLは、複数のサーバーの単一のリアルタイムバックアップを目的としたマルチマスターレプリケーションをサポートしているためです）。

さて、これを設定する方法の詳細を提供できないことを認めます。この非常に非正統的な設定では、（もしあれば）多くのサポートが得られない可能性があることをすぐに認めますが、ここにあります始めるためのいくつかのヒント：

すべてのサーバーは、レプリケートされたステートメントをログに記録するように設定する必要があります（@lgがリンクされている記事のように、通常の循環レプリケーションのように）。
「スポーク」（より適切な用語がないため）サーバーは、中央の「ハブ」サーバーとのマスターマスター関係でセットアップする必要があります。

これは簡単にテストできるはずです。マスターとマスターの関係ですでに2つを設定しているので、中央の「ハブ」にしたい方とマスターとマスターの関係で3つ目を設定します。次に、レプリケーションが希望どおりに機能するかどうかを確認します（ただし、手順1を覚えておいてください。通常のマスターマスターは、レプリケートされたステートメントをbinlogに入れないと思います）。