MySQL入门篇-MySQL 8.0 延迟复制
创始人
2024-05-24 02:07:30
0

备注:测试数据库版本为MySQL 8.0

这个blog我们来聊聊MySQL 延迟复制

概述

MySQL的复制一般都很快,虽然有时候因为 网络原因、大事务等原因造成延迟,但是这个无法人为控制。
生产中可能会存在主库误操作,导致数据被删除了,Oracle有flashback技术,MySQL官方目前没有退出对应的flashback技术。
此时,我们可以通过设置延迟复制,设置从库比主库慢半个小时,这个时候就可以从从库进行数据恢复到主库了。

MySQL支持延迟复制,以便从库故意执行比主库晚至少在指定时间间隔的事务。在MySQL 8.0中,延迟复制的方法取决于两个时间戳:immediate_commit_timestamp和original_commit_timestamp。如果复制拓扑中的所有服务器都运行MySQL 8.0.1或更高版本,则使用这些时间戳测量延迟复制。如果从库未使用这些时间戳,则执行MySQL 5.7的延迟复制。

复制延迟默认为0秒。使用CHANGE MASTER TO MASTER_DELAY = N语句将延迟设置为N秒。从主库接收的事务比主库上的提交至少晚N秒才在从库上执行。每个事务发生延迟(不是以前MySQL版本中的事件),实际延迟仅强制在gtid_log_event或anonymous_gtid_log_event事件上。二进制日志中的每个GTID事务始终都以Gtid_log_event开头,匿名事务没有分配GTID,MySQL确保日志中的每个匿名事务都以Anonymous_gtid_log_event开头。对于事务中的其它事件,不会对它们施加任何等待时间,而是立即执行。注意,START SLAVE和STOP SLAVE立即生效并忽略任何延迟,RESET SLAVE将延迟重置为0。

延迟复制测试

环境要求

服务器类别IP
主库192.168.10.102
从库192.168.10.103
mysql> show slave status\G;
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.10.102Master_User: repllMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000019Read_Master_Log_Pos: 5280Relay_Log_File: hadoop103-relay-bin.000003Relay_Log_Pos: 1316Relay_Master_Log_File: mysql-bin.000019Slave_IO_Running: Yes Slave_SQL_Running: Yes

 此时已经搭建了异步复制的主从

开启延迟复制

从库

stop slave sql_thread;
CHANGE MASTER TO MASTER_DELAY = 3000;
start slave sql_thread;

主库

create table t6 as select * from dept;
select * from t6;
mysql>  create table t6 as select * from t4; 
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0mysql> 
mysql> select * from t6;
+--------+------------+----------+
| deptno | dname      | loc      |
+--------+------------+----------+
|     10 | ACCOUNTING | NEW YORK |
|     20 | RESEARCH   | DALLAS   |
|     30 | SALES      | CHICAGO  |
|     34 | faddsf     | fadsf    |
|     40 | OPERATIONS | BOSTON   |
+--------+------------+----------+
5 rows in set (0.00 sec)

从库

mysql> select remaining_delay from performance_schema.replication_applier_status;
+-----------------+
| remaining_delay |
+-----------------+
|            300 |
+-----------------+
1 row in set (0.01 sec)
mysql> select current_timestamp;
+---------------------+
| current_timestamp   |
+---------------------+
| 2020-07-29 11:00:44 |
+---------------------+
1 row in set (0.00 sec)mysql> select * from t6;
ERROR 1146 (42S02): Table 'test.t6' doesn't exist
mysql> 
mysql>  select current_timestamp;
+---------------------+
| current_timestamp   |
+---------------------+
| 2020-07-29 11:03:30 |
+---------------------+
1 row in set (0.00 sec)mysql> select * from t6;
ERROR 1146 (42S02): Table 'test.t6' doesn't exist
mysql> 
mysql> select current_timestamp;
+---------------------+
| current_timestamp   |
+---------------------+
| 2020-07-29 11:05:29 |
+---------------------+
1 row in set (0.00 sec)mysql> select * from t6;
+------+------+
| id   | name |
+------+------+
|    1 | aaa  |
+------+------+
1 row in set (0.00 sec)
mysql> select remaining_delay from performance_schema.replication_applier_status;
+-----------------+
| remaining_delay |
+-----------------+
|            NULL |
+-----------------+
1 row in set (0.01 sec)

