备份策略

目标：

• 认识备份的不同类型
• 阐述不同备份技术的优缺点
• 实施备份策略

理解备份

备份的原因

• 数据库恢复
  • 从完全系统故障中恢复
  • 将系统的某些部分恢复到用户发生错误之前
• 审计和分析
  • 创建一个独立于主要生产环境用来数据审计或分析
• DBA经典任务
  • 不同系统间迁移数据
  • 基于一个产品服务器的具体状态创建开发环境

备份的类型

备份的类型影响在备份期间应用如何于数据交互

• 热备份通常允许应用程序完全访问数据。
• 冷备份通常不允许应用程序访问数据。
• 温备份允许应用程序读取数据，但不允许修改数据。

热备份

• 热备份在数据读取和修改时进行，几乎不会中断您与数据交互或操作数据的能力。
• 系统对于读取和修改数据的操作仍可访问。
• 通过以下方式锁定数据：
  • 使用多版本并发控制（MVCC）
  • 在较低级别（如行级别）进行锁定
  • 完全不锁定，以便应用程序可以继续访问数据

冷备份

• 在数据对用户不可访问时进行
  • 通常在冷备份期间，服务器处于不可访问模式或完全关闭。
  • 在备份进行时，你无法读取或对数据进行任何修改。
• 阻止你对数据执行任何操作
• 在系统正常运行时不干扰系统性能
  • 然而，对于某些应用程序来说，长时间锁定或完全阻止用户访问数据是不可接受的。

温备份

• 在数据被访问时进行
  • 在大多数情况下，备份进行时数据无法被修改。
• 优点是无需完全阻止终端用户访问
  • 然而，备份进行时无法修改数据这一缺点，可能使这种备份类型不适合某些应用程序。
• 可能会导致性能问题，因为在备份期间无法修改数据。
  • 更新数据的用户可能会长时间受阻。

备份技术

• 逻辑备份
  • 文本表示形式：以逗号分隔文件、制表符分隔文件或 XML 文件形式存在的 SQL 语句或数据文件
  • 生成一个文本文件，其中包含用于重建数据库的 SQL 语句或数据
• 物理备份
  • MySQL数据库文件二进制复制
• 基于快照（物理备份）
• 基于复制（逻辑备份和物理备份）
• 增量备份
  • 通过复制和刷新MySQL二进制日志创建

逻辑备份

通过执行SQL语句 mysqldump 或 mysqlpump 完成数据转储

• 这些数据转储基于特定的时间点，但却是所有备份技术中速度最慢的

• 优点：

  • 该过程会创建一个 SQL 脚本，你可以在 MySQL 服务器上执行该脚本，或者创建可导入数据库表的数据文件
  • 你可以使用该脚本来在另一台主机上重新加载数据库，该主机可以运行不同的架构或不同版本的 MySQL

• 缺点：

  • 默认情况下（对于非 InnoDB 表始终如此），mysqldump 和 mysqlpump 在转储期间会锁定表，这会阻止用户在备份期间修改数据。

• 逻辑备份：

  • 将数据库和表转换为包含 SQL 语句或文本数据的文本文件
  • 可以备份所有数据库、一个或多个数据库，或一个或多个表
  • 具有可移植性
  • 要求在备份期间 MySQL 服务器处于运行状态
  • 可以备份本地和远程 MySQL 服务器
  • 通常比物理（二进制）备份慢

• 逻辑备份文件的大小可能超过正在备份的数据库的大小。

  • 语句占用的空间可能比它们所表示的数据更多。
  • 文本数据通常比二进制数据占用更多空间。
  • 然而，由于 InnoDB 将数据存储在数据页中，这些数据页可能包含未使用的空间，因此 InnoDB 数据文件在磁盘上占用的空间通常比数据所需的空间大得多。

逻辑备份的条件

• 通常是热备份
  • 创建备份时服务器是运行状态
  • 逻辑备份期间，其他应用可以执行读取操作
  • 服务器通过读取要备份的表的结构和内容来创建文件。
  • 然后，它将结构和数据转换为 SQL 语句或文本文件
• 借助 InnoDB 多版本并发控制（MVCC），可以进行热逻辑备份
  • 以可重复读隔离级别启动事务，以备份 InnoDB 表的一致时间点副本
• 使用逻辑备份，您可以备份本地和远程 MySQL 服务器
  • 物理备份只能在服务器主机上执行

逻辑备份的性能

• 通常慢于物理备份
  • MySQL 服务器必须读取表并解读其内容
  • 然后它必须将表内容转换为磁盘文件，或者将语句发送到客户端程序，由客户端程序将其写出
  • mysqlpump 客户端实用程序比 mysqldump 性能更好，因为它可以并行处理数据库及其对象，但它仍然比物理备份慢
