私は 3 台のサーバー mySQL/PHP/Apache クラスターを所有しています (最大の回復力を得るためにそれぞれ異なる大陸に配置)。私は多くのアドバイスを読みましたが、どれも「これはやらないほうがいい」と言っています。
基本的に私がこれをやりたい理由は次のとおりです。
- 回復力 - 3 台のサーバーのうち 2 台がダウンしても、ユーザーはログインしてデータを表示したり、作業したりできます。
- バックアップ - 上記と同じ
- 負荷分散 - フロントエンドの負荷とバックエンドのサーバープロセスを異なるボックスに分散できます
私は percona galera を含むさまざまなオプションを検討しましたが、すべてに欠点があるようです。主な欠点は透明性です。ある時点でリンクまたはサーバーがダウンし、漠然とした BINLOG エラーが発生し、すべてが大きな問題になります...
そこで、代わりに自分でこれを実装しました。各テーブルに INSERT/UPDATE/DELETE トリガーを作成するスクリプト セットがあり、変更はすべてレプリケーション テーブルに記録されます。1 分ごとのプロセスで、これらの変更が他の 2 つのサーバーにプッシュされます。また、CHECKSUM をチェックして不一致があれば警告するプロセスもあります。
非常にうまく機能します。簡単ではないことは認めます。次のようないくつかの面倒な点があります:
- float 列タイプを使用していません (0.3434 は 0.3434 と等しくありません...)
- 自動増分キーを回避します (2 つの異なるサーバーに同時にデータが挿入されると、両方のサーバーが次の値を取得する可能性があり、相互の挿入は失敗します)。
- テーブル構造を変更する場合は、トリガー作成スクリプトを再実行してください。
そこで、私の質問は...何が問題になる可能性があるのか？どこで/なぜ失敗するのか？私が知らないことは何ですか？
答え1
上記とは逆に、これは素晴らしい質問だと思います。彼らは、自分たちが何をしたかの分析を求めているのではなく、未知の未知が何であるかという一般的な「第 4 の窓」を求めているだけです。
データ集約型アプリケーションは素晴らしい本 彼らはこれをマスター-マスターではなくマルチリーダーレプリケーションと呼んでおり、これがなぜ落とし穴を抱えているのかについてよく議論しています。ご覧のとおり、Galera と Percona のサービスではこれを実行していません。したがって、正当な理由があるに違いありません (私はまだ Blackhole を試していません)。
重要なメッセージは、テーブル構造がマルチリードレプリケーションに対応できるようにする必要があるということだと思います。つまり、2 つの新しいエントリが別のサーバーに追加された場合は、(おっしゃるとおり) 自動増分キー フィールドは不要です。ユーザー ID やタイムスタンプなどを使用するようにテーブルとアプリケーションを設計する必要があります (そのため、手作業で面倒な作業になります)。
また、データベース間でテーブルをすばやく比較し、不一致を見つけることができる適切なツールも必要になるでしょう。