如题所示,本文会记录一些关于通过【mysqldump】备份与恢复MySQL数据库的样例。

首先查看当前我的环境中的MySQL的现状:

查看当前MySQL状态:

可以看到:
这个环境中的MySQL的数据目录位于:/var/lib/mysql
日志文件:/var/lib/mysql/mysql-1.err(在MySQL中,错误日志一般是:【hostname】.error)

在我的环境中,我的备份策略设定是这样的:

其中:
dumpfile,存放通过mysqldump导出的备份文件。
tarfile,存放通过tar压缩的MySQL数据目录。(该文件可用的前提是,MySQL停机状态下的冷备份。)

一、冷备:数据目录
先停库,做一个冷备:

不同的打包(压缩)策略的差异:
tar -cf

tar -cjf

tar -czf

可以看到,通过bzip2压缩的压缩率是最高的。

二、热备:mysqldump导出
查看当前的数据库状态:

备份当前的数据库状态:

备份全库:

备份某个特定的库:

注意,上面备份中都添加了“–events”目的是为了过滤mysql.events的数据,否则,导出的过程中,会出现这样的警告(warning):

对于普通的库来说,mysqldump导出的时候,是不需要添加“–events”选项的。

向数据库中添加一些新的数据库,并建表,写入一些数据:

备份:
全库:

单独备份库:world。

创建用户,并赋予对数据库world的权限。

备份这时候的数据库:
全库:

单库:world

单库:mysql

三、MySQL恢复

现有的备份文件阶段:

最初,MySQL初始状态:
全:MySQL_all_db.dmp
单:MySQL_db_mysql.dmp

然后,创建world,并建表、插入数据的状态:
全:MySQL_db_all_after_create_insert.dmp
单:MySQL_db_world_after_create_insert.dmp

最后,创建用户,并分配权限后的状态:
全:MySQL_db_all_after_user.dmp
单-mysql:MySQL_db_mysql_after_user.dmp
单-world:MySQL_db_world_after_user.dmp

从上边的变化阶段你可以知道:
1. 三个阶段的全库导出文件肯定不同
2. 三个阶段的单库文件有可能不同:
相同的部分:
— 第一阶段到第二阶段,只是创建了库,所以mysql的单库状态没有发生变化
— 第二阶段到第三阶段,只是新建了用户,所以world的单库状态没有发生变化
不同的部分:
— 第二阶段到第三阶段,单库mysql的状态肯定发生了变化

恢复:
全库恢复到第二阶段:MySQL_db_all_after_create_insert.dmp
这个过程中,变化的应该是mysql.user表。

可以看到,全库备份也备份了mysql,所以mysql.user的登陆信息的表也被更改了。

单库恢复第三阶段mysql:MySQL_db_mysql_after_user.dmp。
这一步操作,会看到mysql.user发生变化,第三阶段中新增的用户god,会恢复到mysql.user中。
由于是单库恢复,所以,不会影响其他的数据库状态。

四、终了
MySQL的导出文件,并不像Oracle的导出文件那样,可以导出多个表空间,然后恢复的时候可以指定具体恢复哪一个表空间以及恢复到哪个Schema下。
MySQL的导出文件,如果包含了实例下的多个数据库,则恢复的时候会同时恢复。这对于一些需要只恢复导出文件中的某一部分库的场景是不太适用的。
此外,如果MySQL的导出文件包含了mysql库,恢复的时候只想恢复数据而不希望影响MySQL的登陆权限,则也是比较麻烦的,很容易就覆盖了之前的账户信息,造成丢失。

所以,MySQL的备份,如果采用mysqldump,最好分开备份mysql和非mysql单库。

——————————
Done。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装