MySQL 主从延迟复制方法总结

mysql 5.6开始已经支持主从延迟复制,可设置从库延迟的时间.延迟复制的意义在于:主库误删除对象时,在从库可以查询对象没改变前状态.

方法介绍

1.percona公司pt-slave-delay工具

主库:

[[email protected] ~]$ login

Logging to file ‘/tmp/master.log‘

Warning: Using a password on the command line interface can be insecure.

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 18500

Server version: 5.6.28-log MySQL Community Server (GPL)

Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type ‘help;‘ or ‘\h‘ for help. Type ‘\c‘ to clear the current input statement.

[email protected] [(none)] 04: 16: 08 >

[email protected] [(none)] 04: 16: 08 >use test;

Database changed

[email protected] [test] 04: 16: 16 >insert into tb values(1,‘chuck‘);

Query OK, 1 row affected (0.03 sec)

[email protected] [test] 04: 16: 27 >commit;

Query OK, 0 rows affected (0.00 sec)

从库查询:

[email protected] [test] 04: 16: 52 >show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.168

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000033

Read_Master_Log_Pos: 1006

Relay_Log_File: localhost-relay-bin.000063

Relay_Log_Pos: 1176

Relay_Master_Log_File: mysql-bin.000033

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 1006

Relay_Log_Space: 1353

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 7618d547-5d81-11e7-b9ec-b083fee71372

Master_Info_File: mysql.slave_master_info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:2052039-2052041

Executed_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:1-2052041,

c7a64be9-61e6-11e7-9697-b083fee71372:1-3

Auto_Position: 1

1 row in set (0.00 sec)

[email protected] [test] 04: 17: 05 >select * from tb;

+------+-------+

| id   | val   |

+------+-------+

|    1 | chuck |

+------+-------+

1 row in set (0.00 sec)

可以看到主从现在状态是正常的.

设置延迟

[[email protected] ~]$ pt-slave-delay --delay=1m --interval=15s --run-time=10m u=root,p=mysql,h=localhost,P=3307 --socket=/usr/local/mysql/mysql1.sock

从库状态改变

设置延迟后从库停止了sql_thread线程:Slave_SQL_Running: No

[email protected] [test] 04: 19: 05 >show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.168

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000033

Read_Master_Log_Pos: 1812

Relay_Log_File: localhost-relay-bin.000063

Relay_Log_Pos: 1739

Relay_Master_Log_File: mysql-bin.000033

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 1569

Relay_Log_Space: 2159

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: NULL

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 7618d547-5d81-11e7-b9ec-b083fee71372

Master_Info_File: mysql.slave_master_info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State:

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:2052039-2052044

Executed_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:1-2052043,

c7a64be9-61e6-11e7-9697-b083fee71372:1-3

Auto_Position: 1

1 row in set (0.00 sec)

主库再插入一条记录

[email protected] [test] 04: 17: 29 >insert into tb values(2,‘chuck‘);

Query OK, 1 row affected (0.02 sec)

[email protected] [test] 04: 22: 10 >commit;

Query OK, 0 rows affected (0.00 sec)

延迟日志

[[email protected] ~]$ pt-slave-delay --delay=1m --interval=15s --run-time=10m u=root,p=mysql,h=localhost,P=3307 --socket=/usr/local/mysql/mysql1.sock

2017-07-21T16:22:04 slave running 0 seconds behind

2017-07-21T16:22:04 STOP SLAVE until 2017-07-21T16:23:04 at master position mysql-bin.000033/1569

2017-07-21T16:22:19 slave stopped at master position mysql-bin.000033/1569

2017-07-21T16:22:34 slave stopped at master position mysql-bin.000033/1812

2017-07-21T16:22:49 slave stopped at master position mysql-bin.000033/1812

2017-07-21T16:23:04 no new binlog events

2017-07-21T16:23:19 slave stopped at master position mysql-bin.000033/1812

2017-07-21T16:23:34 START SLAVE until master 2017-07-21T16:22:34 mysql-bin.000033/1812

可以看到大概一分钟后,从库开启sql_thread线程.

从库记录

[email protected] [test] 04: 24: 24 >select * from tb;

+------+-------+

| id   | val   |

+------+-------+

|    1 | chuck |

|    2 | chuck |

+------+-------+

2 rows in set (0.00 sec)

2.使用CHANGE MASTER TO MASTER_DELAY 单位为秒

[email protected] [(none)] 04: 50: 02 >stop slave;

Query OK, 0 rows affected, 1 warning (0.00 sec)

[email protected] [(none)] 04: 50: 04 >CHANGE MASTER TO MASTER_DELAY = 60;

Query OK, 0 rows affected (0.04 sec)

[email protected] [(none)] 04: 50: 10 >start slave;

Query OK, 0 rows affected (0.01 sec)

[email protected] [(none)] 04: 50: 14 >show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.168

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000033

Read_Master_Log_Pos: 1812

Relay_Log_File: localhost-relay-bin.000002

Relay_Log_Pos: 408

Relay_Master_Log_File: mysql-bin.000033

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 1812

Relay_Log_Space: 616

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 7618d547-5d81-11e7-b9ec-b083fee71372

Master_Info_File: mysql.slave_master_info

SQL_Delay: 60

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set:

Executed_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:1-2052044,

c7a64be9-61e6-11e7-9697-b083fee71372:1-3

Auto_Position: 1

