浅析MySQL 备份与恢复

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的一些策略

浅析MySQL 备份与恢复

扫一扫手机访问