MySQL复制+快照恢复误删除操作实验测试_MySQL

bitsCN.com

MySQL复制+快照恢复误删除操作实验测试

 

下面假定2个场景：

 

场景1：主从架构，没有延迟，某DBA误操作：drop database 【复制+快照：在线备份】

场景2：存在不确定性或者风险性较大的操作，如升级测试，大表变更【啥事都在快照上折腾，不行大不了就将之删除】

 

场景2比较简单，随便在新建的一个快照上折腾，搞砸就把快照删除，再新建一个，2个字：随便玩

下面我们对场景1进行模拟

 

恢复方法：

① 恢复备库上的快照

② 根据binlog执行point-in-time恢复

 

先为备库创建快照

 

[root@localhost ~]# vgs  VG   #PV #LV #SN Attr   VSize VFree  vg     4   1   0 wz--n- 3.81G 1.81G[root@localhost ~]# lvs  LV    VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert  mysql vg   -wi-ao 2.00G      [root@localhost ~]# lvcreate --size 1G --snapshot --name backup_mysql /dev/vg/mysql  Logical volume "backup_mysql" created[root@localhost ~]# lvs  LV           VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert  backup_mysql vg   swi-a- 1.00G mysql    0.00                          mysql        vg   owi-ao 2.00G      [root@localhost ~]# mount /dev/vg/backup_mysql  /mnt/backup[root@localhost ~]# cd /mnt/backup/[root@localhost backup]# lslost+found  mysql[root@localhost backup]# tar -jcv -f /mnt/snapshot/mysql.tar.bz2 *[root@localhost ~]# lvremove --force /dev/vg/backup_mysql   Logical volume "backup_mysql" successfully removed

 

 

 

这里为什么要先备份快照再还原呢？

其一，昂贵的IO，因为磁头要在快照区和系统区来回跑

其二，快照区空间不足，因为是COW原理

 

在 2013-10-12 9:57 某位无经验DBA错误地执行了drop database snapshots：

 

在备库上确认查看：

 

mysql> show databases;+--------------------+| Database           |+--------------------+| information_schema || mysql              || test               |+--------------------+

 

可见库已经被删除了

 

同时在主库或者备库查看当前的二进制日志坐标并记录下来

[mysql@localhost mysql]$ mysqladmin -uroot -poracle shutdown131012 09:59:36 mysqld_safe mysqld from pid file /mnt/lvm/mysql/data/localhost.localdomain.pid ended[1]+  Done                    mysqld_safe[root@localhost ~]# umount /mnt/backup[root@localhost ~]# lvremove --force /dev/vg/backup_mysql   Logical volume "backup_mysql" successfully removed[root@localhost ~]# umount /mnt/lvm                                 [root@localhost ~]# mkfs -t ext3 /dev/vg/mysql[root@localhost ~]# mount /dev/vg/mysql /mnt/lvm[root@localhost ~]# tar -jxv -f /mnt/snapshot/mysql.tar.bz2  -C /mnt/lvm[mysql@localhost ~]$ mysqld_safe &

 

 

通过binlog执行point-in-time恢复 

 

[mysql@localhost ~]$ mysqlbinlog --stop-datetime="2013-10-12 10:9:56" /mnt/lvm/mysql/data/mysql-bin.000008 | mysql -uroot -poracle

 

 

确认数据是否恢复：

mysql> show databases;+--------------------+| Database           |+--------------------+| information_schema || mysql              || snapshots          || test               |+--------------------+4 rows in set (0.00 sec)mysql> use snapshots;Database changedmysql> show tables;+---------------------+| Tables_in_snapshots |+---------------------+| t                   |+---------------------+1 row in set (0.00 sec)mysql> select * from t;+----+| id |+----+|  1 |+----+1 row in set (0.00 sec)

 

 

到此，整个简单的测试就算完成了

这种复制+快照的备份架构可以实现在线实时的备份，个人感觉是个不错的备份解决方案

bitsCN.com