mysql主从复制延迟问题

在一般生产环境，普遍通过MySQL的主从复制进行读写分离，从而减轻主服务器的压力，提高数据的读写效率。通常情况下，主从复制基本上能做实时同步。由于服务器实际运行过程中，客户端的连接服务器，读写数据不可能是均匀，在某个时间点出现大量并发连接，主服务器不断的有更新操作不断的写入，但是从服务器当某个语句在从服务器上执行的时间较长，或者某个语句要进行锁表，就会导致主服务器的SQL语句大量积压，未被同步到从服务器，这样就会导致在某个时刻主从数据不一致；还有主从复制，是通过网络进行数据传输，网络的抖动、主从服务器间的网络中断肯定会影响数据的传输，同样会造成数据的不一致。这就是主从延迟，虽说随着时间的推移，或者主服务器不在大量更新操作，主从服务器会逐步一致（网络中断除外），对于某些企业写数据时一般不做同步的查询，数据延迟就不是问题，但是一些交易型的企业（或者要求数据要求实时一致），数据的延迟是不能被接受的。
解决方案：
1、（网友给的方案）最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
2、提升主从服务器硬件性能
3、使用MySQL5.6.3以后的版本，因为mysql-5.6.3已经支持了多线程的主从复制。
虽说这些方案能一定程度上解决数据延迟，但是受MySQL主从复制的原理限制，还是会存在数据延迟的可能性的。我认为比较可行的方案还是使用MySQL Galera Cluster集群。
Mysql Galera Cluster是一套基于同步复制的多主MySQL集群解决方案,使用简单,没有单点故障,可用性高,能很好保证业务不断增长时我们数据的安全和随时的扩展。
优点：
1、同步复制,真正行级别的并发复制，各节点间无延迟且节点宕机不会导致数据丢失。
2、多主服务器的拓扑结构，可以在任意节点上进行读写。
3.自动加入新节点自动成员控制，故障节点自动从集群中移除，可提供 99.999% 的可用性。
4、客户端连接跟操作单台MySQL数据库的体验一致。
缺点:
1、目前仅支持InnoDB存储引擎,任何写入其他引擎的表，包括mysql.*表将不会复制,但是DDL语句会被复制的,因此创建用户将会被复制,但是insert into mysql.user…将不会被复制的.
2、DELETE操作不支持没有主键的表,没有主键的表在不同的节点顺序将不同,如果执行SELECT…LIMIT… 将出现不同的结果集.
3、在多主环境下LOCK/UNLOCK TABLES不支持,以及锁函数GET_LOCK(), RELEASE_LOCK()…
4、查询日志不能保存在表中。如果开启查询日志，只能保存到文件中。
5、允许最大的事务大小由wsrep_max_ws_rows和wsrep_max_ws_size定义。任何大型操作将被拒绝。如大型的LOAD DATA操作。
6、由于集群是乐观的并发控制，事务commit可能在该阶段中止。如果有两个事务向在集群中不同的节点向同一行写入并提交，失败的节点将中止。对 于集群级别的中止，集群返回死锁错误代码(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
7、XA事务不支持，由于在提交上可能回滚。
8、整个集群的写入吞吐量是由最弱的节点限制，如果有一个节点变得缓慢，那么整个集群将是缓慢的。为了稳定的高性能要求，所有的节点应使用统一的硬件。
9、集群节点建议最少3个，所有服务器数据完全一致，数据同步更新，占用硬件资源，越多数量的服务器，牺牲的硬件资源越大。
10、如果DDL语句有问题将破坏集群。