MySQL运维实战之备份和恢复(8.7)将数据库恢复到指定时间点2

云的事随心讲 2024-03-14 18:39:22
使用mysql原生复制功能实现时间点恢复使用mysqlbinlog解析并执行binlog是实现mysql时间点恢复的一种常用的方法。这里提供另外一种实现时间点恢复的方法:使用mysql的复制功能来实现。 方法如下: 1、启动一个空的mysql实例,将需要恢复的binlog注册到该实例。 2、待恢复实例上,从binlog实例复制数据。 启动binlog实例初始化一个空白实例: ## 创建相关目录mkdir -p /data/servebinlog/{data,log,binlog,relaylog,tmp,run}## 准备my.cnf## 初始化数据库/opt/mysql/bin/mysqld --defaults-file=/data/servebinlog/my.cnf --initializetail -1 /data/servebinlog/log/alert.log2023-06-26T08:54:33.758630Z 6 [Note] [MY-010454] [Server] A temporary password is generated for root@localhost: ar2sWPCf4.++## 修改文件owner,并启动实例chown -R mysql:mysql /data/servebinlog/mysqld_safe --defaults-file=/data/servebinlog/my.cnf # 修改默认密码,创建复制账号mysql -uroot -par2sWPCf4.++ -h127.0.0.1 -P16380mysql> alter user 'root'@'localhost' identified by 'abc123';Query OK, 0 rows affected (0.01 sec)mysql> create user 'rep'@'%' identified by 'rep123';Query OK, 0 rows affected (0.02 sec)mysql> grant replication slave on *.* to 'rep'@'%';Query OK, 0 rows affected (0.01 sec)注册binlog: 将需要的binlog复制到binlog实例相关目录,并编辑binlog.index文件,重启binlog实例。 ## 停实例mysqladmin -h127.0.0.1 -P16380 -uroot -pabc123 shutdown## 清空原有binlog,将需要的binlog复制到指定目录rm /data/servebinlog/binlog/binlog.00000*cp /data/mysql8.0/binlog/binlog.0000{20,21,22} /data/servebinlog/binlog/## 编辑binlog.index,最终内容如下# cat /data/servebinlog/binlog/binlog.index/data/servebinlog/binlog/binlog.000020/data/servebinlog/binlog/binlog.000021/data/servebinlog/binlog/binlog.000022## 启动实例chown -R mysql:mysql /data/servebinlog/mysqld_safe --defaults-file=/data/servebinlog/my.cnf &到这一步,binlog实例准备完成, mysql> show binary logs;+---------------+-----------+-----------+| Log_name | File_size | Encrypted |+---------------+-----------+-----------+| binlog.000020 | 5598638 | No || binlog.000021 | 4751928 | No || binlog.000022 | 3944712 | No || binlog.000023 | 237 | No |+---------------+-----------+-----------+mysql> select @@gtid_purged\G*************************** 1. row ***************************@@gtid_purged: 0b06b27c-13ff-11ee-8d21-fab81f64ee00:1-3,58224b02-09b7-11ee-90bd-fab81f64ee00:1-13191,7caa9a48-b325-11ed-8541-fab81f64ee00:271 row in set (0.00 sec)mysql> select @@gtid_executed\G*************************** 1. row ***************************@@gtid_executed: 0b06b27c-13ff-11ee-8d21-fab81f64ee00:1-3,58224b02-09b7-11ee-90bd-fab81f64ee00:1-51514,7caa9a48-b325-11ed-8541-fab81f64ee00:271 row in set (0.00 sec)从binlog实例复制数据查看全备的binlog位点: # cat xtrabackup_binlog_infobinlog.000020 610 58224b02-09b7-11ee-90bd-fab81f64ee00:1-13191,7caa9a48-b325-11ed-8541-fab81f64ee00:1-27到需要进行时间点恢复的实例上执行: mysql> reset slave all;Query OK, 0 rows affected, 1 warning (0.03 sec)mysql> change master to master_host='172.16.121.234', master_port=16380, master_user='rep', master_password='rep123', get_master_public_key=1, master_log_file='binlog.000020', master_log_pos=610;Query OK, 0 rows affected, 9 warnings (0.13 sec)mysql> start slave until master_log_file='binlog.000021', master_log_pos=340009;Query OK, 0 rows affected, 3 warnings (0.03 sec)等待SQL线程执行完成,执行完成的标志是Slave_SQL_Running=No,并且Relay_Master_Log_File和Exec_Master_Log_Pos和start slave until命令中指定的位点一样。 mysql> show slave status\G*************************** 1. row *************************** Slave_IO_State: Waiting for source to send event Master_Host: 172.16.121.234 Master_User: rep Master_Port: 16380 Connect_Retry: 60 Master_Log_File: binlog.000023 Read_Master_Log_Pos: 237 Relay_Log_File: relaylog.000004 Relay_Log_Pos: 340210 Relay_Master_Log_File: binlog.000021 Slave_IO_Running: Yes Slave_SQL_Running: No...... Exec_Master_Log_Pos: 340040和直接使用mysqlbinlog解析binlog并执行的方法对比,使用binlog实例进行时间点恢复需要创建一个临时空白实例,看起来更加复杂,但是具备以下优点: 1、更加可靠。使用了mysql原生的复制代码来执行binlog,比使用mysqlbinlog解析binlog并执行更可靠。 2、效率更高。如果开启了多线程复制,应用binlog的效率会更高。 3、更容易处理异常。如果应用binlog的过程中遇到各种错误,可以像处理一个普通的备库遇到的问题那样来处理。 正式的环境中,更推荐使用binlog实例来进行时间点恢复。 binlog恢复注意事项使用备库产生的binlog恢复数据时,需要注意备库是否有延迟。如果备库本身存在延迟,那么备库上生成的binlog的时间戳和真实的业务时间可能存在偏差,依据这个时间来进行恢复,就可能达不到业务上的恢复目标。 所以进行时间点恢复时,优先选择使用主库的binlog来进行恢复。当然在实际业务场景中,主备库之间可能会存在角色切换,需要想办法确定待恢复的时间点上,哪一个实例是主库。 我们也需要监控好主备库的复制状态,如果存在复制中断、复制延迟、甚至是主备库数据不一致的情况,需要及时处理。不然,在对备库进行的备份可能实际上是无效的。 更多技术信息请查看云掣官网云掣YunChe - 可观测运维专家 | 大数据运维托管 | 云MSP服务
0 阅读:20

云的事随心讲

简介:感谢大家的关注