MySQL还原备份的方法是什么

这篇文章主要介绍“MySQL 还原备份的方法是什么”，在日常操作中，相信很多人在 MySQL 还原备份的方法是什么问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”MySQL 还原备份的方法是什么”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

Facebook 的 MySQL 数据库遍布在我们位于全球的数据中心内，我们必须能在任何时间内从任何位置发生的故障中恢复。在发生此类灾难事件后，不仅需要尽量快速可靠地恢复服务，而且需要确保整个过程不会丢失任何数据。为此我们构建了一套能够对从备份中恢复数据库的能力进行持续不断测试的系统。

我们的还原系统包含两个重要组件：

持续还原层（Continuous Restore Tier，CRT） – 负责对所有还原操作进行调度和监控。该组件会查找包含新备份的数据库，为其创建还原作业，监控还原过程，并确保每个备份可以成功还原。

ORC 还原协调器（ORC） – 由负责执行还原的工作进程（Peon）和负载均衡器（Warchief）组成。Warchief 接收来自 CRT 的新建还原作业并将其分配给 Peon。Peon 承载了负责执行实际还原过程的本地 MySQL 实例。

数据 CRT 会收集每个还原作业的进度信息，借此帮助我们了解数据库还原操作的资源需求，ORC 则可以帮助我们验证备份的完整性。本文将侧重于介绍 ORC 的内部原理，尤其是内部的 Peon 状态机（State machine），以及在对单一数据库进行还原的过程中我们遇到并克服的挑战。

备份概述

在构建持续还原流程前，我们首先需要了解各种可用备份选项的本质。目前我们主要进行三种备份，所有备份内容均存储在 HDFS 中：

完整逻辑备份，使用 mysqldump 每几天进行一次。

差异（Diff）备份在所有未进行完整备份的日子里进行。备份过程中会再次创建完整转储，但只存储与上一次完整备份相比有差异的内容。我们会通过元数据记录每次差异备份是基于哪个完整备份进行的。

二进制日志（Binlog）备份从主数据库持续不断地流式传输至 HDFS。

完整和差异备份均会将 –single-transaction 选项传递至 mysqldump，这样我们就可以对数据库获得一致的快照，该快照可取自从属（Slave）或主（Master）实例。下文会将差异和完整备份统称为转储（Dump）。

由于每天只进行一次转储操作，因此可通过 Binlog 备份确保自从备份之后，数据库所执行的每一笔事务都能被我们记录在案。随后只要对转储内容执行还原操作将数据库恢复至某个时点，随后通过 Binlog 对事务进行重播（Replay），即可顺利实现数据库的时点还原。我们的所有数据库服务器都使用了全局事务 ID（GTID），因此在从 Binlog 备份进行事务重播时我们可以获得额外的一层控制能力。

除了将备份存储在 HDFS 中，我们还会将其写入离场位置

ORC：ORC 还原协调器

架构

ORC 包含三个组件：

Warchief – 负载均衡器。这是一种可暴露出 Thrift 接口的 Python 程序，通过接口可接收新的还原请求，并将其调度至可用的 Peon。

ORC DB – 负责维持分配给每个 Peon 的作业状态、每个作业的当前状态，以及 Peon 健康度状态等信息的中央 MySQL 数据库。Warchief 会使用该数据库中存储的信息决定要将某个作业分配给哪个 Peon，以及故障恢复过程中要使用的 Peon。

Peon – 负责还原操作的工作进程。Peon 也使用 Python 编写，可暴露出 Thrift 接口，通过该接口接收有关 Peon 的各类状态信息。每个 Peon 会定期与 ORC DB 进行同步，查询分配给自己的新作业，并汇报自己的健康度状态。运行 Peon 的服务器上还运行了一个本地 MySQL 实例，备份将还原至该实例中。

内部原理：Peon

Peon 中包含了从 HDFS 获取备份，将其载入自己的本地 MySQL 实例，通过 Binlog 重播将实例推进至某一时点等操作的所有相关逻辑。Peon 处理的每个还原作业会经历下列五个步骤：

选择（SELECT） – 决定需要用哪个备份进行还原（例如完整或增量，HDFS 或离场等）。

下载（DOWNLOAD） – 将所选文件下载至磁盘。如果要还原的是完整备份，只需下载一个文件。对于差异备份，首先需要下载完整和差异备份，随后在完整备份的基础上应用差异备份，并将最终结果存储到磁盘上。无论备份类型为何，至此我们已经在磁盘上有了一个 mysqldump 输出的内容。

加载（LOAD） – 将下载的备份载入 Peon 的本地 MySQL 实例。按照与备份文件中每张表有关的语句进行解析，并行恢复每张表，这一过程类似于 Percona 的 Mydumper。

验证（VERIFY） – 针对载入 MySQL 的数据执行健康检查（Sanity check）。

重播（REPLAY） – 如果有必要，在已还原备份的基础上，下载二进制日志备份并进行事务重播。我们会使用 mysqlbinlog 程序筛选掉来自其他共置数据库以及空事务的 Binlog 事件，随后对同一个 MySQL 实例重播所需的事务。

每个步骤有自己对应的失败状态，因此如果某个作业在 DOWNLOAD 步骤失败，将显示为 DOWNLOAD_FAILED 状态，并且不会继续进入到 LOAD 步骤中。

Binlog 的选择逻辑

还原过程中最具挑战的部分可能就是确定所要下载并重播的 Binlog。完整和差异备份可以从主或从属数据库获取，然而我们只从主数据库创建 Binlog 备份。这意味着简单的时间戳对比已经无法用于确定要重播的 Binlog。

我们于 2014 年在所有服务器上部署了 GTID，因此每笔事务都可以获得一个全局唯一标识符。此外每台运行 MySQL 的服务器也维持了一个 gtid_executed（GTID 集）变量，可将其作为对应实例目前已执行事务数量的计数器。

在具备 GTID 的情况下，从主数据库重播至从属数据库的事务可以维持自己的 GTID，这也意味着我们可以清楚地知道每笔事务是否包含在某个 GTID 集中。此外还可以针对服务器的 gtid_executed 值进行超集 / 子集（Superset/subset）比较，因为该值实际上就是一种严格递增的计数器和数学意义上的函数。

通过配合使用这些技术，即可在创建转储时记录服务器的 gtid_executed 值，同时记录每个 Binlog 文件中包含的 GTID 集，借此执行一致的比较并确定 Binlog 中的哪些事务需要重播。此外一旦需要重播的第一笔事务确定后，无需重新对比其他 GTID 即可确定需要重播的所有后续事务。我们还会使用 mysqlbinlog 的 –stop-datetime 选项确定 Binlog 流要在何处停止。

到此，关于“MySQL 还原备份的方法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！