3つのノードを使用したマスターマスターレプリケーション
Mysqlマスター/マスターレプリケーションを3つのノードで構成する必要があります。現在、私はマスター/スレーブ設定をしており、それを3つのノードを持つマスター/マスターに移動する必要があります。私はそれをリング構造で構成することについていくつかの記事を読みました、私はそれについて少し神経質になっています。
誰かが本番環境で同様の設定をしている場合は、これを達成する方法を教えていただければ幸いです。
マルチマスターレプリケーションを循環的に実行したくない理由はいくつかありますが、それらのほとんどは1つに要約できます：3つの異なる単一障害点。チェック この記事 （これはまさにあなたが要求したものですが、おそらく望んでいるものではありません）。標準レプリケーションは非同期であるため、データがドリフトする傾向が非常に高く、-運が良ければ-すべてのノードでレプリケーションが停止するか-運が悪ければ-ノード間の異なるデータでレプリケーションを続行できます。
5.6 GTIDとその他の機能はこれらの一貫性の問題を最小限に抑えましたが、レプリケーションはシングルマスター（マルチソースレプリケーションはMariaDBとMySQL 5.7、循環レプリケーションの必要性を否定します）。
マルチマスター（どこでも書き込める）の設定が必要な場合は、ノード間の競合を管理する別のテクノロジを使用することを強くお勧めします。 Galera （ Percona XtraDB Cluster または MariaDB Cluster の名前で見つかる場合もあります）行く方法。これはWANで機能し、競合を「解決」（ロールバックしてトランザクションを再試行）することはマルチスレッド化されており、通常のレプリケーションやクラスタリングの代わりに使用できます。目標がHAまたは読み取りスケーリングである場合に非常に推奨されます。これは無料でオープンソースであり、非常に広く利用されており（私はいくつかの銀行やホスティング会社がそれを使用するのを助けました）、標準のレプリケーションと互換性があり、標準のInnoDB（別のエンジンではない）をストレージに使用します。
もちろん、最大の短所は、理解するのに時間がかかる可能性がある別のテクノロジーであることです（おそらく他のクラスタリングテクノロジーよりも簡単ですが）、小さな癖があります。しかし、私自身の意見では、物事を「適切に機能させる」ためにそれについて学ぶ時間は価値があります。
循環レプリケーションを設定できますか？確かに、上記の記事では、log-slave-updates、auto_increment_incrementおよびauto_increment_offset各ノード。ただし、これを実行している可能性のある少数の人々は、マルチマスター書き込みを回避するか、同時実行で同じテーブルの更新と削除を実行できない非常に制御された環境で実行する必要があります。 GTIDやセミシンクレプリケーションなどを含むソリューションをオーバーエンジニアリングする人もいますが、一般に、すべての企業が、ネイティブで準備されていないプロトコルにパッチを適用するための熱意と知識を持っているわけではありません。
Jynusの以前の回答に同意します。 MariaDBのインストールは非常に簡単で、MySQLのインプレース置換を行うには多くの方法があります（あまり心配する必要はありません。知っているすべてのユーティリティとコマンドは同じです）。たとえば、MariaDBサイト自体 MariaDB Upgrade からです。 Several Nines サイトからのハードウェア設定を使用して、MariaDB/Percona/MySQL構成をシミュレートすることもできます（コンフィギュレーターを検索）
提示された機能が本当に求めているものであるかどうかを評価できるように、Galeraclusterのサイトで事前に読むことをお勧めします。個人的には、Galeraは、データベースの扱い方を大幅に変更することなく、MySQL（および「派生物」）上のHAの優れた「イネーブラー」だと思います。
ご注意ください：Galera（およびNDBタイプのクラスターではない）を使用する場合は、提案されているrsyncまたはmysqldumpの代わりにPercona XtraBackupをSST（状態スナップショット転送）に使用することを検討してください）
これまでに3つのノードで循環レプリケーションを扱いました。これが私の投稿です：
May 07, 2012： mysqlでの循環レプリケーションの設定 （最初から）Sep 24, 2012： 既存のレプリケーショントポロジでMySQL循環レプリケーションをセットアップしますか？ （2つのスレーブを持つマスターを取得し、トポロジを3ノード循環レプリケーションに変換します）
3ノードの循環レプリケーションで800のクライアントデータベース（約2 TB）を使用していたクライアントを覚えています。クライアントは、1つのDBサーバーで267個のデータベース、2番目のDBサーバーで267個のデータベース、3番目のデータベースで最後の266個の書き込みを行いました。重い書き込みがありました。ノード間にレプリケーションラグの長い間隔がありました。ビジネスのピーク時間が過ぎると、すべてのノードはSeconds_Behind_Masterが0で通常に戻りました。特定のデータベースへのすべての書き込みは特定のDBサーバーに制限されていたため、auto_increment_incrementとauto_increment_offsetは必要ありませんでした。
あなたの場合、書き込み集中型ではない小規模から中規模のデータベースがある場合、循環レプリケーションは問題ありません。私は、すべてのDB書き込みを1つのボックスに制限し、SELECTの負荷を分散します。
警告
@ jynus と @ AaronBrown の両方が複数の障害点があると言っているのは正しいことに留意してください。また、バックアップを行う際には細心の注意を払い、特定のデータベースの書き込みを固定DBサーバーに制限し、アプリがクラスター対応であることを確認する必要があります。また、フェイルオーバーを実行し、リングからノードを取り出し、ノードをリングに挿入し、サーバーの負荷を増大させることなく単一のデータベースを復元するための厳密な方法を設計する必要もあります。