Go to mysql master and check mysql-bin logs and current position:
So, the latest bin log is 452.
The binary log is a set of files that contain information about data modifications made by the MySQL server.
- Now we have volume, based on the snapshot, made at 11.59 (server time) or 1.59 AWS time.
- Now lets copy 2 or 3 binary logs ( mysql-bin.000451 and mysql-bin.000452) to /home directory, as we'll detach and attach new volume
- Convert binary logs to READABLE format and catch exact time or end_log_pos (log position) when unneeded SQL was executed:
- Convert 1482415011 to a human time - GMT: Thu, 22 Dec 2016 13:56:51 GMT (also remember about time drift! -2 hours of #161222 15:56:51 )
So, we need to recover DB up to 13:56:50 (1 sec before destructive statement)
- Detach old volume, containing /vol with mysql data-files and attach the one, made from snapshot:
Detach volume, using AWS console
Check, that the volume was detached, using lsblk and after attach as /dev/sdh
Usually there is a problem with logs directory or permissions, so check in /etc/mysql/my.cnf logs dir.
To create log path:
Now, when Mysql started (make sure that apache or nginx are down! DB should have NO connections during restoring period) get the name of a current binary log:
- Finally, here are our commands to restore:
Don't forget to start apache or nginx after final checks.
UPDATE: better to use log positions, not time to avoid data loss in those milliseconds
Комментариев нет:
Отправить комментарий