一、为什么要进行数据库备份？
常见数据库备份的应用场景如下：
数据丢失应用场景：
人为操作失误造成某些数据被误操作
软件 BUG 造成部分数据或全部数据丢失
硬件故障造成数据库部分数据或全部数据丢失
安全漏洞被入侵数据恶意破坏
非数据丢失应用场景：
特殊应用场景下基于时间点的数据恢复
开发测试环境数据库搭建
相同数据库的新环境搭建
数据库或者数据迁移
二、数据库备份的分类
1、从物理与逻辑的角度，备份可分为
物理备份：对数据库操作系统的物理文件（如数据文件、日志文件等）的备份
逻辑备份：对数据库逻辑组件（如：表等数据库对象）的备份
2、从备份的内容来分，备份可分为
完全备份：是指对数据库进行一个完整的备份，即备份整个数据库，如果数据较多会占用较大的时间和空间。
部分备份：是指备份部分数据库（例如，只备份一个表）。
部分备份又分为：
增量备份：指的是在上次完全备份的基础上，对更改的数据进行备份。也就是说每次备份只会备份自上次备份之后到备份时间之内产生的数据。因此每次备份都比差异备份节约空间，但是恢复数据麻烦。
差异备份：指的是自上一次完全备份以来变化的数据。和增量备份相比，浪费空间，但恢复数据比增量备份简单。
MySQL 中进行不同方式的备份还要考虑存储引擎是否支持，如 MyISAM 不支持热备，支持温备和冷备。而 InnoDB 支持热备、温备和冷备。
3、从业务运行的角度，备份可分为
冷备份（脱机备份）：是在关闭数据库的时候进行的
热备份（联机备份）：数据库处于运行状态，依赖于数据库的日志文件
温备份：数据库锁定表格（不可写入但可读）的状态下进行备份操作
三、如何设计数据库的备份策略
备份策略设计的参考值
能够容忍丢失多少数据
恢复数据需要多长时间
需要恢复哪一些数据
备份策略
针对不同的场景下, 我们应该制定不同的备份策略对数据库进行备份, 一般情况下, 备份方法为以下四种：
第一种方式，冷备：直接cp,tar复制数据库文件;
第二种方式，热备或温备+增量备或差异备：mysqldump+bin logs;（本次介绍重点）
第三种方式，lvm2快照+bin logs;
第四种方式，xtrabackup+bin logs;
四、冷备份与数据恢复
冷备份
需要先停止数据库服务，再直接打包压缩数据库文件
数据库所有文件目录：/var/lib/mysql/ 文件目录可以在mysql的配置文件/etc/my.cnf中查看。
1、停止数据库
systemctl stop mysqld
2、通过tar&cp等方式冷备数据库
tar zcf /tmp/mysql_all_$(date +%F).tar.gz /var/lib/mysql
备份操作
冷备份恢复
故障时，停止服务，将故障的数据库文件移走到备份文件夹中进行备份，解压之前的备份数据库包到目录下，再移动到/var/lib/mysql/下，再重启服务，比较简单，就不演示了。
删除数据
停止数据库，并将当前数据库下的数据移动到其他目录，解压缩备份文件，移动到mysql的数据目录，开启数据验证数据恢复。
五、mysqldump+bin logs（温备+增量备）
通过mysqldump进行全备名令
mysqldump -uroot -pPassword@123 --quick --all-databases --flush-logs --delete-master-logs --lock-all-tables > /tmp/mysql_bak.sql
mysqldump名令的重点选项介绍：
--all-databases, -A
指定dump所有数据库。等价于使用--databases选定所有库
--databases, -B指定需要dump的库。该选项后的所有内容都被当成数据库名；在输出文件中的每个数据库前会加上建库语句和use语句
--quick, -q快速导出数据，该选项对于导出大表非常好用。默认导出数据时会一次性检索表中所有数据并加入到内存中，而该选项是每次检索一行并导出一行。
--flush-logs, -F在开始dump前先flush logs，如果同时使用了--all-databases，则依次在每个数据库dump前flush；如果同时使用了--lock-all-tables,--master-data
或者--single-transaction，则仅flush一次，因为这几个选项是dump前开启一个长事务或者全局锁定。等价于使用flush tables with read lock锁定所有表，
这样可以让dump和flush在完全精确的同一时刻执行。
--single-transaction该选项在dump前将设置事务隔离级别为repeatable read并发送一个start transaction语句给服务端。该选项对于导出事务表如innodb表很有用，
因为它在发出start transaction后能保证导出的数据库的一致性时而不阻塞任何的程序。该选项只能保证innodb表的一致性，无法保证myisam表
的一致性。在使用该选项的时候，一定要保证没有任何其他连接在使用ALTER TABLE,CREATE TABLE,DROP TABLE,RENAME TABLE,TRUNCATE TABLE语句，
因为一致性读无法隔离这些语句。--single-transaction选项和--lock-tables选项互斥，因为lock tables会隐式提交事务。
mysqldump温备测试+恢复
通过mysqldump建立全备
mysqldump -uroot -pPassword@123 --quick --all-databases --flush-logs --delete-master-logs --lock-all-tables > /tmp/mysql_bak.sql
mysqldump备份恢复
删除数据库
通过备份进行恢复
进入数据库执行source /tmp/mysql_bak.sql
binlog增量备份
增量备份概况
开启二进制日志功能
修改配置文件，开启二进制日志功能
增量备份
log-bin日志保存到安全的地方就完成了一个时间段的增量备份。
一般恢复
将所有备份的二进制日志内容全部恢复
断点恢复
基于位置恢复：
数据库在某一时间点可能既有错误的操作也有正确的操作
可以基于精准的位置跳过错误的操作
基于时间点恢复：
跳过某个发生错误的时间点实现数据恢复
MySQL二进制日志对增量备份有重要的作用
二进制日志保存了所有更新或者可能更新数据库的操作；
二进制日志在启动MySQL服务器后开始记录，并在文件达到max_binlog_size所设置的大小或者接收到flush logs命令后重新创建新的日志文件；
开启二进制功能
vim /etc/my.cnf
增加bin-log=mysql-bin字段即可
进行增量备份
log-bin日志保存到安全的地方就完成了一个时间段的增量备份。
准备测试库，测试表
增量日志的一般恢复
将所有备份的二进制日志内容全部恢复
mysqlbinlog --no-defaults mysql_bin.000007 | mysql -uroot -pPassword@123
查看binlog二进制文件
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000001
基于时间点恢复
从某个时间点到日志结尾的恢复
mysqlbinlog [–no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ 二进制日志 | mysql -u 用户名 -p 密码从某个时间点到某个时间点的恢复
mysqlbinlog [–no-defaults] --start-datetime=’年-月-日 小时:分钟:秒’ --stop-datetime=’年-月-日小时:分钟:秒’ 二进制日志 | mysql -u 用户名 -p 密码
假如我们要跳过binlog00009里的如下update语句，binlog7、8按照顺序执行，到binlog9时，可以选择基于时间和pos点恢复，跳过update语句。
基于位置点恢复
从日志开头截止到某个位置点的恢复
mysqlbinlog --no-defaults --stop-position='1742726' mysql_bin.000009 |mysql -uroot -pPassword@123
从某个位置点到日志结尾的恢复，即正确操作之后的日志恢复
mysqlbinlog --no-defaults --start-position='1742869' mysql-bin.000009 |mysql -uroot -pPassword@123
参考博客：https://blog.csdn.net/qq_41786285/article/details/109443311?spm=1001.2014.3001.5506
