7.5 Point-in-Time (Incremental) Recovery Using the Binary Log 使用binay log 基于时间点恢复

时间:2023-01-01 09:19:15
7.5 Point-in-Time (Incremental) Recovery Using the Binary Log  使用binay log 基于时间点恢复

7.5.1 Point-in-Time Recovery Using Event Times
7.5.2 Point-in-Time Recovery Using Event Positions 基于时间点恢复指从一个数据改变恢复从一个给定的时间点。 通常情况下, 这个恢复的类型是在恢复一个全备份后执行的,把服务器带到备份时候的状态。 (全备份可以有几种方式) 按时间点恢复让数据库到从全备份的时间点到最近的时间点 时间点恢复是基于这些原则: 1.用于基于时间恢复大师增量备份通过binary log 文件产生随后到全备份操作。 因此, server 必须启用--log-bin选项来启动binary log 要查看所有的binary log 文件的列表,使用这个语句: SHOW BINARY LOGS; 要确定当前binary log 文件的名字,执行下面的语句: mysql> SHOW MASTER STATUS; mysqlbinlog 功能转换binary log 文件里的evnets 从binary 格式到文本格式 这样它们可以被执行或者查看。 Mysqlbinlog 有选项用于查询binary log的部分基于evnet times或者 event position 从binary log 执行事件 可以让数据修改被重做。 这个可以让数据改变恢复用于给定的时间范围。 从binary log 执行events,处理mysqlbinlog输出适用mysql client shell> mysqlbinlog binlog_files | mysql -u root -p 查看log 内存可以是有用的 当你需要知道event times或者positions 来选择特定的日志内容 shell> mysqlbinlog binlog_files | more 如果你有多个binary log 需要执行,安全的方式是使用一个连接来处理它们,下面是一个例子,演示了可能是不安全的 shell> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
shell> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!! 处理binary logs 用这种方式使用不同的连接到server 会导致问题如果第一个log file 包含一个CREATE TEMPORARY TABLE statement 第2个 log 包含一个语句 使用这个临时表。 当第一个mysql process 中断,server drop 这个临时表 当第2个mysql 处理尝试使用这个表,server 报告 “unknown table.” 为了避免这个问题, 使用一个单独的连接来执行所有的binary logs里的内从 shell> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p 另外一种方法是将所有的日志写入到一个单独的文件,然后处理这个文件: shell> mysqlbinlog binlog.000001 > /tmp/statements.sql
shell> mysqlbinlog binlog.000002 >> /tmp/statements.sql
shell> mysql -u root -p -e "source /tmp/statements.sql"