MySQL数据备份
# 备份相关工作
# 备份策略的设计
# 备份周期的规划
全量备份的备份周期可以根据数据量决定。数据量只需要30分钟就能备份完，可以每天一备份，数据量比较大的比如说以T为单位的可以一周一次备份。
增量备份可以在各个时段备份binlog日志，比如半天一备份，一天一备份。
# 备份工具的选择
- mysqldump、mysqlbinlog、percona Xtrabackup(PBK)。
# 备份方式的选择
- 是物理备份还是逻辑备份，逻辑备份就是通过导出数据或者SQL之类的东西进行备份，物理备份就是直接备份数据库在磁盘上的物理文件。
- 物理备份的全备和增量备份都可以使用PBK。
- 逻辑备份的全备和增量备份可以使用mysqldump+binlog日志备份。binlog备份就是使用flush刷新一次，然后将除了最后一个的数据文件全部拷贝走。
# 备份类型
热备- 在业务运行时进行备份，对业务影响小，只有InnoDB引擎支持热备，直接通过mysqldump备份即可。另外主从同步实际上也是一个热备。温备- 长时间锁表备份，MyISAM引擎支持温备。冷备- 业务关闭的情况下备份，任何存储引擎都支持冷备。
# 备份策略的实现
# 备份脚本 + crontab定时任务
- 一周的其中1天执行全备，一周内的每一天执行增量备份。
# 检查备份可用性
- 每天第一件事就是检查数据备份的可用性，然后再去看监控、检查慢日志等。
- 如果对备份位置不熟悉，可以通过crontab -l找到备份脚本，然后通过脚本找到备份路径。
- 一般可以通过检查备份脚本的日志、检查备份文件的大小、内容中是否有建库建表语句等。
# 定期的恢复演练
- 只要备份和日志是完整的，就要能快速的恢复到故障之前的时间点。
- 时间越长，对业务影响越大，所以定期的恢复演练很重要，一般一个季度或半年。
# mysqldump命令
mysqldump是MySQL官方提供给我们的数据导出工具，在日常运维工作当中，我们会频繁的用到mysqldump工具来进行数据备份导出操作。
mysqldump [参数] | gzip > [备份文件路径].sql- 一般还会先将mysqldump输出的数据进行压缩，然后再重定向到文件。
# 参数
# 连接数据库相关参数
执行mysqldump命令首先需要连接数据库并登录用户，且需要有一定的管理权限才能备份。
-u[用户名]-p [密码]- 一般会将密码保存在一个文件中，然后权限设为600，在执行备份命令时通过命令读取，而非直接写在脚本文件中。
-S [Socket路径]-h 主机IP-P 主机MySQL端口
# 基础备份参数
#
-A全部库备份- 例如：
mysqldump -uroot -p123 -A > [备份文件路径].sql
- 例如：
#
-B [库名1] [库名2]...- 指定库备份 (分库备份)- -B后面跟的都必须全是数据库名。
- 例如：
mysqldump -uroot -p123 -B [库名1] [库名2] [库名3]... > [备份文件路径].sql
#
[库名] [表名1] [表名2]...- 分库分表备份- 库名后面跟的都必须全是表名。
- 例如：
mysqldump -uroot -p123 [库名] [表名1] [表名2]... > [备份文件路径].sql
#
[库名]- 备份指定数据库下所有表- 与-B的区别是，该方式备份的是表。-B多了个建库语句和USE语句，所以库级别的备份用-B，表级别的备份用[库名]。
- 例如：
mysqldump -uroot -p123 [库名] > [备份文件路径].sql
# 特殊备份参数
-R- 备份存储过程和函数，如果有则会备份。-E- 备份事件，如果有则会备份。--triggers- 备份触发器，如果有则会备份。--master-data=2- 在备份文件中记录binlog日志的最后位置信息，最后位置可在以后通过binlog恢复数据时作为起始点。- 例如：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000023', MASTER_LOG_POS=194; - 等于1时，将会以命令的方式记录 (一般不使用)。
- 等于2时，将会以注释的方式记录 (一般使用)。
- 如果不带--single-transaction参数，会自动锁表进行备份 (温备份)。
- 如果同时带--single-transaction参数，则对于InnoDB引擎的表，会进行不锁表备份 (快照备份)。
- 例如：
--single-transaction- 在备份时创建一致性快照进行备份。- 对于InnoDB引擎的表会进行一致性快照备份不会锁表，另外因为是快照备份所以只会备份开始备份之前的数据。
--set-gtid-purged=auto- 在备份文件中添加gtid信息。- 会在备份文件中添加GTID:1-N，表示这个备份中有1-N号事务的数据，在恢复后会告诉mysql已经有1-n号事务了，binlog使用UUID还原时会自动跳过1-n号事务，也可以作为起始点：N+1。
- 默认是auto，相当于ON，所以可以不添加该参数。
# 扩展参数
--max_allowed_packet=128M- 传输的数据包最大大小- 备份时如果一个表非常大，传输时超过了数据包最大大小可能就会报错，如果报错超出，就添加该参数进行调整。
-F- 备份时滚动binlog日志- 指定该参数后，备份时每有一个库就会滚动出一个新的binlog日志，所以不用，会刷出很多binlog文件。
- 一般可以使用MySQL语句手动滚动
flush logs;。
# 数据备份恢复流程
- 先则停业务，挂维护页面。
- 查找可用备份，先找到全备数据文件内的binlog文件信息和位置信息或GTID信息。
- 再通过mysqlbinlog命令加上--base64-output=decode-rows -vvv参数查看binlog文件中的数据，分析出问题故障发生点。最终找到问题故障发生前的数据点，将其位置信息或者GTID信息获取下来。
- 然后通过mysqlbinlog --skip-gtids和位置开始结束参数，或者GTID参数对binlog日志文件进行截取导出。
- 检查没问题后，就开始恢复，提前准备一个临时库。
- 进入数据库中，将log_bin暂时设为0，防止将数据恢复的操作再次记录。
- 然后再source导入全备数据和binlog截取的数据。
- 这样临时库就恢复到了数据库数据丢失或数据库崩溃以前的状态，然后验证数据。
- 最后，要么直接用临时库替换生产库，要么就将丢失数据的库或表导出，然后导入生产库。