简单回顾几种MySQL复制解决方案，并解决一些误解( 二 ) _MySQL

审计数据库会更容易，因为实际执行的SQL语句就被记录在binlog中；
主从之间会有更少的数据传输；
binlog日志需要的空间更小；
不确定性SQL可能会给slave带来很大的影响；
某些操作（例如insert...select）会有性能劣势；
Statement-based复制会由于SQL优化和执行变得更慢；
slave上一些复杂SQL执行时，执行计划评估可能变得糟糕；
数据一致性问题会有更大的挑战；

Row-based 复制（基于行复制）是从MySQL 5.7.7起默认的选择，它有很多优点，改变的行会被记录在binlog中，因此它不需要上下文信息。它的其他优点如下：:

每一个改变都能被复制，所以是最安全的复制方式；
对于包含不是很多行改变的高并发操作，性能有一定的提升；
显著的改善了数据一致性；

当然，也有缺点：

网络流量显著变大，尤其当操作很多行记录的时候，可能打爆网络；
对于影响很多行的操作，Row-based就会很吃力，不擅长；
数据库操作审计变得更加困难，因为binlog中不记录SQL，取而代之的是记录变更的数据；
Row-based相比statement-based在一些场景下会更慢；

关于复制的误解
误解1: 复制就是集群
标准的异步复制不是集群，记住不管是标准的异步复制还是半同步复制，都不能保证环境服务于同一数据集。而使用集群（例如Percona XtraDB Cluster）时，这是不同的，任意一个请求打到任意一台服务器上其结果都一样。如果不是，则会从群集中删除受影响的节点。异步复制没有这样的保障，即使某个slave节点与master处于不一致状态时仍然会接受操作请求。
误解2: 复制作为手动故障转移方案
理论上来说，两个环境之间是有可比性的。然而，有许多参数能影响性能和数据一致性。只要你使用了异步复制，在master上发生的事务正确性就无法在slave上得到保障。当然，你可以通过增强持久化的配置来改善这点，但是它相应的会带来一定的性能损耗，性能和可靠之间总需要做一定的取舍。
误解3: 我有复制，所以不用备份
复制是为了对数据集有一个可访问的副本的解决方案，通过把读请求打到复制节点，能减轻master的压力。但是复制不是备份。备份一般是指离线备份，它的作用是数据库所在环境发生灾难性的破坏不可恢复时，还能通过备份恢复数据库。对数据库进行离线备份是非常重要和有意义的事情！
误解4: 因为有复制，所以数据库能负载均衡事务请求
给master增加一个slave尽管可以改善系统的可用性，但是你仍然需要自己做几件事情：把读请求打到slave上，把写请求打到master上。有很多代理工具可以完成这样的事情，当然你可以自己动手造轮子！