mysql性能优化总结(六)

主从复制常见问题

1.主库宕机,部分操作没有写入bin-log,导致偏移量上没有操作

2.从库宕机,部分操作没有写入中继日志,导致重复读取

3.从库没有设置read_only,导致主从数据不一致

4.不唯一的server_id和server_uuid

5.max_allow_package设置引起的问题

解决办法:

1.跳过 skip

2.change master

3.设置从库只读

4.检查server_id和server_uuid

 

如何实现高可用

 

 

 如何避免mysql单点故障

1.多写集群 pxc 只有所有的服务器都写入成功才提交事务,否则回滚,有点类似于kafka的其中一种可靠性策略,

　　优点:数据完全同步

　　缺点:性能差,只支持innodb

2.NDB集群,主主复制,只支持内存模式,否则性能很差 

3.mysql主从复制,重点是解决主服务器的单点问题

 

 第三方组件两种解决方案:MMM,MHA

 

　　MMM架构

 

 

 MMM有点类似于redis的哨兵机制

MMM架构的优缺点

　　优点:

　　　　1.通过虚拟ip实现故障自动转移

　　　　2.实现了对主从同步延迟的监控,某台从服务器延迟过高时,可以切换到其他没有延迟的数据库 

　　缺点:

　　　　1.最新版本是2010年的,停更了,不支持mysql新的复制方式(gtid,多线程复制),只能支持基于日志点的复制

　　　　2.没有读负载均衡的功能

　　　　3.主从切换过程中,可能造成数据丢失或者重复执行事务

　　　　4.MMM监控成为了新的单点问题

 

　　

MHA架构

 

 

 

 1.设置所有主机免认证登录

2.配置主从复制集群

3.配置MHA管理节点

4.通过master_check_ssh和master_check_repl对配置进行检测

5.启动MHA服务

 

MHA的优缺点

　　优点:

　　　　1.支持gtid

　　　　2.切换过程中不容易发生数据丢失

　　缺点:

　　　　1.需要自己编写脚本实现vip的配置,上手难度大

　　　　2.只会对主进行监控,从挂掉不能自动剔除

　　　　3.需要基于ssh免认证配置,存在一定安全隐患

　　　　4.没有从服务器负载均衡

读写分离与负载均衡

　　1.程序实现,增加复杂度

　　2.使用中间件,macat,mysql-proxy,maxScale