这篇文章主要介绍“MySQL还原备份的方法是什么”，在日常操作中，相信很多人在MySQL还原备份的方法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”MySQL还原备份的方法是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
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还原备份的方法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
