MySQL 复制+快照回复误删除操作实验测试
日期：2014-05-16 浏览次数：20728 次
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]# ls
lost+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 shutdown
131012 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 changed
mysql> show tables;
+---------------------+
| Tables_in_snapshots |
+---------------------+
| t
下面假定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]# ls
lost+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 shutdown
131012 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 changed
mysql> show tables;
+---------------------+
| Tables_in_snapshots |
+---------------------+
| t
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