• 从逻辑备份恢复从比物理备份恢复慢
  • 恢复过程会执行包含各个 CREATE 和 INSERT 语句的脚本，这些语句用于创建每个备份的表和行
  • 恢复后的表中的所有索引都必须重建

物理备份

• 通过复制数据文件创建

  • 使用诸如 tar、cp、cpio、rsync 或 xcopy 等标准命令
  • 使用物理镜像或块设备在线磁盘复制
  • 使用基于快照的文件归档

• 必须恢复到相同的存储引擎和 MySQL 版本

  • 当从 InnoDB 表恢复物理 MySQL 备份时，在目标服务器上它仍然是一个 InnoDB 表

• 可以跨机器架构恢复

  • 文件在存储引擎级别必须是二进制可移植的

• 与逻辑备份和恢复相比，执行和恢复速度更快

物理备份文件

• 基于文件的二进制备份比逻辑备份速度更快，因为该过程只是简单的文件或文件系统复制
• 物理备份是数据库文件中数据位的精确呈现
  • 这些副本以 MySQL 自身在磁盘上存储数据库的完全相同格式来保存数据库
  • 由于它们是原始文件的精确副本，物理备份与原始文件大小相同

物理备份条件

• 在备份期间，服务器不得修改数据文件
  • 如果复制实时数据文件，要防止对这些文件进行写入操作
    • 对于 InnoDB：需要关闭 MySQL 服务器
    • 对于 MyISAM：锁定表以允许读取但不允许更改
• 还可以通过使用将正在备份的数据文件与 MySQL 服务器分离的技术，来尽量减少对 MySQL 和应用程序的影响
  • 快照
  • 复制
  • DRBD 或其他复制整个文件系统的方法

磁盘拷贝

• 可以通过以下方式直接将数据备份到另一块磁盘
  • 诸如存储复制或 RAID 镜像之类的流程
  • 诸如 DRBD（分布式复制块设备）之类的外部应用程序
    • 支持在集群计算机之间进行底层磁盘拷贝
• 这些技术可提供
  • 实时（或近乎实时）备份
  • 在发生硬件故障时快速恢复数据的方法
• 缺点
  • 副本是实时（或近乎实时）创建的，因此你无法使用此技术从用户或应用程序错误导致的数据丢失中恢复

基于快照备份

• 创建一个数据在某一时间点的副本
  • 通常针对快照副本执行物理备份
• 提供文件系统的逻辑冻结版本，从中可以进行 MySQL 备份
  • 冻结的文件系统不一定包含一致的数据库映像
  • 当您从这样的文件系统恢复时，InnoDB 必须执行自身的恢复操作，以确保不存在不完整的事务
• 可能需要关闭 MySQL 服务器（对于 InnoDB 表）或锁定表（对于 MyISAM 表）
  • 以确保数据一致性
  • 数据文件存储在多个卷中，需要进行多个快照
• 大幅减少数据库和应用程序不可用的时间

执行快照

• 基于快照的备份使用 MySQL 外部的快照功能。

  • 例如：如果数据文件位于 Linux 上的 LVM2 逻辑卷上，且该卷包含合适的文件系统（如 ext4），则可以创建快照备份

• 基于快照的备份对于能够自行执行恢复的事务引擎（如 InnoDB）效果最佳

• 执行快照所需的时间不会随着数据库大小的增长而增加

  • 从应用程序的角度来看，备份窗口几乎为零
  • 快照使用写时复制方法(copy-on-write)，以确保几乎瞬间完成。
    • 会导致额外的 I/O 开销
  • 在快照处于活动状态时会产生性能成本

  “写时复制” 是一种在磁盘数据块发生变化时复制这些数据块的技术，它与 InnoDB 撤销日志和多版本并发控制（MVCC）所使用的方法类似。当执行快照时，逻辑卷管理器（LVM）会标记所有后续发生变化的块，并记录这些块的快照版本。初始快照需要花费一点时间，但在快照处于活动状态时，所有后续的写入操作都会带来额外的性能和存储成本。

基于复制的备份

• MySQL 支持单向异步复制，其中一台服务器作为主服务器（master），而一台或多台其他服务器作为从服务器（slave）。
• MySQL 复制可用于备份：
  • 主服务器用于运行生产应用。
  • 从服务器用于备份目的。
• 这消除了对生产应用的影响。
• 对从服务器的备份可以是逻辑备份或物理备份。
• 成本较高：必须额外配备一台服务器和存储设备来存储数据库的副本。
• 基于异步复制的特性：
  • 从服务器可能会落后于主服务器。
  • 只要二进制日志（binary log）在从服务器读取之前未被清除，这种延迟是可以接受的。

二进制日志备份

二进制日志备份记录对数据的修改操作，核心价值是补充全量备份。

• 用途：通过恢复上次全量备份后发生的事件，最大限度地减少全量备份之间的数据暴露风险（即减少数据丢失量）。
• 优点：
  • 二进制日志备份包含了数据随时间发生的所有变更记录。
  • 其他类型的备份仅包含数据的某个快照。
  • 可以按顺序进行多次二进制日志备份。