1 row in set (0.00 sec)

主库插入记录

[email protected] [test] 04: 55: 44 >insert into tb values (3,‘chuck‘);

Query OK, 1 row affected (0.02 sec)

[email protected] [test] 04: 55: 55 >commit;

Query OK, 0 rows affected (0.00 sec)

从库查询主从状态

[email protected] [(none)] 04: 56: 06 >show slave status\G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.0.168

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000033

Read_Master_Log_Pos: 2055

Relay_Log_File: localhost-relay-bin.000002

Relay_Log_Pos: 408

Relay_Master_Log_File: mysql-bin.000033

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 1812

Relay_Log_Space: 859

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 14

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: 7618d547-5d81-11e7-b9ec-b083fee71372

Master_Info_File: mysql.slave_master_info

SQL_Delay: 60

SQL_Remaining_Delay: 46 //预计还有多长时间延迟

Slave_SQL_Running_State: Waiting until MASTER_DELAY seconds after master executed event

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:2052045

Executed_Gtid_Set: 7618d547-5d81-11e7-b9ec-b083fee71372:1-2052044,

c7a64be9-61e6-11e7-9697-b083fee71372:1-3

Auto_Position: 1

1 row in set (0.00 sec)

大概一分钟后数据在从库应用.

[email protected] [(none)] 04: 56: 38 >select * from test.tb;

+------+-------+

| id   | val   |

+------+-------+

|    1 | chuck |

|    2 | chuck |

|    3 | chuck |

+------+-------+

3 rows in set (0.00 sec)

时间： 2024-10-29 19:12:43

MySQL 主从延迟复制方法总结的相关文章

MySQL主从延迟复制实践及生产故障案例恢复实践

1.1 MySQL主从延迟复制介绍 从MySQL5.6开始支持了主从延迟复制,这个功能主要解决的问题是,当主库有逻辑的数据删除或错误更新后,所有的从库都会进行错误的更新,从而导致所有的数据库数据异常,即使有定时的备份数据可以用于数据恢复,特别是数据库数据量很大时,恢复时间会很长,再恢复期间数据库数据被删或错误数据影响正常的访问体验. 而延迟复制就可以较好的解决这个问题.例如,可以设定某一个从库和主库的更新延迟1小时,这样主库数据出问题以后,1个小时以内发现,可以对这个从库进行无害恢复处理,使之依

实时刷新缓存-处理mysql主从延迟的一些设计方案

概要: 在项目开发当中,经常有这样一种场景,对数据库进行添加.修改.删除操作的应用直接连接master库,只对数据库进行查询的应用,会先建立一个中央缓 存,例如redis或者memcache,如果缓存没有命中,那么直接访问slave库.下文会介绍一下在刷新中央缓存时,如果发生主从延迟,应该如何处 理.也即是,当应用System-A 把数据库写入master库的时候,System-B应用在读取slave库的时候,master库的数据还没同步到slave库,如果这个时候刷新缓存 的话,会直接把旧的数

MySQL 主从延迟几万秒 Queueing master event to the relay log（转）

数据库版本Server version:    5.6.24-log Source distribution 问题描述 数据采集平台业务数据库由于批量灌数据导致主从延迟上万秒. 复制线程长期处于Queueing master event to the relay log状态. 监控数据显示1.Seconds_Behind_Master 维持在6w秒左右,且有上升趋势.2.主库有大量的binlog积压无法同步到从库,但主从库的网卡流量都很低远未达到瓶颈.3.从库的qps与tps很低,维持在几百左右

MySQL主从延迟现象及原理分析详解

一.现象 凌晨对线上一张表添加索引,表数据量太大(1亿+数据,数据量50G以上),造成主从延迟几个小时,各个依赖从库的系统无法查询数据,最终影响业务. 现在就梳理下主从延迟的原理. 二.原理 根据 MySQL 官方文档 MySQL Replication Implementation Details 中的描述,MySQL 主从复制依赖于三个线程:一个线程(),两个线程(和).主从复制流程如下图: master 服务器和 slave 服务器连接时,创建以发送数据: 一个对应一个 slave 服务器

MySQL主从延迟原因以及解决方案

1.MySQL数据库主从同步延迟原理. 谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高:slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还

MySQL 主从延迟监控脚本(pt-heartbeat)

对于MySQL数据库主从复制延迟的监控,我们可以借助percona的有力武器pt-heartbeat来实现.pt-heartbeat通过使用时间戳方式在主库上更新特定表,然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟.本文主要是通过脚本来定期检查从库与主库复制的延迟度并发送邮件,供大家参考. 有关pt-heartbeat工具的安装可以参考:percona-toolkit的安装及简介    有关pt-heartbeat工具的介绍可以参考:使用pt-heartbeat监控主从复制延

mysql主从延迟设置

Mysql (需5.6以上版本)延迟复制配置,通过设置Slave上的MASTER TO MASTER_DELAY参数实现: CHANGE MASTER TO MASTER_DELAY = N: N为多少秒,该语句设置从数据库延时N秒后,再与主数据库进行数据同步复制 具体操作: 登陆到Slave数据库服务器 mysql>stop slave; mysql>CHANGE MASTER TO MASTER_DELAY = 600: mysql>start slave; mysql>sho

mysql主从同步延迟原因及解决方法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高. slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还可

MySQL主从同步延迟原因及解决办法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高. slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还可