MySQL的备份恢复

环境:MySQL 5.1.50  
log_format: MIXED

开始14:52:08 - 结束17:18:49 #全备时间 dump文件信息:CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.008329', MASTER_LOG_POS=120359470;

17:43:32 drop database feedback 相关的binlog记录如下:
BEGIN
/*!*/;
# at 532569498
# at 532569570
# at 532569646
#171210 17:43:33 server id 1  end_log_pos 532569720     Query   thread_id=2767042479    exec_time=0     error_code=0
SET TIMESTAMP=1512899013/*!*/;
COMMIT
/*!*/;
# at 532569720
#171210 17:43:33 server id 1  end_log_pos 532569793     Query   thread_id=2767042479    exec_time=0     error_code=0
SET TIMESTAMP=1512899013/*!*/;
BEGIN
/*!*/;
# at 532569793
# at 532569865
# at 532569941
#171210 17:43:33 server id 1  end_log_pos 532570015     Query   thread_id=2767042479    exec_time=0     error_code=0
SET TIMESTAMP=1512899013/*!*/;
COMMIT
/*!*/;
# at 532570015
#171210 17:43:32 server id 2  end_log_pos 532570104     Query   thread_id=22025 exec_time=2     error_code=0
SET TIMESTAMP=1512899012/*!*/;
drop database feedback
/*!*/;
# at 532570104
#171210 17:43:34 server id 1  end_log_pos 532570173     Query   thread_id=2768947870    exec_time=0     error_code=0
SET TIMESTAMP=1512899014/*!*/;
BEGIN
/*!*/;
# at 532570173
# at 532570466
#171210 17:43:34 server id 1  end_log_pos 532570493     Xid = 35333617283
COMMIT/*!*/;
# at 532570493
#171210 17:43:33 server id 1  end_log_pos 532570562     Query   thread_id=35768148      exec_time=1     error_code=0
SET TIMESTAMP=1512899013/*!*/;
BEGIN
/*!*/;
# at 532570562

17:43:06 drop database channel 相关的binlog记录如下:
# at 528849902
# at 528850252
#171210 17:43:06 server id 1  end_log_pos 528850280     Intvar
SET INSERT_ID=1135930191/*!*/;
# at 528850280
# at 528850629
#171210 17:43:06 server id 1  end_log_pos 528850657     Intvar
SET INSERT_ID=1135930192/*!*/;
# at 528850657
# at 528851005
#171210 17:43:06 server id 1  end_log_pos 528851033     Intvar
SET INSERT_ID=1135930193/*!*/;
# at 528851033
# at 528851383
#171210 17:43:06 server id 1  end_log_pos 528851452     Query   thread_id=2768942713    exec_time=0     error_code=0
SET TIMESTAMP=1512898986/*!*/;
BEGIN
/*!*/;
# at 528851452
# at 528851760
#171210 17:43:06 server id 1  end_log_pos 528851787     Xid = 35333558620
COMMIT/*!*/;
# at 528851787
#171210 17:43:06 server id 2  end_log_pos 528851874     Query   thread_id=22025 exec_time=0     error_code=0
SET TIMESTAMP=1512898986/*!*/;
drop database channel
/*!*/;
# at 528851874
#171210 17:43:06 server id 1  end_log_pos 528851943     Query   thread_id=2768942541    exec_time=0     error_code=0
SET TIMESTAMP=1512898986/*!*/;
BEGIN
/*!*/;
# at 528851943
#171210 17:43:06 server id 1  end_log_pos 528851971     Intvar
SET INSERT_ID=5609403/*!*/;
# at 528851971
# at 528852181
#171210 17:43:06 server id 1  end_log_pos 528852208     Xid = 35333558718
COMMIT/*!*/;
# at 528852208
#171210 17:43:06 server id 1  end_log_pos 528852277     Query   thread_id=2768942746    exec_time=0     error_code=0

从全备中恢复两个库的时间:
18:37:06 从全备中恢复 channel
18:37:21 从全备中恢复 feedback

问题1:由于误删库之后,没有停服,在从备份中恢复2个库之后,业务可以正常访问,这种情况下,全备到drop库期间的操作,只能导出sql语句和开发核对了吧?
问题2:基于问题1,和误操作的binlog信息,导出binlog文件如下位置的操作是否正确?
channel库 start_pos=120359470(全备开始的pos) end_pos=528851383 (误操作前的pos)
feedback库 start_pos=120359470(全备开始的pos) end_pos=532569720 (误操作前的pos)
已邀请:

tplinux

赞同来自:

1.binlog格式必须为row 其他格式 我个人认为无法恢复 哪怕是客户问题或者其他 都是这个答案
2.发生误操作 第一时间是停止服务
3.先对目前状态的数据库做个冷备份
4.新初始化一个实力 进行最近期间全量恢复+binlog恢复 如果带有change 信息可以根据change信息进行binlog位置点恢复。最后一个binlog 手动结束点 跳过误操作语句 
搞定
注意 做操作前要有冷备份 和停机 不要对数据进行二次污染~
希望能解答你的问题 

要回复问题请先登录注册