mysql复制

如何提升mysql主从复制延迟

几个思路，也有可能会衍生新的问题

• 从库是SSD硬盘。
• 尽量避免主库大量的写入，异步写。
• 主库和从库直接使用专用网络，高速互联。
• 对于数据一致性要求严格的，不要查从库。
• 减少从库压力，例如使用多个从库。

备注：主从复制延迟只能缓解，严格意义上说无法解决的。

 

 

MySQL延时复制库

1、延迟复制作用

存在即合理，延迟复制可以用来解决以下三类问题：

• 用来在数据库误操作后，快速的恢复数据。比如有人误操作的表，那么这个操作在延迟时间内，从库的数据并没有发生变化，可以用从库的数据进行快速恢复。
• 用来做延迟测试，比如你做好的数据库读写分离，把从库作为读库，那么你想知道当数据产生延迟的时候到底会发生什么。那么你就可以使用这个特性也模拟延迟。
• 用于老数据的查询等需求，比如你经常需要查看某天前一个表或者字段的数值，你可能需要把备份恢复后进行查看，如果有延迟从库，比如延迟一周，那么就可以解决这样类似的需求。

 

2、具体操作：

登陆到Slave数据库服务器

mysql>stop slave;

mysql>CHANGE MASTER TO MASTER_DELAY = 600；

mysql>start slave;

mysql>show slave status \G;

查看SQL_Delay的值为600，表示设置成功。

 命令注释：

• SQL_Delay：一个非负整数，表示秒数，Slave滞后多少秒于master。
• SQL_Remaining_Delay：当 Slave_SQL_Running_State 等待，直到MASTER_DELAY秒后，Master执行的事件，
• 此字段包含一个整数，表示有多少秒左右的延迟。在其他时候，这个字段是0。

参考文章：http://mp.weixin.qq.com/s/fi4WcmdcOgYFNJAsziqNcQ

 

Mysql复制

MySQL复制是一个非常简单而有方便进行架构扩展的功能，可以说是运维必备，我们通过对主从进行不同的组合，可以满足我们相应的需求。

架构场景：

• 一主一从，高可用
• 一主一从，读写分离
• 一主多从，读写分离
• 一主多从，负载均衡
• 主主复制，双写
• 主主复制，单写
• 双主双从

1、一主一从，高可用

架构说明：最传统的一主一从，如果主库发生故障，手动将从库提升为主库，从库仅用于故障恢复。

2、一主一从，读写分离

架构说明：还是一主一从，在客户端实现读写分离，不过需要注意主从延时的情况。

提示：在写比较度的表上可以在Master不建立索引，而在Slave端来建立索引。 可以一个主库，两个从库，一个从库做备份，一个从库做读。

3、一主多从，读写分离

架构说明：和一主一从类似，在读请求比较多的情况下，可以增加MySQL从节点。

提示：可以在客户端实现多个从节点的轮询和权重的设置。

4、一主多从，负载均衡

架构说明：在对读需求场景比较多的情况下，为了不频繁的对客户端进行配置变更，可以在从库前端放置负载均衡。不过在slave比较多的时候。主从复制也会给MySQLMaster带来一些性能上和带宽上的压力。

提示：给Slave分配不同的角色。例如延迟从库、灾备从库、数据仓库等。

5、主主复制，双写

架构说明：主主复制其实就是MySQL的双向复制，两台机器互为主从，双主可以同时写，不过要处理好自增ID重复问题，例如设置使用奇偶插入 。

6、主主复制，单写

架构说明：还是主主复制，不过这次单写，也就是双主当主从。既可以保证写的高可用，又可以保证读的高可用。

提示：这个是两台机器的最佳方案。

7、双主双从

架构说明：在主主复制，单写的时候。如果一个主宕机，那么就读写另外一个主。可读的节点就剩下了一个。对于读需求比较多的业务可能会有问题，那么双主双从就可以解决这个问题。

提示：复杂的架构带来的肯定是运维的难题。

参考文章：http://mp.weixin.qq.com/s/B30SScTCUQ85vfDSfCsNBw

 

Mysql高可用解决方法

1、Mysql mha方案

参考文章：http://www.cnblogs.com/gomysql/p/3675429.html

 

2、MySQL半同步复制

 

MySQL DAL（Data Access Layer）中间件

参考文章：https://www.unixhot.com/article/75