我们有一个应用程序，它有一些特殊的特性，阻止我们进行主从 MySQL 复制。这与为每个会话和存储过程生成的随机数有关。
我们计划明年修复该应用程序，但与此同时，我们需要使我们的 MySQL 机器“高度可用”，那么我们有什么选择呢？普通的 RH 集群可以工作吗？我们运行 MySQL mysql-server-5.0.45-7.el5.x86_64。
谢谢您的任何建议。
答案1
我想不出任何无法设置复制以在具有适当架构的情况下生成与主服务器相同的数据集的场景。简而言之，它仍然可能是一种选择。
你可以使用以下命令设置两个服务器DRBD在后端复制数据。对于故障转移，使用Linux 高可用性.（心跳/起搏器）这将是一种主动/被动配置，它不会像没有共享存储的双主那样快速进行故障转移，但数据完整性能得到更好的保证。
MySQL 已经针对此类架构撰写了一份白皮书，名为MySQL 和 DRBD 高可用性架构。
这NDB 引擎，由MySQL 集群也可以实现高可用性架构。然而，引擎有特定的局限性，在使用前需要考虑。它对于基于事务的负载（例如通常用于 Web 应用程序的负载）来说并不理想。
答案2
我遇到的专业 MySQL 顾问的普遍共识是“如果您认为您需要 NDB，那么您可能不需要”。
DRBD 和 Heartbeat 的 +1 - 它的工作相当出色，并且不止一次在生产中拯救了我的尾巴。问题是，您的应用程序是否支持故障转移到另一个数据库服务器，或者您是否需要在数据库主机之间设置某种类似 CARP 的共享 IP？
不想越界，但您是否考虑过使用 NoSQL 解决方案（如 CouchDB）来重写您的应用程序？CouchDB 上的复制工作得非常好，而且主主（甚至 N 主）配置通常只需几分钟。值得深思。