在一般生产环境, 普遍通过 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 语句有问题将破坏集群.
来源: http://www.bubuko.com/infodetail-2928574.html