视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001 知道1 知道21 知道41 知道61 知道81 知道101 知道121 知道141 知道161 知道181 知道201 知道221 知道241 知道261 知道281
问答文章1 问答文章501 问答文章1001 问答文章1501 问答文章2001 问答文章2501 问答文章3001 问答文章3501 问答文章4001 问答文章4501 问答文章5001 问答文章5501 问答文章6001 问答文章6501 问答文章7001 问答文章7501 问答文章8001 问答文章8501 问答文章9001 问答文章9501
MySQL复制+快照恢复误删除操作实验测试_MySQL
2020-11-09 18:47:05 责编:小采
文档

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

下载本文
显示全文
专题