监控延迟复制

在MySQL 8之前的老版本中,监控复制的延迟(滞后)最常用的方法之一是依赖于show slave status输出中的seconds_behind_master字段。但是,当使用比传统主从复制更复杂的复制拓扑,例如组复制时,此度量标准不再适用。MySQL 8中添加的immediate_commit_timestamp和original_commit_timestamp可提供有关复制延迟的更精细的信息。监控支持这些时间戳的复制延迟的推荐方法是使用以下performance_schema模式中的表。

replication_connection_status:与主服务器连接的当前状态,提供有关连接线程排队到中继日志中的最后和当前事务的信息。
replication_applier_status_by_coordinator:协调器线程的当前状态,仅在使用多线程复制时显示该信息,提供有关协调器线程缓冲到工作队列的最后一个事务的信息,以及当前正在缓冲的事务。
replication_applier_status_by_worker:应用从主服务器接收事务的线程的当前状态,提供有关应用程序线程或使用多线程复制时每个工作线程应用的事务信息。
使用这些表,可以监控相应线程处理的最后一个事务以及该线程当前正在处理的事务的信息,包括:

事务的GTID。
从库中继日志中检索的事务的original_commit_timestamp和immediate_commit_timestamp。
线程开始处理事务的时间。
对于上次处理的事务,线程完成处理它的时间。
除Performance Schema表之外,show slave status的输出还有三个字段与延迟复制有关:

SQL_Delay:非负整数,表示使用CHANGE MASTER TO MASTER_DELAY = N配置的复制延迟,以秒为单位。与performance_schema.replication_applier_configuration.desired_delay值相同。
SQL_Remaining_Delay:当Slave_SQL_Running_State等待主执行事件后的MASTER_DELAY秒时,该字段包含一个整数,表示延迟剩余的秒数。在它他时候,此字段为NULL。与performance_schema.replication_applier_status.remaining_delay值相同。
Slave_SQL_Running_State:一个字符串,指示SQL线程的状态(类似于Slave_IO_State)。该值与SHOW PROCESSLIST显示的SQL线程的State值相同。
当从库的SQL线程在执行事件之前等待延迟时,SHOW PROCESSLIST将其状态值显示为:Waiting until MASTER_DELAY seconds after master executed event。
参考

MySQL 8.0 延迟复制_只是甲的博客-CSDN博客

相关内容

热门资讯

如何看待网络小说抄袭现象 如何看待网络小说抄袭现象当红网络小说种类套路固定,种田文、重生文等等,极易模仿抄袭,大量雷同的类型小...
人们对“善良”有着不同的理解。... 人们对“善良”有着不同的理解。对此,你有怎样的认识?善良也要有底线,不要对别人道德绑架,不要影响别人...
求魔兽世界双采路线 求魔兽世界双采路线我的采药路线是新手村(1-60)银松森林(60-120)湿地(120-230)悲伤...
找一本热血传奇小说 主角叫林西 找一本热血传奇小说 主角叫林西能告诉我那是多久前的事情吗?传奇法师异界纵行
狄更斯的小说《远大前程》(又名... 狄更斯的小说《远大前程》(又名《孤星血泪》)中的乔原谅醒悟后的皮普了吗?当然原谅了啊乔其实一直把匹普...
黑龙江省特色文化旅游推介会开展... 来源:中国新闻网 中新网抚远7月3日电 (记者 王琳)7月2日晚,2025黑龙江省特色文化旅游推介会...
日本吐噶喇列岛12天地震逾90... 来源:新华社新华社北京7月3日电 日本西南部鹿儿岛县吐噶喇列岛及其附近海域6月21日以来地震活动频繁...
为什么经常听说物种灭绝,却从未... 为什么经常听说物种灭绝,却从未听说有新物种诞生?因为需要物种的演变需要很长很长的时间吧新物种不好诞生...
嘉欣丝绸:公司上半年外销订单饱... 每经AI快讯,有投资者在投资者互动平台提问:尊敬的董秘您好,查阅了贵公司的基本资料,发现贵公司市盈率...
两连板!业绩大幅增长 今日(7月3日)市场主要指数集体高开,美容护理、医药生物等行业领涨。盘面上,光伏玻璃概念股延续强势,...