MySQLデュアルマスター

Question

現在のプロジェクトでは、地理的に離れたセットアップ用にデュアルマスターレプリケーショントポロジをセットアップすることを考えています。 1つは米国東海岸にあり、もう1つは日本にあります。 誰かがこれを試してみて、そこにどんな経験があったか興味があります。

また、この問題を解決するための他のオプションが何か興味があります。メッセージキューを検討しています。

ありがとう！

Answer 1

計画の技術的側面に注意してください。MySQLマルチマスターレプリケーションを公式にサポートしていません（同期レプリケーションのサポートはMySQL Clusterのみが提供しています）。

ただし、少なくとも1つの「ハック」があります。これにより、通常のMySQLレプリケーション設定でもマルチマスターレプリケーションが可能になります。可能な解決策については、Patrick Galbraithの＆quot; MySQL Multi-Master Replication＆quot; を参照してください。私はこのセットアップの経験がないので、このアプローチがどの程度実現可能かを判断する勇気はありません。

Answer 2

データベースを地理的に複製する際に考慮すべきことがいくつかあります。パフォーマンス上の理由でこれを行う場合は、レプリケーションモデルが「最終的に一貫した」データをサポートしていることを確認してください。両方または多くの場所でレプリケーションを最新の状態にするには時間がかかる可能性があるためです。ロケーション間のスループットまたは応答時間が良好でない場合、アクティブレプリケーションは最適なオプションではない可能性があります。

Answer 3

mysqlをデュアルマスターとして設定することは、正しく実行された適切なシナリオで実際に正常に機能します。しかし、あなたのシナリオにうまく適合するかどうかはわかりません。

まず第一に、mysqlでのデュアルマスターセットアップは実際にはリングセットアップです。サーバーAはBのマスターとして定義され、Bは同時にAのマスターとして定義されているため、両方のサーバーがマスターとスレーブの両方として機能します。レプリケーションは、スレーブが適切と判断したときに挿入するsqlステートメントを含むバイナリログを出荷することで機能します。これは通常すぐに実行できます。しかし、ローカルの挿入でそれを叩いている場合は、追いつくのに時間がかかります。スレーブの挿入は順次行われるため、複数のコアなどの利点は得られません。

デュアルマスターmysqlの主な用途は、自動フェールオーバーを使用してサーバーレベルで冗長性を持たせることです（多くの場合、Linuxでlistenbeatを使用します）。 （さまざまな理由で）mysql-clusterを除くと、これはmysqlで使用できる唯一の自動フェールオーバーです。基本的なデュアルマスターのセットアップは、 google で簡単に見つけることができます。ハートビートの処理はもう少し手間がかかります。しかし、これは実際には単一のデータベースサーバーとして動作するため、あなたが求めていたものではありません。

常にローカルデータベースに書き込む（両方に同時に書き込む）ためにデュアルマスターセットアップが必要な場合は、これを念頭に置いてアプリケーションを記述する必要があります。データベースに自動インクリメント値を含めることはできません。また、一意の値がある場合、2つの場所が同じ値を書き込まないようにする必要があります。たとえば、ロケーションAは奇数の一意の番号を書き込み、ロケーションBは偶数の一意の番号を書き込むことができます。その理由は、サーバーが常に同期していることが保証されないため、Aに一意の行を挿入し、2番目のサーバーが追いつく前に重複する一意の行をBに挿入した場合、システムが壊れている。そして、何かが最初に壊れると、システム全体が停止します。

要約すると、それは可能ですが、この上にビジネスソフトウェアを構築する場合は、非常に慎重につま先を傾ける必要があります。

Answer 4

MySQLレプリケーションの1対多のアーキテクチャのため、複数のマスターでレプリケーションリングを作成する必要があります。つまり、それぞれがループ内の次からレプリケーションを行います。 2つの場合、それらは互いに複製します。これはv3.23からサポートされています。

私が以前働いていた場所で、私たちはあなたが求めているものを正確に提供する方法として、かなりの数の顧客とv3.23でそれを行いました。インターネットを介したSSHトンネルを使用して複製を行いました。信頼性を得るには時間がかかり、あるデータベースから別のデータベースへのバイナリコピーを数回行う必要がありました（残念ながら、2Gbを超えるものも24時間アクセスする必要もありませんでした）。また、v3のレプリケーションはv4ほど安定していませんでしたが、v5でも、何らかのエラーを検出すると停止します。

不可避のレプリケーションラグに対応するために、 AUTOINCREMENT フィールドに依存しないようにアプリケーションを再構築しました（そしてテーブルからその属性を削除しました）。これは、私たちが開発したデータアクセスレイヤーのおかげで、比較的簡単でした。新しいオブジェクトに mysql_insert_id（）を使用する代わりに、最初に新しいIDを作成し、残りの行とともに挿入しました。また、 BIGINT であるため、IDの上半分に格納したサイトIDも実装しました。これは、3つの場所にデータベースを必要とするクライアントがいたときに、アプリケーションを変更する必要がないことも意味していました。 ：-）

100％堅牢ではありませんでした。 InnoDBは単に可視性を獲得していたため、トランザクションを簡単に使用することはできませんでしたが、それを検討しました。そのため、同じIDで2つのオブジェクトを作成しようとしたときに競合状態が発生することがありました。これは、1つが失敗したことを意味し、アプリで報告しようとしました。しかし、複製を監視し、壊れたときに問題を修正することは、依然として誰かの仕事の重要な部分でした。重要なのは、同期が外れすぎる前に修正することです。いくつかのケースでは、データベースは両方のサイトで使用されており、再構築する必要があるとすぐに再統合が困難になるためです。

参加するのは良い運動でしたが、二度とやりません。 MySQLではありません。