今日は、MySQL Master-Masterレプリケーションが実際にどのようなタスクに役立つのか、完全に役に立たず有害なもの、それに関連する神話や誤解、このテクノロジーからすぐに得られる実用的なメリットについて説明します。 構成図とアーキテクチャ図の具体例を示します。
MySQLのマスターとマスターのレプリケーションについて話す（高可用性とパフォーマンスのコンテキストで）のは流行ですが、残念ながら、多くはその本質とテクノロジーに関連する重大な制限を理解していません。
そもそも、従来のMySQLには「実際の」マスターマスタレプリケーションはまだありません。
マスター-マスターセットアップ
Master-Masterを構成するには、IDshnikovオフセットを構成し、各サーバーに一意の識別子を設定する必要があることが知られています。
- dev.mysql.com/doc/refman/5.5/en/replication-options-master.html#sysvar_auto_increment_increment
- dev.mysql.com/doc/refman/5.5/en/replication-options-master.html#sysvar_auto_increment_offset
- dev.mysql.com/doc/refman/5.5/en/replication-options.html#option_mysqld_server-id
手順はネットワーク上で詳細に説明されており、簡単かつ迅速に行われます...しかし、最初は簡単です。 実際、成功への道のりで、多くの死体、驚き、落とし穴が見つかるでしょう:-)
結論：あなたは自分で2つのサーバーでMySQL Master-Masterを設定し、さらに理解する準備ができています。
同期性
古典的なMySQLレプリケーションが非同期であることを完全に理解する必要があります（バージョン5.6では、SEM同期レプリケーションのサポートが登場しました。これまで完全に同期していないため、 SEMが割り当てられます）。
理論を説明するために、非同期レプリケーションの問題を見てみましょう。 データベース間のデータは、任意の遅延（ミリ秒から数日）で送信されます。 スレーブを使用したマスター/スレーブアーキテクチャの場合、たとえば30秒までにアプリケーションの背後にあるデータを読み取ることはできません。 しかし、Master-Masterの場合、すべてが悪化しています。データベースのコピーが同期しているという保証はありません（SEM同期レプリケーションの場合でも）。 つまり 同じクエリを各データベースで別々に実行できます。 コマンドの同時実行：
UPDATE mytable SET mycol=mycol+1; - UPDATE mytable SET mycol=mycol*3; -
また、両方のデータベースでデータの同期がとれなくなります（ CoddとDateが許してくれるかもしれません）。
同じ一意の列値（自動インクリメントではありません！）を両方のデータベースに同時に挿入すると、レプリケーションが誤って停止します。 そのような不気味な例はたくさんあります。
また、「ON DUPLICATE KEY UPDATE」などのソリューションがエラーなどを無視して推奨される場合もありますが、同時にアプリケーションをシャベルで処理することもありますが、常識的には、このようなアプローチは滑りやすく信頼性が低いことが示唆されています。
私は、明らかに、アプリケーションがどのような崩壊と矛盾につながる可能性があると思います。
結論：非同期マスターマスターを使用して、落とし穴を知らずに両方のデータベースに同時に書き込むことは危険で信頼性が低く、まれに使用されます。
魔法の指輪
MySQLサーバーをリングに統合することは技術的に可能です。 ただし、前述の問題はさらに深刻になります。リングに沿ったレコードの分布に関連する非決定性が追加されます。ノード1と3で同時に更新し、ノード2で一度に更新できます。 各ノードで何が起こるかを考えるのは怖いです。 そして、そのような複製経済を維持することは「完全な喜び」であり、システム管理者の悪夢です。
MySQL同期レプリケーションのサポート
さて、真の同期マスターマスタレプリケーションのコンテキストでは（データの整合性が保証され、すべてのクラスターノードに同時に書き込むことができる場合）、 Galeraについて多くの話があります。 誰かがこれのためにあなたが長い間知られているMySQL NDB Clusterを使用することを試みることができると言うでしょう-しかし、この「ジャイロプレーン」はめったにウェブの世界からのアプリケーションの非常に狭いサークルに適さないことが広く知られています。
ガレラを興味を持ってフォローしています-将来的に本物のマスター-マスタークラスターが構築される可能性がありますが、今のところ、既存の十分にテストされた安定したツールから何が学べるかを見ていきます。
非同期MySQLマスターマスタレプリケーションの利点
しかし、すべてがそれほど悲しいわけではありません。 従来のMySQL Master-Slaveレプリケーションをどれだけscったとしても、
- 非同期（ノード上のデータ同期解除、遅延...）
- 信頼性が不十分です（flush_log_at_trx_commit = 1、sync_binlog = 1、sync_relay_log = 1、sync_relay_log_info = 1、sync_master_info = 1、時には不十分であり、サーバーの再起動時にレプリケーションが失敗します）
- 不十分なトランザクションサポート（この機能が実装されている Percona Serverパッチのおかげ）
この「主力製品」は非常に広く使用されており、システム管理者に多くの利点と幸福をもたらします。
- ホットな「ほぼ」最新のバックアップを作成する
- MySQLスレーブで読み取り値をクラスタリングするため
- 垂直シャーディング用（どのテーブルをどのスレーブに転送するかをフィルタリングします）
- データベースバトルサーバーをロードせずにmysqldumpを使用してスレーブサーバーを安全にバックアップするため
- その他
非同期マスター間レプリケーションは、すぐに「有用な馬」に変えることができます。 通常、このアーキテクチャは、マスター-マスター（アクティブ-パッシブ）と呼ばれます。
アイデアは簡単です。1つのデータベースに書き込み、2番目のデータベースはホットバックアップとして使用され、必要に応じてデータの書き込みをすばやく開始できます。 このアーキテクチャにこのような有用性とHighAvailabilityを与えるのは、「データの書き込みをすぐに開始する」ことです。
少し吸ったことは......
少しタバコを吸って考えてみると、この「働き者」のもう1つのすばらしい応用例がわかります。これは、ローカルデータセンターでの事故に耐える能力です。 ホットデータベースを別のデータセンターのマスター-マスター（アクティブ-パッシブ）に保持するだけで、別の大陸で行うことができます。
はい、書き込み中のデータセンターの矢印は不要になりましたが、画像認識の整合性に任せましょう:-)
それでは、データセンターにローカルなクラスターを受け取って、このアーキテクチャの測定値をスケーリングすることを誰も禁止していません。
スレーブサーバーのウィザードで更新のログを記録するオプションを有効にすることを忘れないでください。
リスク
正直なところ、このような複製スキームは非常に確実に機能し、AmazonクラウドのBitrix24およびソリューション「地理的Webクラスター」で正常に使用されています 。 その動作の特徴は次のとおりです。
- ステートメントベースのレプリケーションモードで始めましょう。 MySQLログにこのモードでこのクエリを実行するのは危険であるというメッセージが表示される場合、 スレーブでの実行順序は異なる場合があります-「混合」レプリケーションモードを有効にします（これには、InnoDBのトランザクション分離モードをRepeatable Readに増やす必要があります）。 行ベースを含めることはお勧めしません。
- パフォーマンスが心配な場合は、flush_log_at_trx_commit = 1、sync_binlog = 1、sync_relay_log = 1、sync_relay_log_info = 1、sync_master_info = 1（sarcasm :-)）のパラメーターを含めないでください。 つまり、MySQLの緊急再起動後にレプリケーションを最後の位置から手動で上げる必要がある場合があります。mysqlbinlogコマンドをマナで吸うと、多くの興味深く有用なものを見つけることができます。
- 一方のレプリケーションを上げるまでバランサーを戻さないようにしてください-そうしないと、データの混乱が始まります（そしてCoddとDateが二度目に許せなくなるかもしれません:-)）。
「そしてコンポート？」
DC間のコンテンツの同期を忘れていました。 ここではすべてが基本的に標準です。
バルーンファイル用のクラウドストレージ -Clodo.ru 、 Selectel.ru 、Amazon S3、Google Storageなど。 CDNの集中的な使用。 csync2、rsync、およびその他の同様のツールを使用したDC間の静的転送。 通常、問題はありません。
このトピックに関する読み物
linux-haプロジェクトを見る価値があり、bashで簡単にできるようです;-) Galeraは非常に有望に見えます。 また、MySQLが最終的に「本物の」マスター/マスターレプリケーションを要求するようになりました。
そしてもちろん、私は完全に忘れていました-マスター-マスター（アクティブ-パッシブ）間でデータが同期していない可能性があります。 これは、mysqlのクラッシュ、サーバーの突然の再起動、レプリケーション位置の喪失、コードのエラーが原因で発生します。 大丈夫、治療法があります-より複雑です：
このシンプルなbashスクリプトのようにシンプルです（大きなテーブルでは使用しないでください）：
#!/bin/bash DATABASES=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -B -N -e"SHOW DATABASES" | grep -vE '(^binlogs$)|(^performance_schema$)|(^test.*$)|(^information_schema$)'` for DB in $DATABASES; do TABLES=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -B -N -D $DB -e"SHOW TABLES" for TABLE in $TABLES; do CS_L=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -D $DB -B -N -e"CHECKSUM TABLE $TABLE" | awk '{print $2}'` CS_R=`mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_R -D $DB -B -N -e"CHECKSUM TABLE $TABLE" | awk '{print $2}'` if [ "$CS_L" != "$CS_R" ]; then echo "${DB}-${TABLE} : DIFF" mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_L -D $DB -B -N -e"SELECT * FROM $TABLE" > /var/tmp_data/table_diff_${SHARD_L}.tmp mysql -u root -p${MYSQL_ROOT_PASSWORD} -h $SHARD_R -D $DB -B -N -e"SELECT * FROM $TABLE" > /var/tmp_data/table_diff_${SHARD_R}.tmp diff -u /var/tmp_data/table_diff_${SHARD_L}.tmp /var/tmp_data/table_diff_${SHARD_R}.tmp rm -f /var/tmp_data/table_diff_${SHARD_L}.tmp /var/tmp_data/table_diff_${SHARD_R}.tmp else echo "${DB}-${TABLE} : OK" fi done done
まとめ
Bitrix24プロジェクトでは、説明したテクノロジーを集中的に使用します。これは、何度も助けてくれました。 今年の6月15日にAmazonのデータセンターに最後にドロップしたことは、顧客に気付かれずに済みました。別のDCのバックアップマスターに自動的に切り替えました。
この記事では、将来的にこのテクノロジーの隠された意味を探さないように、棚に関するMySQL Master-Masterトピックを整理しました。 ネットの落とし穴について、危険で説明が不十分なものを調査しました。 彼らは、別のデータセンター（別の大陸）でホットMySQLマスターサーバーを提供するために、シンプルで実用的なマスターマスタ（アクティブパッシブ）アプリケーションを選択し、すべてのレプリケーションノードのデータが異なることを恐れずに休暇中にシスダミンを使用できるようになりました（もはやありません）リレーショナル理論の創設者の父親の名前に言及しています）または雷がデータセンターを襲います:-)皆さん、幸運、気分と信頼できる複製！