当前位置:Gxlcms > 数据库问题 > mysql 主从相关

mysql 主从相关

时间:2021-07-01 10:21:17 帮助过:7人阅读

Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理,大事务导致的延迟,slave中有大型query语句产生了锁等待
关于大事务:binlog的写入时机是在commit的时候,redo的写入时机是在事务执行阶段就开始,MySQL是基于binlog复制的,如果有一个非常大的事务,如果需要1个小时,那么master在1小时候后才会生成binlog,而此时,slave就比master慢了至少1个小时,还不算是binlog传输时间

主从同步延时查询方法

show slave status 命令输出的Seconds_Behind_Master参数的值来判断:
NULL,表示io_thread或是sql_thread有任何一个发生故障;
0, 该值为零,表示主从复制良好;
正值,表示主从已经出现延时,数字越大表示从库延迟越严重

数据丢失隐患解决

从MySQL5.5开始,MySQL已经支持半同步复制了,半同步复制介于异步复制和同步复制之间半同步复制,也叫 semi-sync 复制,指的就是主库写入 binlog 日志之后,就会将强制此时立即将数据同步到从库,从库将日志写入自己本地的 relay log 之后,接着会返回一个 ack 给主库,主库接收到至少一个从库的 ack 之后才会认为写操作完成了。

同步延时解决(show status:Seconds_Behind_Master)

1.硬件层面:硬盘采用SSD替代sata,主从要在一个交换机下并且保证带宽
2.从文件系统本身进行优化:可以通过设置文件系统的mount属性,阻止操作系统写atime信息。
3.加入memcache或者redis的cache层,特殊业务查询时候优先从缓存中进行查询,降低从库数据库服务的压力。
4.并行复制,mysql 5.7.19 + 版本支持并行复制,指的是从库开启多个线程,并行读取 relay log 中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。如果说某个库的写入并发就是特别高,单库写并发达到了 2000/s,并行复制还是没意义。
5.直接禁用slave端的binlog
6.slave端,如果使用的存储引擎是innodb,innodb_flush_log_at_trx_commit =2
7.分库,将一个主库拆分为多个主库,每个主库的写并发就减少了几倍,此时主从延迟可以忽略不计。
8.如果说大事务对于binlog的产生有极大的影响,那么我们认为定义小事务,大事务不允许执行,有大事务的监控,可以基于时间,可以基于数据量,监控到不符合规范的trx自动kill

mysql 主从相关

标签:flush   丢失   定义   ati   输出   异步   mit   完成   存储引擎   

人气教程排行