时间:2021-07-01 10:21:17 帮助过:14人阅读
我们也可以看到全备时的binlog位置:
head -50 backup-file.sql |grep ‘CHANGE MASTER‘ -- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001‘, MASTER_LOG_POS=4321;
查看当前所在二进制日志中的位置:
head -50 backup-file.sql |grep ‘CHANGE MASTER‘ -- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001‘, MASTER_LOG_POS=4321;
根据上面两个position能大概确定需要完整恢复哪几个binlog文件。
在待恢复的position或时间点以前、全备以后的binlog需要全部恢复,多个文件以空格隔开
$ mysqlbinlog /var/lib/mysql/mysql-bin.000002 | mysql -uroot -p
此时查询可以得到前两条数据。
这个日志中包括了新增记录和误删表两个部分,我们需要恢复到新增记录之后、误删操作以前的位置。
如果知道误操作的命令如DROP TABLE
,则可以通过下面的方法在binlog文件中找到误操作之前的那个position:
(如下面的信息显示,误操作DROP TABLE
之前的pos是775,在datetime 141204 15:08:04或pos 882时完成DROP TABLE
操作)
$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 |grep -C 5 ‘DROP TABLE‘
#141204 15:07:05 server id 1 end_log_pos 775 Xid = 376
COMMIT/*!*/;
# at 775
#141204 15:08:04 server id 1 end_log_pos 882 Query thread_id=10 exec_time=0 error_code=0
SET TIMESTAMP=1417676884/*!*/;
DROP TABLE `t_user` /* generated by server */
/*!*/;
# at 882
恢复命令:
$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-position=775 | mysql -h localhost -uroot -p
如果position难以确定,但知道需要恢复到的确切(服务器)时间,也可以使用datetime:
$ mysqlbinlog /var/lib/mysql/mysql-bin.000003 --stop-datetime="2014-12-04 15:08:00" | mysql -uroot -p
如果不是误操作导致的,而是迁移数据库,那么不需要position或datetime,使用所有binlog文件增量恢复即可。
确定恢复成功后记得打开日志记录:
mysql > set global sql_log_bin=1;
unknown variable ‘default-character-set=utf8’
在使用mysqlbinlog
查看二进制日志的时候,提示下面的错误:
/usr/local/mysql/bin/mysqlbinlog: unknown variable ‘default-character-set=utf8’
原因是在我为了统一mysql客户端到服务端的的字符编码,在/etc/my.cnf
文件的[client]
、[mysqld]
等节加入了default-character-set = utf8
,mysqlbinlog
会从my.cnf
中的[client]
读取配置,但奈何mysqlbinlog并不认识这个选项(据说是个bug)导致的。
应对这个bug的方法有两个:
第一,自然是注释到[client]
中的这个字符集配置;
第二,改用loose-default-character-set = utf8
。在选项前加了loose-
,表示当程序不认识此选项时会略过此选项,并给出一个警告。
转自
MySQL增量备份与恢复实例 | Sean‘s Notes
http://seanlook.com/2014/12/05/mysql_incremental_backup_example/
MySQL增量备份与恢复实例【转】
标签:efault cal 时间 日志系统 span date 5.4 single div