最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
当前位置: 首页 - 科技 - 知识百科 - 正文

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

来源:懂视网 责编:小采 时间:2020-11-09 18:47:05
文档

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

MySQL复制+快照恢复误删除操作实验测试_MySQL:bitsCN.com MySQL复制+快照恢复误删除操作实验测试 下面假定2个场景: 场景1:主从架构,没有延迟,某DBA误操作:drop database 【复制+快照:在线备份】场景2:存在不确定性或者风险性较大的操作,如升级测试,大表变更【啥事都在快照上折腾,不行大不了就将
推荐度:
导读MySQL复制+快照恢复误删除操作实验测试_MySQL:bitsCN.com MySQL复制+快照恢复误删除操作实验测试 下面假定2个场景: 场景1:主从架构,没有延迟,某DBA误操作:drop database 【复制+快照:在线备份】场景2:存在不确定性或者风险性较大的操作,如升级测试,大表变更【啥事都在快照上折腾,不行大不了就将

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

文档

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

MySQL复制+快照恢复误删除操作实验测试_MySQL:bitsCN.com MySQL复制+快照恢复误删除操作实验测试 下面假定2个场景: 场景1:主从架构,没有延迟,某DBA误操作:drop database 【复制+快照:在线备份】场景2:存在不确定性或者风险性较大的操作,如升级测试,大表变更【啥事都在快照上折腾,不行大不了就将
推荐度:
标签: 删除 恢复 在线
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top