MySQL relaylog + SQL_Thread 增量恢复binlog
一、设置3308实例的已经执行过的gtid号为当天全量备份结束时的gtid号
查看当天xtrabackup全量备份时结束的binlog文件名,binlog的pos 位置点,以及全量备份结束后的Gtid号:
使用xtrabackup工具恢复当天的全量备份到新的mysql 3308 实例:
给新实例3308的数据目录./data授权mysql用户权限:
启动mysql 启动成功:
由于mysql 3306和3308 都是开启gtid的,所以恢复全量备份数据到3308实例上,在启动3308实例后产生Gtid和实际的xtrabackup全量备份结束的Gtid号是不一样的,所以在恢复全备份到3308后,
启动并登录3308实例,reset master 清空当前的3308上的Gtid,然后再set global gtid_purged=‘bde7b592-b966-11e9-8c64-000c294f3e61:1-10296’; 让3308 实例的Gtid号执行到全量备份结束时的这个Gtid号
二、开始MySQL relaylog + SQL_Thread 增量恢复binlog演示
3308 实例slave上操作:
2.1 change命令,是为了告诉MySQL自己为一个slave实例:
随便change master to master_host=“192.168.1.10”;
通过change命令,是为了告诉MySQL自己为一个slave实例,因为无需用到IO_Thread,故host,password,user等可以随意填写。
并且通过该步骤,生成relay.info文件。
2.2 关闭3308实例,将需要增量的binlog文件伪装成relaylog:
并且给予伪装后的relay-log文件对应的权限mysql的权限
2.3、删掉relay.info文件和修改relay-log.index文件:
2.4、告诉3308 slave的sql_thread增量的relaylog文件要从哪个文件名以及pos位置点开始执行:
** 该选项用于告诉SQL_Thread从哪个relay log文件以及pos位置点(也就是3306实例上当天的全量备份结束的binlog文件名和pos位置点)开始执行relay log文件恢复数据到slave 3308实例
也就是说在恢复全量备份的数据到3308 上后,接下来就是利用伪装好的relay log文件(也就是3306实例上当天的全量备份结束的binlog文件名和pos位置点)+sql_thread 线程 开始执行relay log文件恢复数据到slave 3308实例**
三、此恢复的方式总结
优点:
可以断点恢复,人为控制进度,比如stop slave或者遇到错误时,可以断点恢复。
性能好,在大量binlog的情况下,可以加快恢复速度。
在某些版本可以利用多线程复制来加快增量速度,时恢复更快。
缺点:
需要关闭mysqld。
手动执行过程较mysqlbinlog方式更为复杂。
四、解决疑惑如下:
Q1整体上看binlog和relay-log结构是否是一致的???
答:整体上看binlog和relay-log结构上是一致的
Q2 binlog的filename和relay-log的filename是不是有关系?
答:没必然的关系的
Q3 把Binlog手工改成Relay-log是不是可行?
答:是可以的
Q4 Relay-log相关的记录信息有哪些?
五、利用SQL_thread快速恢复增量过程总结:
1.不能使用master_auto_position=1
2.先要让mysql知道他是一个Slave
3.关掉mysql,构建relay-log
4.利用change master to relay_log_file=… ,
relay_log_pos=…;
5.START SLAVE SQL_THREAD UNTIL MASTER_LOG_FILE=‘xxx’,MASTER_LOG_POS=xxxxx
或者START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS=‘xxx–xx-x’;
参考博文地址:
下面的恢复方法参考文档:
http://blog.itpub.net/29773961/viewspace-2143726/