現在、同じ物理ラックに2台のMXサーバーがあり、それらは同じグレーリストデータベースを共有しており、すべてが正常に機能しているようです。 2つのMXの優先順位は異なり、2つの異なる物理サーバー上にあるため、2つのうちの1つに障害が発生した場合に冗長性が得られます。
(参考までに、データベースは冗長ハードウェアクラスター上の仮想マシン上にあります。dbシステムは全体として単一障害点ですが、実行されるハードウェアはそうではなく、考えられる障害モードのほとんどを排除します)
着信メールシステムの完全な冗長性を実現するために、新しい(またはペアの)MXを別のデータセンターに導入したいのですが(DNSサーバーはすでに別のDCに分散されています)、接続できませんそもそも冗長性が失われるため、まったく同じMySQLサーバー。
そのような設定でグレーリストを実装する正しい方法は何ですか?
すべての場所/ MXグループに独自のグレーリストデータベースを持たせることはできますか、それとも問題や非効率を引き起こしますか?同じサイトで同じ/異なる優先度でMXを構成する理由はありますか、それとも問題ではありませんか? (もちろん、サイトが異なれば優先順位も常に異なります)
編集/明確化:最初の返信は、MySQLレプリケーション(マスター/スレーブまたは双方向)をセットアップすることを提案するか、それを行う方法を説明しているようです:そこにいた、それを行った。必要な場合、または必要な場合は、データセンター間で双方向のMySQLレプリケーションを実行できます。
私の質問はifグレイリストデータベースを複製/共有する必要があるか、または共有知識を実装するためにhowではなく、異なるグレイリストMX間で知識を共有せずに実行できるかどうかに焦点を当てました。
最悪のシナリオは、最初の配信試行後にプライマリデータセンターがオフラインになり、セカンダリデータセンターが引き継ぎ、最初の配信試行の記録がない場合です。フォローアップ配信の試行を最初の配信試行として扱い、中継サーバーに後で再試行するように指示します。
多くの場合、遅延時間はわずか5分であるため、これは、可能な最大の遅延が約10分であることを意味します。最初の配信は0分、2回目の配信は5分、最後に受け入れられた配信は10分です。
5分以外の遅延期間が発生する可能性がある場合、最悪のケースは、データセンターに障害が発生した場合の通常の配信遅延の2倍の遅延です。
これがデータセンターのフェイルオーバー状況で許容できる場合は、グレーリストデータベースを共有する必要はありません。そうでない場合は、レプリケーションが最適です。
グレイリストはばかげて大きくもアクティブでもないと思います... MySQLデータベースでリモートデータセンターへのマスター/スレーブレプリケーションを行ってみませんか?
レプリケーションを使用して、両方の場所間でmysqlデータベースを同期することをお勧めします。
データベースの構造に応じて多くの可能性がありますが、一般的な設定は、独立したシリアルキーを生成し、それらを相互に複製するように各クラスターを構成することです。たとえば、my.cnfの場合:
auto-increment-increment = 5
auto-increment-offset = 1 ( and 2, 3, 4 , 5 on your other clusters )
クラッシュした場合、各クラスターはまだ複製されていないトランザクションのログをローカルに保持するため、反対側が起動したときにトランザクションが配信されます。
編集:わかりました。クラスターを同期する必要があります。そうしないと、各クラスターで独立して同じIPアドレスをグレーリストに登録します。これにより、実際には、グレーリストの時間がセットアップしたクラスターの数で乗算される可能性があります。ちなみに、すべてのMXエントリに同じMX優先度を設定してみませんか?