标签：slave relay MySQL master 延时 mysql 从库 主从

目录

• 一、延时复制
  • 1.配置延时复制（已经有主从）
  • 2.配置延时复制（没有主从）
  • 3.关闭延时从库
  • 实例

一、延时复制

延时从库只做备份，不提供任何对外服务，正常情况下我们是不会有刻意延迟从库的需求的，因为正常的线上业务自然是延迟越低越好。
但是针对测试场景，业务上偶尔需要测试延迟场景下业务是否能正常运行。

# 延时复制流程：
和异步复制类似，同样是将主库的binlog日志通过dump线程发送给从库的中继日志中，但是当执行SQL的线程时，
会根据配置的延时复制时长，sql线程等到了延迟时间之后再执行中继日志中的sql语句了。

# 注意：
延时从库恢复数据时不要关闭主库的binlog，实际上从库还是会执行主库执行错的语句，只不过又执行了重建语句

1.配置延时复制（已经有主从）

1.停止主从
mysql> stop slave;
Query OK, 0 rows affected (0.03 sec)

2.配置延时时间
mysql> change master to master_delay=180;
Query OK, 0 rows affected (0.01 sec)

3.开启主从
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

2.配置延时复制（没有主从）

1.搭建出一台mysql
2.配置主从
mysql> change master to
    -> master_host='172.16.1.51',
    -> master_user='rep',
    -> master_password='123',
    -> master_log_file='mysql-bin.000001',
    -> master_log_pos=424,
    -> master_delay=180;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
3.开启线程
mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

3.关闭延时从库

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> change master to master_delay=0;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

实例

#关于延时复制如何恢复思考问题：
总数据量级500G，正常备份去恢复需要1.5-2小时
1）配置延时3600秒
mysql>CHANGE MASTER TO MASTER_DELAY = 3600;

2）主库
drop database db;

3）怎么利用延时从库，恢复数据？
提示：
1、从库relaylog存放在datadir目录下
2、mysqlbinlog 可以截取relaylog内容
3、show relay log events in 'db01-relay-bin.000001';


#处理的思路：
1）停止SQL线程
mysql> stop slave sql_thread;

2）截取relaylog到误删除之前点
relay-log.info 获取到上次运行到的位置点，作为恢复起点
分析relay-log的文件内容，获取到误删除之前position
模拟故障处：

1）关闭延时
mysql -S /data/3308/mysql.sock
mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_DELAY = 0;
mysql> start slave;

2）模拟数据
mysql -S /data/3307/mysql.sock
source  /root/world.sql
use world;
create table c1 select * from city;
create table c2 select * from city;

3）开启从库延时5分钟
mysql -S /data/3308/mysql.sock
show slave status \G
mysql>stop slave;
mysql>CHANGE MASTER TO MASTER_DELAY = 300;
mysql>start slave;
mysql -S /data/3307/mysql.sock
use world;
create table c3 select * from city;
create table c4 select * from city;

4）破坏，模拟删库故障。(以下步骤在5分钟内操作完成。)
mysql -S /data/3307/mysql.sock
drop database world;

5）从库，关闭SQL线程
mysql -S /data/3308/mysql.sock
stop slave sql_thread;

6）截取relay-log
起点：
cd /data/3308/data/
cat relay-log.info
./db01-relay-bin.000002
283
终点：
mysql -S /data/3308/mysql.sock
show relaylog events in 'db01-relay-bin.000002'
db01-relay-bin.000002 | 268047 
mysqlbinlog --start-position=283  --stop-position=268047 /data/3308/data/db01-relay-bin.000002 >/tmp/relay.sql 
恢复relay.sql

1）取消从库身份
mysql> stop slave;
mysql> reset slave all;

2）恢复数据
mysql> set sql_log_bin=0;
mysql> source /tmp/relay.sql
mysql> use world
mysql> show tables;

标签：slave,relay,MySQL,master,延时,mysql,从库,主从
来源： https://www.cnblogs.com/tcy1/p/13377994.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。