您好，habrozhiteli！在IT领域，发生了一场真正的革命-他们开始将基础架构与代码一起使用。此过程不仅会带来新问题，而且还会带来确保数据库正常运行时间的机会。作者已为希望加入现代数据库可靠性工程师（DBRE）社区的任何人准备了本实用指南。本书中：•存储要求和风险管理要求。•创建和开发提供透明数据库支持的体系结构。•简化发布管理流程。•数据的存储，索引编制和复制。•确定数据仓库的特征，并选择最佳使用方案。•研究架构组件并创建面向大数据处理的架构。这本书是给谁的？, , . , . , . , , . .
, Linux/Unix, - / . , — — — . , , .
, , , . , , .
, , . , - , . , Excel, .
出版结构. . , , , . : , , , . , . !
, : (DBRE), (RE). , . DBR- , , .
, . . , . — , . , , , , , , , . .
, .
1 . , — , DBRE, — , , DBRE .
2 . , . , , — , . , .
3 . . .
4 . . , , . , .
5 6 . . , , , , , .
7 . , , DBE. — , . , , , .
8 . , ? SQL? — , .
9 . . .
10 , . , , . , .
11 . , , . , , , .
12 (), , , . , « » () , , . — .
, 13 . , .
备份与还原
在第5章和第6章中，我们专注于设计和管理基础结构。这意味着您对如何创建和部署可在其中运行数据库的分布式基础架构以及如何管理它们有一个好主意。我们研究了快速添加新节点以增加容量或替换故障节点的方法。现在该讨论最重要的事情-备份和还原数据。让我们面对现实：每个人都考虑备份和恢复无聊而乏味的活动。对于大多数人来说，这些程序是例行程序的缩影。该团队不喜欢与初级工程师和外部承包商互动，也不喜欢使用第三方工具。以前，我们只需要处理糟糕的备份软件。老实说，我们对您表示同情。但是，这是您工作中最重要的过程之一。在节点，数据中心之间移动重要数据并将其传输到长期档案中，是企业最有价值的资产-信息的持续移动。强烈建议您不要将恢复和备份操作视为第二类操作，而应将它们视为VIP操作。每个人不仅应该了解数据恢复的目标，而且应该熟悉这项工作和流程监控的原理。 DevOps理念假设每个人都应该能够编写代码并在一个真正有效的系统中实现它。我们邀请每位工程师至少参与一次关键数据恢复过程。我们创建并存储数据的副本-备份和存档-作为满足特定需求的一种方式。它们是恢复所必需的。有时，恢复是一件令人愉快且悠闲的事情，例如，在为审计员创建环境或设置替代环境时。但是大多数情况下，需要快速替换发生故障的节点或增加现有集群的容量。如今，在分布式环境中，我们在数据备份和恢复方面面临着新的挑战。与以前一样，大多数本地数据集都在合理的范围内分配，最大数量为TB。不同之处在于这些本地数据集仅是大型分布式集的一部分。站点恢复是一个相对受控的过程，但是维护集群中的状态是一项更加困难的任务。基本原则
我们首先讨论数据备份和恢复的基本原理。对于经验丰富的数据库专家或系统工程师而言，其中一些似乎很基础。如果是这样，您可以轻松滚动几页。物理还是逻辑？
数据库的物理备份将备份存储数据的实际文件。这意味着支持典型的数据库文件格式，并且通常在数据库中存在一组元数据，该元数据确定什么文件以及其中的数据库结构。如果在创建文件的备份副本时，您希望另一个数据库实例能够使用它们，那么您将需要进行备份并保存与该数据库相关的元数据，以便备份是可移植的。创建逻辑备份时，数据从数据库导出为理论上可以传输到任何系统的格式。通常，元数据也被保存，但是最有可能在执行备份的那一刻是相关的。一个示例是导出在更新空数据库时填充空数据库所需的所有插入语句。另一个示例是JSON字符串。结果，逻辑备份通常会花费大量时间，因为这不是物理复制和写入操作，而是逐行数据提取。同样，恢复会伴随所有常见的数据库开销，例如锁定以及创建重做和撤消日志。这种分离的一个很好的例子是基于行的复制和基于语句的复制之间的区别。在许多关系数据库中，基于代理的复制意味着在写入版本控制系统后，会将数据操作语言（DML或插入，更新，替换，删除）的操作员日志添加到其中。这些语句将传递到播放它们的副本。复制的另一种方法是基于字符串或更改数据捕获（CDC）。自治的还是可操作的？
脱机（或冷）备份是一种禁用了使用文件的数据库实例的备份。因此，您可以快速复制文件，而不必担心此时保持状态，而其他进程则可以读取和写入数据。这是理想的情况，但非常罕见。对于联机（或热）备份，您仍将复制所有文件，但是还需要获得一致的数据快照，这会带来额外的复杂性，在执行备份时必须存在该快照。另外，如果当前流量在备份过程中访问数据库，则必须注意不要超过存储级别的I / O子系统的吞吐量。即使限制了负载，您也可能会发现用于保持一致性的机制在应用程序中引入了不合理的延迟。满，增量和差分
无论使用哪种方法创建完整备份，都意味着完全保留了本地数据集。对于小型数据集，这很常见。对于10 TB，这将花费大量时间。差异备份允许您仅备份自上次完整备份以来已更改的数据。但是实际上，通常备份的数据不仅仅是更改的数据，因为数据是以某种大小的结构形式组织的-页面。页面大小为例如16或64 KB，并且页面包含多行数据。差异备份备份已更改数据的所有页面。因此，与仅在页面上存储修改后的数据相比，使用大页面大小可以获得更大的备份。增量备份与差异备份类似，不同之处在于上次修改数据的日期将是上次备份的日期（增量备份或完整备份）。因此，从增量备份还原时，您可能需要还原最后一个完整备份以及一个或多个增量备份，才能到达当前位置。知道这一点，我们将讨论选择有效的备份和数据恢复策略时应考虑的几点。数据恢复注意事项
首次选择有效策略时，您应该再次考虑服务质量目标（SLO），这已在第2章中进行了讨论。特别是，您需要考虑可用性和可靠性指标。不管您最终选择哪种策略，它都应仍具有恢复正常运行时间限制内的数据的能力。而且，您将必须快速备份以确保符合可靠性规格。如果您每天备份一次，并将两次备份之间的事务日志保存在站点级别的存储中，则很容易丢失这些事务，直到下一次备份为止。此外，您需要考虑数据集如何在整体生态系统中发挥作用。例如，您的订单可以存储在关系数据库中，其中所有事物都以事务形式固定，因此，相对于此数据库中存储的其他数据而言，很容易恢复。但是，在形成订单之后，可以通过存储在队列系统或键值存储中的事件来触发工作流。这些系统只能偶尔或什至短暂地（暂时）确保数据完整性，必要时可以引用关系数据库或将其用于恢复。恢复期间如何考虑这些工作流程？如果您正在处理一个正在快速发展的环境，则可能会发现备份中存储的数据已由该应用程序的一个版本写入和使用，并且在还原另一个版本之后被执行。应用程序将如何与过时的数据进行交互？好吧，如果对数据进行版本控制-可以考虑这样做，但是您应该意识到这种可能性，并为这种情况做好准备。否则，应用程序可能会在逻辑上破坏此数据，从而在将来导致更大的问题。在计划数据恢复时，必须考虑所有这些无法预测的细微差别。如第三章所述，不可能为任何情况做准备。但是，尝试这样做非常重要。数据恢复是工程师确保数据库可靠性的最重要职责之一。因此，您的数据恢复计划应尽可能广泛，并考虑尽可能多的潜在问题。恢复方案
考虑到以上所有因素，我们将讨论可能需要恢复数据的事件和操作的类型，以便您可以计划以满足所有需求。首先，您可以将所有方案分为计划的和计划外的。将数据恢复仅视为解决紧急情况的工具，您将仅将团队工具限制为紧急护理和模拟事故。相反，如果日常活动中包括数据恢复，则可以期望对紧急情况有更高的了解和成功解决。此外，我们将拥有更多数据来确定恢复策略是否支持我们的SLO。每天运行几次脚本，将更容易获得一组样本，其中包括极限值，并且可以很自信地用于计划中。计划的恢复方案
恢复过程可以整合到哪些日常任务中？以下是我们在不同站点上最常遇到的列表：- 在工业运行环境中创建新的节点和集群；
- 创建各种环境；
- 为顺序放置的存储执行提取，转换和加载（提取，转换和加载，ETL）和数据处理技术过程的各个阶段；
- 性能测试。
执行这些操作时，请确保将恢复过程包括在操作控制堆栈中。考虑以下指标。- 时间。完成每个组件和整个过程需要多长时间？开箱？复制？日志执行？测试？
- 规模。备份需要压缩和未压缩占用多少空间？
- . ?
此信息将帮助您避免带宽问题，这将有助于确保恢复过程的稳定性。工业操作环境中的新节点和群集
无论您的数据库是否属于不变的基础架构，都存在进行定期重建的机会，其中将根据需要使用恢复过程。由于新节点的初始加载及其在集群中的放置可能需要一定的时间，因此数据库很少包含在系统的自动扩展中。不过，没有理由阻止团队创建一个计划，以定期向集群添加新节点来测试这些过程。混沌猴子（http://bit.ly/2zy1qsE）-由Netflix开发的工具，它可以随机关闭系统，使您可以测试监视，发出通知，排序和还原的整个过程。如果尚未执行此操作，则可以将其包含在运营部门必须定期执行的流程清单中，以使所有员工熟悉该过程。这些操作使您不仅可以测试完全恢复和增量恢复，还可以测试复制的内容以及使节点正常运行的过程。创建不同的环境您将不可避免地创建用于演示和其他目的的开发，集成和操作测试环境。其中一些环境需要完全数据恢复，并且它们需要实现节点恢复和完整集群恢复。某些环境还有其他要求，例如对功能测试的部分恢复支持和确保用户隐私的数据清理。这使您可以在特定的时间点测试数据恢复以及特定对象的恢复。所有这些都与标准的完全恢复有很大不同，对于修复由操作员操作和应用程序错误引起的损坏非常有用。通过创建API，可以在设施级别和特定的时间点提供数据恢复，您可以帮助员工自动化和熟悉这些流程。位于管道下游的数据仓库的ETL和管道过程对于构建环境的任务，当将数据从工作数据库传输到管道进行进一步分析和流存储时，可以成功应用快照或单个对象级别的过程和恢复API 。现场测试在执行各种测试方案期间，您将需要数据的副本。一些测试（例如容量和负载测试）需要一整套数据，这对于完全恢复非常有用。功能测试可能需要较小的数据集，这将允许在特定时间点和设施级别进行恢复。数据恢复测试本身可以是连续的操作。除了在日常方案中使用数据恢复过程之外，您还可以配置连续恢复操作。这将自动执行测试和验证，以便快速确定备份过程中断时可能出现的任何问题。在实施此过程时，许多人会问如何验证恢复是否成功。创建备份时，您可以获得大量数据，可用于测试，例如：- 自动递增序列中的最新标识符
- 物体的线计数器；
- 仅插入的数据子集的校验和，因此可以被认为是不可变的；
- 模式定义文件中的校验和。
与任何测试一样，该方法应该是多层次的。有许多测试将成功或迅速失败。这应该是测试的第一级。示例包括比较元数据/对象定义的校验和，成功启动数据库实例以及成功连接到复制流。可能需要较长时间的操作，例如计算校验和和计数表，应在检查期间稍后执行。计划外脚本
考虑到所有可以使用的每日计划方案，数据恢复过程应进行良好的调试，记录，制定工作，并充分避免出现错误和问题。由于这个原因，计划外的情况很少会像他们想象的那样可怕。团队不应看到计划内和计划外恢复之间的差异。我们列出并详细考虑了可能需要我们执行恢复过程的情况：- 用户错误
- 应用程序错误;
- 基础设施服务的可用性；
- 操作系统错误和硬件错误；
- 硬件故障；
- 数据中心故障。
用户错误理想情况下，用户错误应该很少发生。通过为工程师构建“栏杆”和“障碍”，您可以防止许多情况发生。但是，操作员总是有可能意外造成损坏。一个典型的示例是在数据库客户端应用程序中执行UPDATE或DELETE时无处不在的所有WHERE子句。或者，例如，数据清理脚本的执行不是在测试环境中，而是在工作的“生产”系统中。通常，操作正确执行，但是对于那些主机，错误的时间执行与否。所有这些都与用户错误有关。通常，它们会立即被识别并纠正。但是，有时在几天或几周内，这种变化的后果就不会引起注意。应用错误应用程序错误是所讨论的最糟糕的情况，因为它们可能非常隐蔽。应用程序正在不断改变与数据仓库交互的方式。许多应用程序还管理参照完整性和指向资源（例如文件或第三方标识符）的外部指针。很难想象如果您进行更改以破坏数据，删除数据或以不被察觉的方式添加不正确的数据会在相当长的一段时间内发生变化，将会发生什么。基础设施服务在第6章中，我们介绍了基础架构管理服务的魔力。不幸的是，这些系统可能具有破坏性和实用性，这可能导致与编辑文件，指向不同的环境或错误的配置设置有关的大规模后果。操作系统错误和硬件错误与之交互的操作系统和设备也是由人创建的系统，因此由于未记录或已知的配置，其中可能会发生错误，从而可能导致意外后果。在数据恢复的情况下，对于通过OS缓存将数据从数据库传输到文件系统，控制器以及最终到磁盘的方式而言，尤其如此。数据损坏或丢失的发生率比我们想象的要高得多。不幸的是，我们对这些机制的信任和依赖引起了人们对数据完整性的期望，而不是对它的怀疑。
Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?
. , , . , . — .
, ZFS, , . RAID-, , .
硬件故障硬件组件原则上会发生故障，在分布式系统中，这种情况经常发生。您经常遇到磁盘，内存，处理器，控制器和网络设备故障。这些硬件故障的后果可能是节点故障或节点延迟，这会使系统无法使用。诸如网络设备之类的共享系统可能会影响整个群集，使其无法访问，或者将其分解为较小的群集，这些群集不知道网络已被划分。这可能导致需要合并和纠正的数据出现快速而重大的差异。数据中心故障有时，网络级别的硬件问题会导致数据中心崩溃。碰巧，存储底板过载会导致级联故障，就像2012年的Amazon Web服务（http://bit.ly/2zxSpzR）那样。有时，飓风，地震和其他灾难会导致整个数据中心的故障。随后的恢复将测试甚至最可靠的恢复策略的强度。脚本范围
列举了可能需要恢复的计划内和计划外场景之后，我们为这些事件添加了一个新的维度，以使我们的演示变得丰富多彩。这对于选择最合适的响应方法很有用。考虑以下选项：- 故障定位在单个节点内；
- 整个集群的故障；
- 影响整个数据中心或多个群集的故障。
如果发生本地或单站点故障，则恢复仅限于一台主机。您可以将新节点添加到群集以增加容量或替换发生故障的节点。或者，系统执行连续更新，然后将逐个节点执行还原。无论如何，这是本地恢复。在群集级别，此群集所有成员的恢复需求是全局性的。可能是破坏性的更改或删除了级联到所有节点的数据。或者您需要引入一个新的集群来测试容量。如果数据中心或几个集群规模出现故障，则意味着有必要在其物理位置或整个故障区域还原所有数据。这可能是由于共享数据仓库的故障或导致数据中心灾难性故障的故障所致。在计划的新辅助站点部署期间，也可能需要这种恢复。除范围外，还有数据集范围。在这里您可以列出三个可能的选项：在一个对象的规模上，仅此特定对象需要数据恢复-部分或全部。前面讨论的情况，其结果是，当执行DELETE操作时，删除的数据多于计划的数据，指的是同一对象内的故障。如果多个对象失败，则特定数据库中的几个或所有对象可能会受到影响。如果应用程序已损坏，更新或段迁移失败，则可能发生这种情况。最后，当一切与数据库中存储的数据保持一致时，数据库元数据的规模就会崩溃，但是元数据会丢失，使其无法使用，例如用户数据，安全特权或对OS文件的遵从性。脚本后果
重要的是，不仅要确定需要恢复的方案并确定故障区域，而且还要确定可能的后果，因为在选择恢复方法时它们将很重要。如果数据丢失不影响SLO，则可以选择一种有条理且缓慢的方法，以最大程度地减少后果的扩大。应当谨慎处理导致SLO中断的更广泛的全局更改，选择快速的服务恢复，然后进行长期清理。所有方法都可以分为以下三类。- 对SLO的影响，应用程序故障影响了大多数用户。
- 威胁SLO，一些用户已受苦。
- 不威胁SLO的功能会受到影响。
关于作者
坎贝尔·莱恩（Laine Campbell）是Fastly设计公司的高级经理（高级总监）。她还是PalominoDB / Blackbird的创始人兼首席执行官，该咨询服务为多个公司维护数据库，这些公司包括美国奥巴马，Activision Call of Duty，Adobe Echosign，Technorati，Livejournal和Zendesk。她拥有18年的数据库和可伸缩分布式系统操作经验。仁爱专业（慈善专业）是honeycomb.io的首席执行官兼联合创始人。结合日志聚合器的准确性，时间序列速度度量和应用程序性能度量（APM）的灵活性，honeycomb是世界上第一个真正的新一代分析服务。 Cheriti以前是Parse / Facebook的运营专家，管理着庞大的MongoDB副本集以及Redis，Cassandra和MySQL。她还与Facebook上的RocksDB团队紧密合作，参与了使用存储插件API开发和部署全球首个Mongo + Rocks安装。»这本书的更多信息可以在出版商的网站上找到» 目录» 摘录对于Khabrozhiteley的优惠券可享受25％的折扣- 数据库支付纸质版本的书后，将通过电子邮件发送电子书。