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中，我们还会将其写入离场位置。Code as Craft活动中 Shlomo Priymak的讲话 更详细地介绍了我们的备份基础架构。
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 。