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