目前，我们在同一物理机架中拥有两台 MX 服务器，它们共享同一个灰名单数据库，一切似乎运行良好。两台 MX 具有不同的优先级，并且位于两台不同的物理服务器上，因此如果其中一台发生故障，我们就会获得冗余。
（仅供参考，数据库位于冗余硬件集群上的虚拟机上：虽然整个数据库系统是单点故障，但它运行的硬件不是，从而消除了大多数可能的故障模式）
我们想在不同的数据中心引入一个新（或一对）MX，以实现传入邮件系统的完全冗余（我们的 DNS 服务器已经分布在不同的 DC 上），但我们不能将其连接到同一个 MySQL 服务器，因为这首先会破坏冗余。
在这样的设置中实现灰名单的正确方法是什么？
我可以让每个位置/MX 组都有自己的灰名单数据库吗？或者这会带来任何问题或效率低下？是否有理由在同一站点中配置具有相同/不同优先级的 MX，或者这无关紧要？（当然，不同的站点总是有不同的优先级）
编辑/澄清：第一条回复似乎建议设置 MySQL 复制（主/从或双向）或解释如何执行此操作：我曾经这样做过。如果需要/想要，我可以在数据中心之间建立双向 MySQL 复制。
我的问题集中在如果我需要复制/共享灰名单数据库，或者如果我可以在不同的灰名单 MX 之间不共享知识，则不需要如何实现知识共享。
答案1
最糟糕的情况是，如果您的主数据中心在首次尝试传送后离线，则辅助数据中心将接管，并且它没有首次尝试传送的记录。它将后续的传送尝试视为首次尝试传送，并会告诉中继服务器稍后再试。
由于延迟时间通常只有 5 分钟，这意味着最大可能的延迟约为 10 分钟。首次投递时间为 0 分钟，第二次投递到不同的邮件服务器时间为 5 分钟，最终接受投递时间为 10 分钟。
考虑到可能出现 5 分钟以外的延迟时间，最坏的情况实际上是数据中心发生故障时正常传输延迟的两倍。
如果在数据中心故障转移情况下您可以接受这一点，那么您就不需要共享灰名单数据库。如果不能，那么复制将是可行的方法。
答案2
我猜灰名单并不是太大或太活跃...为什么不在 MySQL 数据库上到远程数据中心进行主/从复制？
答案3
我建议您使用复制在两个位置之间同步您的 mysql 数据库。
根据数据库的结构，有很多种可能性，但常见的设置是配置每个集群以生成独立的串行密钥并使它们相互复制。例如在 my.cnf 中：
auto-increment-increment = 5
auto-increment-offset = 1 ( and 2, 3, 4 , 5 on your other clusters )
如果发生崩溃，每个集群都会在本地保存尚未复制的事务的日志，以便当另一方启动时可以传递事务。
编辑：好的，您需要同步您的集群，否则您将在每个集群上独立地将相同的 IP 地址列入灰名单，这实际上可能会将灰名单时间乘以您设置的集群数量。顺便问一下，为什么不为所有 MX 条目设置相同的 MX 优先级？