ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

xtrabackup全备+binlog恢复到某一时间点-启用GTID

2020-08-17 18:01:40  阅读:527  来源: 互联网

标签:session binlog log relay xtrabackup scott mysql GTID


背景说明:3306端口数据库,做一次xtrabackup全备之后,删除表,模拟恢复到 3308 端口数据库。
采用模拟slave线程恢复的方式,速度更快。
当恢复的场景是从全备恢复某一张表时,也可以使用复制过滤功能,只应用对应表的binlog,不用全部binlog都恢复。
前提:数据库启用了GTID,即,my.cnf需要有如下参数:
master_info_repository = TABLE
relay_log_info_repository = TABLE
gtid_mode = on
enforce_gtid_consistency = 1


先做一次完整备份:
innobackupex --defaults-file=/etc/my.cnf --user root --password Jimstars /data/mysqlbak

执行完命令后,/data/mysqlbak 目录下会生成目录: 2020-08-17_09-56-57

多切换几次 binlog日志
mysql -uroot -pJimstars -e "flush logs;"

插入测试数据
mysql -uroot -pJimstars scott -e "create table liang_test(id int,name varchar(200));"
mysql -uroot -pJimstars scott -e "insert into liang_test values (20001,'full_bak');"


多切换几次 binlog日志
mysql -uroot -pJimstars -e "flush logs;"

再插入测试数据
mysql -uroot -pJimstars scott -e "insert into liang_test values (20002,'full_bak2');"

多切换几次 binlog日志
mysql -uroot -pJimstars -e "flush logs;"

再插入测试数据
mysql -uroot -pJimstars scott -e "insert into liang_test values (20003,'full_bak3');"

多切换几次 binlog日志
mysql -uroot -pJimstars -e "flush logs;"


假设在这里误删除了表
root@localhost:mysql.sock/scott> drop table liang_test;
Query OK, 0 rows affected (0.02 sec)

root@localhost:mysql.sock/scott> show master status;
+---------------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------------------+----------+--------------+------------------+------------------------------------------+
| VM_0_15_centos-bin.000014 | 384 | | | 5c5286d8-a94c-11ea-9333-52540088b727:1-5 |
+---------------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)


多切换几次 binlog日志
mysql -uroot -pJimstars -e "flush logs;"


创建另外的测试表,作为对比参考,如果是按照指定点恢复,下面创建的表不应该被恢复出来
mysql -uroot -pJimstars scott -e "create table tttt like t1;"
mysql -uroot -pJimstars scott -e "insert into tttt select * from t1;"


解析binlog,找到误删除操作对应的 GTID :
mysqlbinlog --base64-output=DECODE-ROWS -vv -d scott VM_0_15_centos-bin.000014 > /tmp/scott.log


[root@VM_0_15_centos mysql]# grep -C 30 liang_test /tmp/scott.log
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#200817 16:29:35 server id 2003306 end_log_pos 123 CRC32 0xafb8dca3 Start: binlog v 4, server v 5.7.22-log created 200817 16:29:35
# at 123
#200817 16:29:35 server id 2003306 end_log_pos 194 CRC32 0xf66f1562 Previous-GTIDs
# 5c5286d8-a94c-11ea-9333-52540088b727:1-4
# at 194
#200817 16:29:51 server id 2003306 end_log_pos 259 CRC32 0x069e0356 GTID last_committed=0 sequence_number=1 rbr_only=no
SET @@SESSION.GTID_NEXT= '5c5286d8-a94c-11ea-9333-52540088b727:5'/*!*/;
# at 259
#200817 16:29:51 server id 2003306 end_log_pos 384 CRC32 0x8513f6e8 Query thread_id=23 exec_time=0 error_code=0
use `scott`/*!*/;
SET TIMESTAMP=1597652991/*!*/;
SET @@session.pseudo_thread_id=23/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=268435456/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=45/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP TABLE `liang_test` /* generated by server */
/*!*/;
# at 384
#200817 16:30:17 server id 2003306 end_log_pos 440 CRC32 0xd44e7a4f Rotate to VM_0_15_centos-bin.000015 pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

 


从上述日志,可以得出我们要找出的点为: 5c5286d8-a94c-11ea-9333-52540088b727:5


恢复全备,这里采用恢复本地端口 3306的数据库 恢复到 3308
innobackupex --apply-log /data/mysqlbak/2020-08-17_16-28-46
innobackupex --defaults-file=/etc/my_3308.cnf --copy-back /data/mysqlbak/2020-08-17_16-28-46
chown -R mysql.mysql /data/mysql_3308


拷贝binlog 到 /data/mysql_3308
cp /data/mysql/VM_0_15_centos-bin.0* /data/mysql_3308
chown -R mysql.mysql /data/mysql_3308


将binlog改名为relay log
rename "bin" "relay-bin" VM_0_15_centos-bin.0*
ls ./VM_0_15_centos-relay-bin.0* > mysql-relay.index
chown -R mysql.mysql /data/mysql_3308


[mysqld] 中设置参数
relay_log = /data/mysql_3308/mysql-relay.index

# server_id 必须设置和原来实例的 server_id 不一样,不然不会应用 binlog
server_id=2003308
# relay_log_recovery=1时,relay log 会在MySQL重启、复制线程启动时被清除
relay_log_recovery=0
# 开启并行复制
slave-parallel-type=LOGICAL_CLOCK
# 设置work线程数量
slave_parallel_workers=8
# 设置redo log异步刷盘,每秒1次
innodb_flush_log_at_trx_commit=0
# 设置binlog刷盘策略
sync_binlog = 0

 

启动MySQL。
mysqld --defaults-file=/etc/my_3308.cnf &

建立复制通道:
mysql> CHANGE MASTER TO MASTER_HOST='1.1.1.1',RELAY_LOG_FILE='VM_0_15_centos-relay-bin.000001',RELAY_LOG_POS=154;


##确认slave sql thread的起始位置和设置的一样
mysql> select * from mysql.slave_relay_log_info;


启动复制前,如果只需要恢复指定表,可以使用复制过滤功能,加快binlog回放速度:
mysql> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('scott.liang_test');


启动复制线程,到误删除那个事务停止:
mysql> START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS = '5c5286d8-a94c-11ea-9333-52540088b727:5';


如果是恢复全部binlog,则
mysql> start slave sql_thread;


恢复到生产环境
binlog应用结束后可以从error log中看到提示信息:
2020-08-17T09:30:51.827494Z 2 [Note] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='1.1.1.1', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.
2020-08-17T09:30:56.594750Z 3 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'FIRST' at position 0, relay log '/data/mysql_3308/VM_0_15_centos-relay-bin.000001' position: 154
2020-08-17T09:30:56.716703Z 3 [Note] Slave SQL thread stopped because it reached UNTIL SQL_BEFORE_GTIDS 5c5286d8-a94c-11ea-9333-52540088b727:5


接下来把误操作的表导出,再导入到生产环境。


标签:session,binlog,log,relay,xtrabackup,scott,mysql,GTID
来源: https://www.cnblogs.com/liang545621/p/13519023.html

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

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有