1.如何解决主从复制延迟的问题?
(1)主从复制原理
- 1.salve执行slave start,salve服务IO线程会通过授权的用户连接上master,并请求master从指定的文件和位置之后发送bin-log日志内容
- 2.master服务器接收到来自slave服务器的IO线程请求后,master服务器上的IO线程根据slave服务器发送的指定bin-log日志之后的内容,然后返回给slave的IO线程,返回的信息中出了bin-log日志内容wait,还有本次返回日志内容后在master服务器端新的binlog文件名已经在binlog中的下一个指定更新位
- 3.slave的IO线程接收到信息后,将接收到的日志内容依次添加到salve端的relay-log文件的最末端,并将读取到的master端的bin-log的文件名和位置记录到master-info文件中,以便下一次读取的时候能够清楚的告诉master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”、
- 4.slave的SQL线程检测到relay-log中新增了内容后,会马上解析relay-log的内容成为master端真实执行时候的那些可执行的内容,并在自身执行。
(2)产生延迟的原因
- 1.主从复制是单线程操作,异步进行
- 2.master的binlog是顺序读写,效率高、吞吐量高,DDL/DML是并发操作的
- 3.slave的relay-log实施的时候,DML和DLL是随机操作且Slave_SQL_Running是单线程的,如果还有lock争用,成本就更高了
- 4.master TPS并发高峰时,产生的DDL数量超过slave一个sql线程所能承受的范围,延迟就产生了
- 5.
max_allowed_packet
主从不一致 - 6.自增ID起始位置不一样
- 7.主高从低版本不一致,新特性不兼容
(3)解决延迟问题
- 1.主库DDL快速执行DDL操作
- 2.主库设置
双1
,sync_binlog=1 innodb_flush_log_at_trx_commit=1
- 3.从库上可以设置为
双0
- 4.
slave_net_timeout
slave读取log数据失败后,等待多久重新建立连接并获取数据 - 5.
master-connect-retry
重新建立主从连接时,如果连接失败,重试的等待时间 - 6.从库使用更好的硬件
- 7.专用slave服务器,专用读服务器,专用备份服务器
- 8.使用semi_sync插件进行半同步,损失性能
2.如何判断主从复制是否同步?
(1)show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较的差值
(2)如果Relay_master_Log_File
== Master_Log_File
Read_Master_Log_Pos
==Exec_Master_Log_Pos
,则认为是同步的- 主库
show master status\G
的Position
与从库的Read_Master_Log_Pos
相等,也是同步的
(3)使用第三方工具
mk-heartbeat,Maatkit
3.以下参数设为1怎么理解?
set global sql_slave_skip_counter=1;
https://dev.mysql.com/doc/refman/5.6/en/set-global-sql-slave-skip-counter.html
- (1)从库需要跳过某个无法执行的命令,在slave stop的状态下设置
global sql_slave_skip_counter=N
,跳过接下来的N个事件
一个event group包含多个有序的events
一个insert包含三个event,begin/insert/commit
对于事务性的表,一个event group代表一个事务
对于非事务性的表,一个event group代表一个单独的SQL语句
- (2)N=1,会跳过若干个event,直到当前所在事务结束
- (3)N>1,则每跳过一个event都要N--
原文地址:https://www.cnblogs.com/jenvid/p/8495397.html
时间: 2024-10-01 03:23:38