1、简介
数据无价，MySQL 作为一个数据库系统，其备份天然也是十分重要且有必要去做。备份的理由千千万，预防故障，平安需要，回滚，审计，删了又改的需要等等，备份的重要性显而易见。除了备份自身，如何应用备份来复原 服务也是一项重点内容，不能用来复原的备份没有意义。本文次要会针对备份和复原这两方面做一些简略的介绍。
本文为《高性能 MySQL》备份相干章节的读书笔记。
2、备份和复原的简略定义
正如简介所说，备份人尽皆知，也很容易引起人的器重。依据需要写定期脚本，或者应用其余形式都是比拟常见的。然而复原就没有那么引人注目了。比如说，兴许会每周 / 每天定期进行主动备份。然而多久会进行一次备份的复原测试？备份的内容是否实现？是否可用于复原？如果呈现故障，复原的流程是否易操作？
备份只是数据源，如何应用数据源 ， 彻底复原零碎 这个过程。也十分重要。备份与复原，都是 MySQL 运维中须要把握的内容。
备份的意义在于复原。如果不能复原，那就不叫备份（比方 RAID 阵列不是备份，如果 DROP DATABASE，RAID 阵列不能复原）
[还原] 和 [复原] 的区别：
- 还原：仅指将备份文件中的内容提取进去并加载。
- 复原：包含还原备份文件在内的一系列措施，目标是让服务恢复正常运行，比方重启 MySQL，批改配置等其余操作。
也就是说，复原是要复原到异样出前，采取的所有操作(比方批改参数，重启服务等)。不仅仅只是还原备份。
3、复原打算须要思考的几个因素
复原打算在设计的时候，须要思考一些因素，从而依据不同的需要进行更好的布局。能够依据 RPO(复原点指标)和 RTO(复原工夫指标)这两个需要来帮助制订适合的复原策略。
- RPO(复原点指标)：能够容忍失落多少数据？(须要复原所有数据，还是能容忍上一次备份以来的数据失落？)
- RTO(复原工夫指标)：须要期待多久将数据恢复？(用户能承受到什么水平)
兴许还需思考：须要复原什么？(整个服务器，单个库，单个表，还是事务)
其次，复原打算须要定期进行测试，抽出数据测试备份的确无效、理论进行一次残缺的备份复原，相熟整个复原流程，确保真正产生问题时，能够井井有条的实现复原。
4、备份
4.1、备份内容包含什么？
最简略的策略就是 只备份数据和表定义 。然而复原数据库须要更多内容，如果能备份的越短缺，那么复原起来也就更容易。（次要还是 依据需要）
比方能够依据理论状况，思考备份如下内容：
1、Binlog 和 InnoDB 事务日志。
2、主 / 从库配置文件。
3、数据库操作系统配置(cron、脚本、内核参数)
或者说，依据须要进行备份内容的扩大。如果对于数据库复原、甚至重建有很高需要(比方要求更快复原)，那么备份更多的内容也必不可少。如果须要有从 0 复原数据库的能力，那须要做更多工作。
4.2、物理备份与逻辑备份
| 备份品种 | 逻辑备份 | 物理备份 |
|---|---|---|
| 简介 | 利用 mysqldump 等命令实现备份 | 间接复制数据库文件 |
| 长处 | 能够文本编辑，复原简略，应用 mysqldump 备份灵便。 | 足够直观，备份和复原过程，实质上就是文件的挪动。复原速度更快。MySQL 服务器简直不须要执行操作。 |
| 毛病 | 备份和复原都须要 MySQL 服务参加、且占用 CPU 资源。有可能很慢 | InnoDB 的原始文件通常比逻辑备份大得多。 |
物理备份和逻辑备份的一点抉择：
- 对于大数据库，必须有物理备份。逻辑备份太慢，也可思考基于快照的备份做辅助。
- 对于小数据库，逻辑备份简直就能够了。
物理备份简略高效，逻辑备份尽量也要做。【两者都要有，看具体需要和资源分配】
其次：除非通过测试，否则不能假如备份可用。比方应用mysqlcheck -A测试数据库。
4.3、Binlog 备份
Binlog 也是备份中的重要一环，因为基于工夫点的复原须要用到它。而且 Binlog 个别很小，频繁的备份也较容易实现。如果有某个工夫点的数据备份，加上自那当前的所有 Binlog，就能够回滚所有变动。
4.3.1、备份 Binlog 的一些策略
- 倡议 expire_logs_days 设置的尽量长，至多超过 2 次最近的全备份。
- 备份 Binlog 时，能够应用
FLUSH LOGS创立新的 Binlog（这样就只须要备份最新的 Binlog 了） - 能够思考将数据和 Binlog 离开保留，防止同时失落。
- 能够抉择常常备份 Binlog 或者配置一个
--log_slave_updata的只读备库。
须要留神的是，expire_log_days 是通过 日志文件的批改工夫 来判断的，而不是内容。（如果始终只有一个 Binlog 文件，可能就不会清理）。所以肯定要应用
FLUSH LOGS定期刷新 Binlog。
4.3.2、老 Binlog 的清理
最好应用 expire_log_days 来进行主动的清理，保留肯定天数。如果须要用 cron 清理。那么 不要应用 find+rm 配置的 cron 清理日志。0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rm
应用如下 cron 代替：0 3 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"
4.3.3、Binlog 备份的几点注意事项
- 增长保留工夫只是一种配置，不代表 Binlog 自身就不须要备份。Binlog 依然须要定期备份，以便能够联合最近的备份应用。
- 须要留神的是，从库也应用 Binlog。所以须要 辨别从库和备份的 Binlog 治理。
4.4、增量备份与差别备份
增量备份：自任意类型备份后，改变的所有内容的备份。
差别备份：特指自上次 全备份 之后，改变的所有内容的备份。
也就是说，差别备份基于全备份。而增量备份基于任意备份 (比方某一个指定的差别备份。
上面举一个例子：周日进行一次全备份，周一针对周日的全备份做一次差别备份。周二开始就能够有两种抉择：1、基于周日的全备份做备份(差别)。2、基于周一的差别备份做备份(增量)
差别备份可选项：
- 不要备份没有扭转的表。
- 不要备份没有扭转的行
尽管这样做差别备份能够进步复原速度。然而全备份还是很有必要的。(全备份能够频率低，然而必须有)。
4.5、从库备份
在从库中备份，有时候是一个 可选项 ，不会烦扰到主库，防止给主库减少更多的负载。其次，当打算从从库备份的时候，要保留更多信息，比方从库绝对于主库的地位(偏移) 等。
首先 从库不等于备份，从库和主库数据不匹配是很常见的。其次、从从库备份的确能够加重主库备份时的负载，然而不够好。稳固起见，还是倡议进行主库备份、全备份。
4.6、其余注意事项
4.6.1、在线备份与离线备份
离线备份是最简略最平安的。也是一致性最好的。问题就是，大部分数据库不能承受停机备份。所以根本还是用在线备份，或者说不停机备份
能够思考在业务低峰期进行在线备份，即便负载增大也不会有太大影响。
4.6.2、数据一致性
数据一致性：对于多个表之间数据的一致性要求。（比方两个逻辑相干的操作分在了两个事务内，而备份在两个事务之间执行，就会导致数据不统一）
InnoDB 能够在转储一组相干表的时候，开始一个事务，这样能够很大水平上保证数据的一致性。
然而也要留神，如果事务设置的不合理，比方一组相干表的批改分在了两个事务内，这依然会导致数据不统一。（一组表的相干操作须要确保在一个事务内)
4.6.3、定期进行备份复原测试，确认整个复原过程须要的资源
能复原的备份才有价值，不是有备份就能够
小结
本文解说了一些备份的基本知识和概念，包含一些基本概念、复原的重要性、备份和复原的简略策略。还提及到了备份内容的抉择、差别 / 增量备份、Binlog 备份等。后续还须要持续学习，理解备份和复原的具体操作办法和实际。