• 缺点：
  • 必须按顺序恢复从上一次全量备份后生成的所有连续二进制日志。
  • 系统故障后的恢复速度可能很慢，具体取决于需要执行的二进制日志数量。

二进制日志与增量备份(Incremental Backups)

• 在会话级别控制二进制日志： SET SQL_LOG_BIN = {0|1|ON|0FF}
  • MySQL 服务器已启用二进制日志。
  • 必须拥有 SUPER 权限才能设置此变量。
• 执行逻辑备份或物理备份时刷新二进制日志。
  • 使二进制日志与备份同步。
• 逻辑备份和物理备份均为全量备份。
  • 所有表的所有行都会被备份。
• 要执行增量备份，需复制二进制日志。
• 二进制日志可用于时间点恢复。
  • 可以识别导致数据损坏的事务，并在恢复过程中跳过它们

创建备份策略

备份方法对比

mysqldump 与 mysqlpump

这两个工具仅在通过指定 --single-transaction 选项将整个操作包装在一个事务中时，才能对 InnoDB 表执行热备份。

快照（Snapshots）

快照的工作方式并非对所有存储引擎都相同。例如，InnoDB 表不需要执行 FLUSH TABLES WITH READ LOCK 来启动快照，但 MyISAM 表则需要

决定备份策略

• 所实施的备份和恢复策略取决于以下因素：
  • 数据记录的完整性要求如何？
    • 可能选择不备份每个表或每个表中的所有数据。
  • 备份的时效性要求如何？
    • 有些数据变更不频繁，因此可能选择对某些表（或某些表的部分数据）进行非频繁备份。
• 确定策略时还需考虑的其他问题：
  • 系统能承受多长时间的停机(down time)（如果允许停机的话）？
  • 需要备份的数据量有多大？
  • 数据使用哪些存储引擎存储（InnoDB、MyISAM 或两者兼有）？

更复杂的策略

通过组合多种备份技术，可以创建更复杂的策略：

• 示例：使用全量备份与二进制日志备份的组合
  • 利用复制从库，通过 mysqlbackup 进行 nightly（每晚）全量备份
  • 每小时进行多次二进制日志备份，以最大限度减少白天的（数据丢失）风险
• 示例：使用部分备份
  • 技术手段：
    • 带 --where 选项的 mysqldump
    • SELECT INTO OUTFILE 语句
  • 每周对大型事务表进行条件备份，仅包含固定数据或历史数据
    • 例如：已过 “退货期限” 的已完成订单（这类数据不会再变更）
  • 每天 / 每小时对实时数据进行补充备份

详细解释

1. 全量备份 + 二进制日志备份的组合策略

这是应对高频变更数据的典型方案，核心思路是 “全量备份打底，增量日志补全”，具体逻辑如下：

• 夜间全量备份（基于从库）

  ：

  • 利用复制从库执行 mysqlbackup（MySQL 官方物理备份工具），避免对主库的性能影响。全量备份捕获某一时刻（如凌晨 3 点）的完整数据快照，作为恢复的基础。
  • 优势：物理备份恢复速度快，适合大规模数据。

• 每小时二进制日志备份

  ：

  • 全量备份后，每小时备份一次主库的二进制日志。由于二进制日志记录了全量备份后的所有数据变更，即使白天发生故障，也能通过 “全量备份 + 故障前的所有二进制日志” 恢复数据，最大限度减少数据丢失（例如，若上午 10 点故障，只需补充 3 点到 10 点的日志）。
  • 关键：确保二进制日志在备份前不被自动清理（通过 expire_logs_days 配置保留时间）。

2. 部分备份策略（针对数据特性分层）

适用于数据量庞大且变更频率差异大的场景，通过 “区分数据类型、按需备份” 优化效率：

• 技术手段：
  • mysqldump --where：按条件导出部分数据，例如 mysqldump orders --where "order_date < '2023-01-01'" 仅备份 2023 年之前的订单。
  • SELECT INTO OUTFILE：将查询结果导出为文本文件，适合灵活筛选数据（如仅备份活跃用户数据）。
• 分层备份逻辑：
  • 历史 / 固定数据：如已过退货期的订单、归档日志等，这类数据几乎不变更，每周备份一次即可，减少重复备份的资源消耗。
  • 实时 / 活跃数据：如当日订单、用户会话数据等，需每天甚至每小时备份，确保故障时最新数据可恢复。
  • 优势：降低备份总量，缩短备份时间，同时保证核心数据的时效性。

如果你能确定某个阈值日期之前的历史数据不会再发生变更，那么只需对这部分数据进行一次备份即可。仅备份该时间点之后的数据会更快，但这意味着你必须确保备份的数据具有一致性，且恢复操作会更复杂