对于MySQL数据库的Master-Slave架构设计，对于一般的对可用性要求不高的系统来说，是一个不错的设计方案，但是如果对可用性要求较高，就会存在一定的问题，我们先看看Master-Slave架构的特点：一个Master作为主数据库服务器，主要功能是负责处理应用客户端的写数据处理，还担当众多Slave数据库复制数据源的角色。多个master主要是负责应用客户端的读数据处理。但是我们的Master数据库服务器难免会出现故障而停机，或者系统需要停机升级，这时就需要短暂的停机，从而导致系统无法处理写数据业务。这对于一些高可用性的系统来说是个无法接受的问题，因为很多领域的应用系统是需要24小时提供服务的。这时我们可以考虑Master-Master架构。
Master-Master架构的主要特点是：提供两个Master服务器，对应用客户端都提供读写服务，而这两个Master服务器互相将对方作为自己的Master，而自己作为对方的Slave来进行数据复制。这样，任何一方的数据修改都会复制到对方数据库。其架构图如下：
但是，需要说明的是，Master-Master架构在实际应用中，并不需要2个Master服务器端都提供写数据的服务，因为这样的架构设计仅仅是解决可用性问题，也就是解决一台Master宕机或故障后无法提供写数据服务的问题，所以正常的情况下，只需要一台Master服务器提供写数据服务，而另一台则只提供读数据服务，同时兼承担备份写数据服务的角色。而且，在小型系统中，只需要一台Master服务器，提供读写服务，另外一台则只承担备份写数据服务的角色。这些都是根据需求灵活变化的。
也许有人会问，既然这种架构2个Master都可以提供读写服务，那么为什么不都负责读写呢，这样不是读写效率更高吗？2台服务器分担写数据服务效率自然高，但是必然产生一个新的问题，那就是数据的一致性问题。2台服务器写数据容易造成数据的不一致，而且MySQL Replicaiton是异步实现机制，即使是晚更新的数据也可能被早修改的数据覆盖。
简单说说，考虑下边的案例，
第一时间点：在A服务器，更新x记录为test1.
第二时间点：在B服务器，更新x记录为test2.
第三时间点：在B服务器，通过Replicaiton获取到A服务器的bin日志，执行query, 更新x记录为test1.
第四时间点：在A服务器，通过Replicaiton获取到B服务器的bin日志，执行query, 更新x记录为test2.
通过上边的流程，很容易看出第三时间点出现了错误，B服务器获得了过期数据，造成最终A,B服务器不一致的问题。