MySQL 运维 - 数据库备份
MySQL 运维 - 数据库备份
- 一、数据库备份的分类
-
- ① 物理备份
- ② 逻辑备份
-
- ►完全备份
- ►差异备份
- ►增量备份
- ③ 备份方式比较
- 二、mysqldump的使用
-
- ① 备份数据
- ② 查看数据
- ③ 恢复数据
- 三、增量备份
-
- ① 二进制日志的三种记录格式
- ② 刷新日志的两种方式
- ③ 查看二进制日志文件内容
- ④ 增量恢复的场景
- ⑤ 丢失完全备份之后更改的数据的恢复步骤
- ⑥ 查看二进制日志内容
- 四、增量恢复
-
- ① 增量恢复的场景
- ② 丢失完全备份之后更改的数据的恢复步骤
- ③ 完全备份之后丢失所有数据的恢复步骤
- ⑤ 基于时间点与位置的恢复
- ⑥ 基于位置的操作
- 五、总结
一、数据库备份的分类
① 物理备份
指对数据库操作系统的物理文件（如数据文件、日志文件等）的备份
物理备份又可以分为脱机备份（冷备份）和联机备份（热备份）
冷备份（脱机备份）：在关闭数据库时进行的备份操作，能够较好地保证数据库的完整性
压缩tar归档使用xz模式备份data文件夹，解压可实现数据恢复
热备份（联机备份）：在数据库运行状态中进行操作，这种备份方法依赖于数据库的日志文件
② 逻辑备份
逻辑备份是对数据库逻辑组件的备份.表示为逻辑数据库结构
这种类型的备份适用于可以编辑数据值或表结构
从数据库的备份策略角度来看，备份又可分为完全备份、差异备份和增量备份
►完全备份
每次对数据进行完整备份，即对整个数据库、数据库结构和文件结构的备份，保存的是备份完成时刻的数据库，是差异备份与增量备份的基础完全备份的备份与恢复操作都非常简单方便，但是数据存在大量的重复并且会占用大量的磁盘空间，备份的时间也很长
►差异备份
备份那些自从上次完全备份之后被修改过的所有文件，备份的时间节点是从上次完整备份起，备份数据量会越来越大。恢复数据时只需要恢复上次的完全备份与最佳的一次差异备份
►增量备份
只有那些在上次完全备份或者增量备份后被修改的文件才会被备份以上次完整备份或上次增量备份的时间为时间点，仅备份者之间的数据变化，因而备份的数据量小，占用空间小，备份速度快。但恢复时，需要从上一次的完整备份开始到最后一次增量备份之间的所有增量依次恢复，如中间某次的备份数据损坏，将导致数据的丢失
③ 备份方式比较
| 备份方式 | 完全备份 | 差异备份 | 增量备份 |
|---|---|---|---|
| 完全备份时的状态 | 表1、表2 | 表1、表2 | 表1、表2 |
| 第1次添加内容 | 创建表3 | 创建表3 | 创建表3 |
| 备份内容 | 表1、表2、表3 | 表3 | 表3 |
| 第2次添加内容 | 创建表4 | 创建表4 | 创建表4 |
| 备份内容 | 表1、表2、表3、表4 | 表3、表4 | 表4 |
二、mysqldump的使用
mysqldump是mysql自带的逻辑备份工具
mysqldump [选项] 数据库名 [表名] > 备份目标名
常用的选项
| 参数名 | 缩写 | 含义 |
|---|---|---|
| –host | -h | 服务器IP地址 |
| –port | -P | 服务器端口号 |
| –user | -u | MySQL 用户名 |
| –pasword | -p | MySQL 密码 |
| –databases | 指定要备份的数据库 | |
| –all-databases | 备份mysql服务器上的所有数据库 | |
| –compact | 压缩模式，产生更少的输出 | |
| –comments | 添加注释信息 | |
| –complete-insert | 输出完成的插入语句 | |
| –lock-tables | 备份前，锁定所有数据库表 | |
| –no-create-db/–no-create-info | 禁止生成创建数据库语句 | |
| –force | 当出现错误时仍然继续备份操作 | |
| –default-character-set | 指定默认字符集 | |
| –add-locks | 备份数据库表时锁定数据库表 |
① 备份数据
备份所有数据库
mysqldump -uroot -p --all-databases > /opt/all_databases.sql
备份指定数据库
mysqldump -uroot -p --databases bbs > /opt/bbs.sql
备份指定的表
mysqldump -uroot -p bbs user > /opt/bbs_user.sql
备份多个表
mysqldump -uroot -p bbs user password > /opt/bbs_user_password.sql
② 查看数据
grep -v "^--" xx.sql | grep -v "^/" | grep -v "^$"
③ 恢复数据
mysqldump -uroot -p bbs user > user.sql
#删除数据库
mysql -uroot -p -e 'use bbs;drop table user;'
选项 -e 用于指定连接MySQL后执行的命令，执行后退出
方法Ⅰ
#将备份的数据导入进去
mysql -uroot -p bbs < user.sql
方法Ⅱ
source 备份文件
三、增量备份
增量备份需要开启二进制日志功能
vim /etc/my.conf
[mysqld]
log-bin=mysql-bin
#可先代表二进制记录格式为混合模式
binlog_format = MIXED
① 二进制日志的三种记录格式
STATEMENT(基于SQL语句)
ROW(基于行)
MIXED(混合模式)
② 刷新日志的两种方式
systemctl restart mysqld
mysqldump -u root -p flush-log
③ 查看二进制日志文件内容
mysqlbinlog --no-defaults --base64-output-decode-rows -s 二进制文件
选项说明
--no-defaults 不加的话会报一个UTF8的错
-f 显示项目内容
--base64-oupunt
④ 增量恢复的场景
当数据发送错误时，应根据实际情况选择使用完全备份恢复，还是增量备份
增量备份的场景是
人为的 SQL 语句破坏了数据库
在进行下一次全备之前发送系统故障导致数据库数据丢失
在主从架构中，主库数据发送了故障
根据数据丢失的情况可以分为两类
只丢失了完全备份之后更改.丢失完全备份之后更改的数据的恢复步骤的数据
完全备份之后丢失所有的数据
⑤ 丢失完全备份之后更改的数据的恢复步骤
当完全备份之后更改的数据丢失，需要把完全备份之后的所有增量备份文件逐个恢复
#删除两条数据
delete from user where id=1;
delete from user where id=2;
#恢复至修改前
mysqlbinlog --no-defaults mysql-bin.000002 | mysql -uroot -p
#查看是否恢复成功
mysql -uroot -p -e 'use bbs;show tables;select * from user;'
⑥ 查看二进制日志内容
#使用64位编码机制去解码，按行读取详细内容
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002
四、增量恢复
① 增量恢复的场景
当数据发送错误时，应根据实际情况选择使用完全备份恢复，还是增量备份
增量备份的场景
- 人为的 SQL 语句破坏了数据库
- 在进行下一次全备之前发送系统故障导致数据库数据丢失
- 在主从架构中，主库数据发送了故障
根据数据丢失的情况可以分为两类
- 只丢失了完全备份之后更改的数据
- 完全备份之后丢失所有的数据
② 丢失完全备份之后更改的数据的恢复步骤
delete from user where id=1;
delete from user where id=2;
quit
mysqlbinlog --no-defaults mysql-bin.000003 | mysql -uroot -p
③ 完全备份之后丢失所有数据的恢复步骤
当完全备份和增量备份之后，所有的数据丢失，需要把完全备份和所有增量备份文件逐个恢复
#完全备份
mysqldump -uroot -p bbs user > bbs_user.sql
use bbs;
#删除表
drop table user;
quit
#恢复数据
mysql -uroot -p -e "select * from bbs.user;"
⑤ 基于时间点与位置的恢复
利用二进制日志可实现基于时间点与位置的恢复，例如由于误操作删除了一张表，这时完全恢复是没有用的
因为日志里还有误操作的语句，我们需要的是恢复到误操作之前的状态，然后跳过误操作的语句，再恢复后面操作的语句
使用 mysqlbinlog 加上 --stop-datetime 选项，表示在哪个时间点结束，后面误操作的语句不执行
–start-datetime 选项表示执行后面的语句
mysql -uroot -p -e "truncate table bbs user;"
mysql -uroot -p -e "select * from bbs user;"
mysqlbinlog --no-defaults --stop-datetime='2021-04-15 17:02:10' /opt/mysql-bin.000002 |mysql -uroot -p
mysql -uroot -p -e "select * from bbs user;"
#恢复数据
mysqlbinlog --no-defaults --start-datetime='2021-04-15 17:03:22' /opt/mysql-bin.000002 |mysql -uroot -p
⑥ 基于位置的操作
基于位置的恢复，就是使用基于时间点的恢复
可能会出现在一个时间点里既同时存在正确的操作又存在错误的操作，基于位置是一种更为精确的恢复方式
mysqlbinlog --no-defaults --stop-position='404' /opt/mysql-bin.000002 | mysql -uroot -p
#使用64位编码机制去解码并按行读取二进制文件02（增量备份）的详细内容
#仅恢复“2077”之前的数据
mysql -uroot -p -e "select * from bbs user;"
mysql -uroot -p -e "truncate table bbs user;"
mysql -uroot -p -e "select * from bbs user;"
mysqlbinlog --no-defaults --stop-position='2077' /opt/mysql-bin.000002 | mysql -uroot -p
mysql -uroot -p -e "select * from bbs user;"
五、总结
MySQL 需要定期实施备份，指定合适的备份计划或策略，并严格遵守
除了进行完全备份，开启 MySQL 服务器的日志功能也很重要，完全备份加上日志，可以对 MySQL 进行最大化还原
备份文件的名字还需要使用统一的易于理解的名称，推荐使用库名或表名加上时间的命名规则，在需要恢复数据库时能很容易的定位到相应的所需备份文件