我试图在mysql级别为我们的生产系统devise一个简单的高可用性系统。 从我目前阅读的内容来看，最好的解决scheme是设置主 – 主复制。 不幸的是，我们不能使用虚拟IP，所以像MMM这样的脚本不能像我所想的那样被使用。
build议的解决scheme是通过haproxy连接到mysql，这将“保证”一次只能写入一个主机。 我找不到这个configuration的许多信息 – 与通常的基于虚拟IP的configuration相比有什么优点/缺点？
如果您使用的是负载均衡器（如Zeus），则可以在负载均衡器中创build一个DBVIP，并将其分配给MySQL主服务器的IP。 然后，将调度分配给循环加权循环或负载均衡器定义的其他方法。
由于我们正在谈论MySQL，请确保您真正使用多主站的思维模式。
对于初学者，确保你使用
用于Master1的/etc/my.cnf
server_id=1 auto_increment_increment=10 auto_increment_offset=1 /etc/my.cnf为Master2
server_id=2 auto_increment_increment=10 auto_increment_offset=2
然后，绝对确保在查询任何一个主logging时，不要使用auto_increment值来查询数据。 为什么？
从上面给出的configuration中，Master1将具有1作为auto_increment值的最后一个数字的表。 Master2将具有2个作为auto_increment值的最后一位的表格。
如果您的SELECT子句具有WHERE ID = 11，则该SELECT只能从Master1中检索。
你将不得不build立如下的基本规则：
地面规则＃1
所有具有auto_increment值作为PRIMARY KEY的表都将有一个额外的UNIQUE KEY来检索所需的数据。 Master1和Master2上的唯一密钥必须相同。
地面规则＃2
所有带有auto_increment值的表作为PRIMARY KEY，不能有额外的UNIQUE KEY来检索所需的数据，必须有应用程序forms的SELECT语句来设置WHERE子句来协商所select的PRIMARY KEY值，以便能够检索所需的行（例如：如果您插入数据的服务器上的server_id是2，那么您必须在代码中取ID，减去MOD（ID，10），然后添加auto_increment_offset，然后可以调用SELECT。
如果不能遵循这些规则，则必须从多主机切换到另一个复制拓扑。