web-dev-qa-db-ja.com

1つのMySQL宛先にマージする2つのMySQLソースからのリアルタイムデータをスレーブ化する方法は？

3番目のインスタンスに「スレーブ」したい2つの異なるMySQLインスタンスがあります。 （3番目のインスタンスで簡単に結合できるように）

例えば。

mysql1> show databases
db1
db2

mysql2> show databases
db3
db4

mysql3> show databases
db1
db2
db3
db4

Maatkit （percona toolkit） pt-table-syncを見てきましたが、データが破損する可能性があると言われています。 （挿入を生成するためにデータを削除および再追加することは明らかです）

pt-archiverは「スナップショット」で機能しますが、db1は約6GBであり、全体をコピーすると、実際に必要なデータよりもはるかに多くのデータが必要になります。リアルタイムの更新は1日約100MBです。

私にとっての自然な概念は、mysql3をmysql1とmysql2の両方のレプリカスレーブとして実行できるようにすることですが、それはMySQLのオプションではないようです。

Tungsten Replicator このタイプのデータ同期を許可しているようですが、構成が少し扱いに​​くいようで、信頼性が心配です。

この問題に使用した他の解決策はありますか？

mysqldatabase-mirroringmaster-slavetungsten
4
Joel K

設計上、1つのmysqldプロセスが2つの異なるマスターを同時にリッスンすることはできません。

CHANGE MASTER TOコマンドでは、読み取るソースとして1つのマスターのみを設定できます。

これをエミュレートするには、プログラムで2つのマスターを切り替える必要があります。どうやってそれをしますか？

StackOverflowで、各マスターがラップトップでスレーブが中央コンピューターであるさまざまなマスターにスレーブを手動で接続する方法について説明しました。

これが基本的な考え方です

  • マスターM1
  • マスターM2
  • スレーブS1

このようにM1からS1へ、次にM2からS1へのレプリケーションを設定します

  • 1）M1をソースとしてS1にCHANGE MASTERTOを実行させます
  • 2）スレーブを開始します。
  • 3）しばらくの間レプリケーションを実行します
  • 4）停止スレーブ;
  • 5）M2をソースとしてS1にCHANGE MASTERTOを実行させます
  • 6）スレーブを開始します。
  • 7）しばらくの間レプリケーションを実行します
  • 8）スレーブを停止します。
  • 9）ステップ1に戻ります

あるマスターから別のマスターに切り替えるたびに、SHOW SLAVE STATUS\Gから2つの値を記録する必要があります。

  1. Relay_Master_Log_file
  2. Exec_Master_Log_Pos

これらの2つの値は、マスターから送信され、次にスレーブで実行される最後のSQLステートメントを表します。

1つの大きな注意があります：M1とM2が相互に排他的なデータベースを更新している限り、このアルゴリズムは問題ないはずです。

信じられないかもしれませんが、 2011年5月にServerFaultでこのような質問に対処しました。実際には、「High PerformanceMySQL」という本に基づいてBLACKHOLEストレージエンジンを使用して真のマルチマスター/シングルスレーブをエミュレートする方法を説明しました。 ==

2
RolandoMySQLDBA

これを行うための優れた既製のツールはありません。 pt-table-syncはあなたが言われたように正確には機能しません（私はそれを書きました;）が、それは正しい解決策ではありません。意図的に切断して更新した後、サーバーを中央ソースに調整するために使用される双方向同期機能を見てきましたが、これは必要なものに適したソリューションではありません。

私は通常、このようなトピックについて売り込みをしませんが、これは正直なところ、Perconaに新しいツールの開発を依頼する場合です。個人的なシナリオに合った小さなスクリプトを書いた人もいますが、一般的に使用するための高品質のソリューションはまだ存在せず、それほど難しくはありません。重要なことは、正式なテストが必要であり、Percona Toolkitのコンポーネントはすでに必要なものの90％に到達しているということです。つまり、それらの間にほんの少しの接着剤が必要です。もちろん、これは自分で行うこともできますが、なぜ四角いホイールを作って自分でメンテナンスし、必要のないときにすべてのバグを発見するのでしょうか。

そうは言っても（売り込みを終了します、申し訳ありません）-私が提案する解決策は、ブラックホールテーブルを避け、より単純で面倒な手法を採用する必要があります。 （ええ、私もHigh Performance MySQLを作成しました。わかっています。当時、ブラックホールテーブルに関する問題は、今日ほど多くは見られませんでした。）Rolandoが提案することを大まかに行う必要がありますが、微妙な点がいくつかあります。たとえば、I/Oスレッドがマスターから大量のデータをストリーミングしてSQLスレッドよりもはるかに進んで、次のサーバーにラウンドロビンするときにすべてを破棄してはなりません。それは本当に無駄であり、マスターに多くの影響を与えます。このように注意が必要な詳細がたくさんあります。もう1つ頭に浮かぶのは、レプリケーションによって引き起こされた一時テーブルが使用されているときにマスターを切り替えないことです。

0
Baron Schwartz