我很乐意向师父/师父推荐Master / Slave，原因有几个
- 您有两个数据库服务器configuration为最新的二进制日志的主人
- 手动故障转移到被动主机只是一个“IP地址添加”了。
- 您可以将IPconfiguration为一个Active Master（使用ucarp ）
- 您可以将数据库写入隔离到一台机器（无论哪个主机都有DBVIP）
- 被动主人（谁没有DBVIP）可用于读取，mysqldumps，XtraBackups，tar / gzips
- 重新configuration一个奴隶成为一个新的主人，老主人到一个新的奴隶既不是快速的，微不足道的，也没有什么不寻常的，尤其是当你必须快速恢复数据库服务器。
使用主/主只有两（2）个缺点
- 如果被动主人大于0秒，则不能执行任何故障转移。 失败的时间过早，提交的数据是过时的数据，重复键的可能性可以追溯其丑陋的头，试图写入新的数据与数据中的空白。 对于低写入环境，您可以接受这种情况，因为在故障恢复之前，复制可以快速赶上。
- 两个主人的caching（MyISAM密钥caching和InnoDB缓冲池）是不一样的。 被动主控失败会导致初始服务器负载尖峰读取和写入，以获得正确的数据的数据库caching。 你可以用mk-slave-prefetch来克服这个问题，很快就会被重命名为pt-slave-prefetch（一个Percona工具包）
在灰色区域似乎是在两个主人进行数据库写入。 尽pipe发明了auto_increment_increment和auto_increment_offset选项来减轻同一个表的两个不同服务器上的auto_increment值，但真正安全地使用允许在两个服务器上进行数据库写入的master / master可以归结为两种情况：
- 所有使用PRIMARY KEYS的表不是基于自动递增的
- 写在不同的硕士互斥数据库。 换句话说，如果您将一个主数据库中的数据库写入限制为schema1，并且从不对另一个主数据库执行数据库写入模式1的操作。
更新2012-10-04 11:42 EDT
Percona XtraDB集群（PXC）已经成为一个很好的同步多主数据库。 这对于多租户数据库来说很好。
你将不得不记住以下关于PXC
- 调整InnoDB的内存需求和磁盘configuration
- 记住MyISAM上的DDL / DML没有在Galera写集复制器库中复制。 由于GRANT命令是存储引擎中立的，mysql模式中的MyISAM表被处理没有问题。 任何针对mysql.user的DML都不会被复制。
- 最弱的节点会使整个Cluster变慢，特别是在COMMIT时。 因此，确保所有节点具有相同的硬件/软件/ OS / VM / RAM /networking设置。
- 您可以针对所有节点执行适度的负载平衡写入。 集群中的节点越多。 COMMIT越慢。
- PXC与MySQL Cluster不同之处在于所有节点都包含相同的数据
谈到故障转移，任何节点都可以成为Master。 您跨群集传播读取。 对于多租户DB，您可以扩展写入（INSERT，UPDATE，DELETE），而不会造成死锁。 当写入相同的数据库时，死锁仍然可能通过群集传播。 尽职调查您的应用程序，以避免死锁。
如果可能的话，你想避免主 – 主设置。 通常最好是有一个主人和多个奴隶，如果主人不能促使一个奴隶成为新的主人。 如果您的写入负载很高，则无法执行此操作。 那么多硕士可能是有道理的。 或者你可以看看分片。
一个关键的考虑因素是您需要在整个群集中反映更新的实时性。
如果是我，我会倾向于使用服务器关联的主/主复制 – 这样，用户将可以保证立即看到他们的更新（部分中断除外）。
我需要第三方工具才能为虚拟IP做一个主 – 主mysql集群？
你需要一些智慧来处理在主/从复制中的奴隶推广，如果主人失败 – 有一个谷歌，有很多的例子。
作为prev，为了提供负载平衡和服务器亲和力，我build议运行mysqlproxy （并根据会话ID或客户端IP分配工作负载）。 根据您运行的Web服务器的数量，您可能会在每个服务器上运行一个mysqlproxy的实例。 实现服务器的亲和力没有明显logging在mysqlproxy网页 – 但你只需要学习一些卢阿！
这里有一个简单的设置复制的方法。