我建议您阅读 Andrey Borodin 2019 年初的报告文字记录“WAL-G 备份。2019 年有什么？”
大家好！ 我叫安德烈·鲍罗丁。 我是 Yandex 的开发人员。 自 2016 年以来，我一直对 PostgreSQL 感兴趣，在我与开发人员交谈后，他们说一切都很简单 - 你获取源代码并构建它，一切都会成功。 从那时起我就停不下来——我写了各种各样不同的东西。
我正在做的事情之一是备份系统。 。 总的来说，在 Yandex，我们很长时间以来一直致力于 PostgreSQL 的备份系统。 您可以在互联网上找到有关我们如何制作备份系统的一系列六份报告。 每年他们都会进化一点，发展一点，变得更加可靠。
但今天的报告不仅是关于我们做了什么，而且是关于它有多简单以及是什么。 你们中有多少人已经看过我关于 WAL-G 的报道？ 还好有不少人没看，因为我会从最简单的开始。
如果你突然有了一个 PostgreSQL 集群，而且我想每个人都有几个，并且突然还没有备份系统，那么你需要获得任何 S3 存储或 Google Cloud 兼容存储。
例如，您可以来到我们的展位并获取与 S3 兼容的 Yandex 对象存储的促销代码。
然后创建一个桶。 它只是一个信息容器。
创建服务用户。
为服务用户创建访问密钥：aws-s3-key。
下载 WAL-G 的最新稳定版本。
我们的预发布版本与发布版本有何不同？ 我经常被要求提前释放。 如果版本在足够长的时间内（例如一个月）没有出现错误，那么我就会发布它。 这是 XNUMX 月发布的版本。 这意味着我们每个月都会发现某种错误，通常是在非关键功能中，但我们尚未发布版本。 之前的版本只有XNUMX月份。 其中没有我们已知的错误，即随着项目的进展添加了错误。
下载 WAL-G 后，您可以运行一个简单的“备份列表”命令，并传入环境变量。 它将连接到对象存储并告诉您有哪些备份。 当然，首先您不应该有备份。 这张幻灯片的目的是表明一切都很简单。 这是一个接受环境变量并执行子命令的控制台命令。
之后，您可以进行第一次备份。 在 WAL-G 中说出“backup-push”并在 WAL-G 中指定集群的 pgdata 位置。 最有可能的是，如果您还没有备份系统，PostgreSQL 会告诉您需要启用“归档模式”。
这意味着您需要进入设置并打开“archive_mode = on”并添加“archive_command”，这也是WAL-G中的子命令。 但出于某种原因，人们经常在这个主题上使用 bar 脚本并将其包装在 WAL-G 周围。 请不要这样做。 使用 WAL-G 中的功能。 如果您遗漏了什么，请写信至 。 WAL-G 假定它是在 archive_command 中运行的唯一程序。
我们使用WAL-G主要是在Yandex数据库管理中创建高可用性集群。
通常用于一主多副本的拓扑中。 同时，它在 Yandex 对象存储中制作备份副本。
最常见的场景是使用时间点恢复创建集群的副本。 但在这种情况下，备份系统的性能对于我们来说并不是那么重要。 我们只需要从备份上传一个新的集群。
通常，我们在添加新节点时需要备份系统性能。 它为什么如此重要？ 通常，人们会向集群添加新节点，因为现有集群无法处理读取负载。 他们需要添加新的副本。 如果我们把pg_basebackup的负载加到Master上，那么Master可能会崩溃。 因此，对我们来说非常重要的是，我们可以快速从存档中上传新节点，从而在主节点上创建最小的负载。
还有一个类似的情况。 这是在从失去连接的数据中心切换 Cluster Master 后需要重新启动旧的 Master。
- 结果，在制定复制系统的需求时，我们意识到pg_basebackup不适合我们在云中操作时的情况。
- 我们希望能够压缩我们的数据。 但除了自带的备份系统之外，几乎所有备份系统都将提供数据压缩功能。
- 我们希望将一切并行化，因为云中的用户购买了大量的处理器核心。 但如果我们在某些操作中没有并行性，那么大量的核心就变得毫无用处。
- 我们需要加密，因为数据通常不属于我们，无法以明文形式存储。 顺便说一下，我们对 WAL-G 的贡献是从加密开始的。 我们在WAL-G中完成了加密，之后有人问我们：“也许我们中的一个人会开发这个项目？” 从那时起，我已经与 WAL-G 合作了一年多。
- 我们还需要资源节流，因为随着使用云的时间的推移，我们发现有时人们在晚上有重要的杂货负载，并且该负载不能被干扰。 这就是我们添加资源限制的原因。
- 以及上市和管理。
- 并验证。
我们研究了很多不同的工具。 幸运的是，我们在 PostgreSQL 中有大量的选择。 我们到处都缺少一些东西，一些是一项小功能，一些是一项小功能。
在检查了现有系统后，我们得出的结论是我们将开发 WAL-G。 那时这是一个新项目。 很容易影响备份系统云基础设施的发展。
我们坚持的主要理念是 WAL-G 应该像巴拉莱卡琴一样简单。
WAL-G 有 4 个命令。 这：
WAL-PUSH – 归档轴。
WAL-FETCH – 获取轴。
BACKUP-PUSH – 进行备份。
BACKUP-FETCH – 从备份系统获取备份。
事实上，WAL-G还对这些备份进行管理，即列出和删除历史中暂时不再需要的记录和备份。
对我们来说重要的功能之一是创建增量副本的功能。
增量副本意味着我们不会创建整个集群的完整备份，而只会创建集群中已更改文件的已更改页面。 从功能上看，这与使用 WAL 进行恢复的能力非常相似。 但我们可以并行汇总 WAL 单线程增量备份。 因此，当我们在周六进行基本备份、每天进行增量备份、周四失败时，我们需要汇总 4 个增量备份和 10 小时的 WAL。 由于增量备份并行滚动，因此大约需要相同的时间。
基于 LSN 的增量 - 这意味着在创建备份时，我们需要组合每个页面并检查其 LSN 与前一个备份的 LSN，以便了解它是否已更改。 任何可能包含更改数据的页面都应该出现在增量备份中。
正如我所说，并行性受到了相当多的关注。
但 PostgreSQL 中的存档 API 是一致的。 PostgreSQL 归档一个 WAL 文件，恢复时请求一个 WAL 文件。 但是，当数据库使用“WAL-FETCH”命令请求一个 WAL 文件时，我们调用“WAL-PREFETCH”命令，该命令准备接下来的 8 个文件以并行地从对象存储中获取数据。
当数据库要求我们归档一个文件时，我们会查看 archive_status 并查看是否还有其他 WAL 文件。 并且我们也在尝试并行下载WAL。 这提供了显着的性能增益，并显着减少了未归档 WAL 数量的距离。 许多备份系统开发人员认为这是一个风险很大的系统，因为我们依赖于代码内部知识，而不是 PostgreSQL API。 PostgreSQL 不保证我们存在 archive_status 文件夹，也不保证那里的 WAL 文件的语义、就绪信号的存在。 尽管如此，我们正在研究源代码，我们发现确实如此，并且我们正在尝试利用它。 我们控制着 PostgreSQL 的发展方向；如果这个机制突然被打破，我们将停止使用它。
在其纯粹形式中，基于 LSN 的 WAL 增量需要读取自上次备份以来文件系统中的模式时间已更改的任何集群文件。 我们忍受了很长一段时间，差不多一年了。 最后我们得出的结论是我们有 WAL 增量。
这意味着每次我们在Master上归档WAL时，我们不仅会对其进行压缩、加密并将其发送到网络，而且同时还会对其进行读取。 我们分析并阅读其中的记录。 我们了解哪些块已更改并收集增量文件。
增量文件描述了一定范围的WAL文件，描述了在这个范围的WAL中哪些块被改变的信息。 然后这些增量文件也被存档。
在这里，我们面临着这样一个事实：我们很快地并行化了所有内容，但我们无法并行读取顺序历史记录，因为在某个段中，我们可能会遇到前一个 WAL 记录的结尾，而我们还没有任何东西可以连接，因为平行阅读导致我们首先分析未来，而未来还没有过去。
结果，我们不得不将难以理解的部分放入 _delta_partial 文件中。 结果，当我们回到过去时，我们会将 WAL 记录的各个部分粘合在一起，然后我们将解析它并了解其中发生了什么变化。
如果在我们的轴解析历史中至少有一个点我们不明白发生了什么，那么相应地，在下一次备份期间，我们将被迫再次读取整个集群，就像我们对常规 LSN 所做的那样基于三角洲。
结果，我们所有的痛苦都导致了我们开源WAL-G解析库。 据我所知，还没有人在使用它，但如果有人想编写和使用它，它就属于公共领域。 （更新了链接 )
因此，所有的信息流看起来都相当复杂。 我们的大师存档轴并存档增量文件。 并且制作备份副本的副本必须在备份之间经过的时间内接收增量文件。 在这种情况下，需要批量添加并解析部分历史记录，因为并非整个历史记录适合大段。 只有在此之后，副本才能归档完整增量备份。
在图表上，一切看起来都简单得多。 这是从我们的真实集群之一下载的。 我们有基于 LSN 的、一日之内制作的产品。 我们看到基于 LSN 的增量备份从凌晨三点运行到凌晨五点。 这是处理器核心数量的负载。 WAL-delta在这里花了我们大约20分钟，也就是说，它变得明显更快，但同时网络上的交换也更加激烈。
由于我们掌握了有关数据库历史记录中哪些块发生更改以及发生时间的信息，因此我们进一步决定集成功能 - 一个名为“pg_prefaulter”的 PostgreSQL 扩展
这意味着当备用库执行恢复命令时，它告诉 WAL-G 获取下一个 WAL 文件。 我们大致了解 WAL 恢复过程将在不久的将来访问哪些数据块，并对这些块发起读取操作。 这样做是为了提高 SSD 控制器的性能。 因为WAL卷会到达需要更改的页面。 该页位于磁盘上，不在页缓存中。 并且他会同步等待这个页面的到达。 但附近是 WAL-G，它知道在接下来的几百兆字节的 WAL 中我们将需要某些页面，同时开始预热它们。 启动多个磁盘访问，以便并行执行。 这在 SSD 驱动器上效果很好，但不幸的是，它绝对不适用于硬盘驱动器，因为我们只会通过提示来干扰它。
这就是现在代码中的内容。
我们想添加一些功能。
从这张图可以看出WAL-delta花费的时间比较短。 这是读取白天数据库中发生的更改。 我们不仅可以在晚上进行 WAL-delta，因为它不再是重要的负载源。 我们每分钟都可以读取 WAL-delta，因为它很便宜。 一分钟内我们可以扫描集群发生的所有变化。 这可以称为“即时 WAL-delta”。
关键是，当我们恢复集群时，我们减少了必须按顺序滚动的故事数量。 也就是说，应该减少 PostgreSQL 滚动的 WAL 量，因为这需要大量时间。
但这还不是全部。 如果我们知道某些块将被更改为备份一致性点，那么我们就无法更改它过去。 也就是说，现在我们对 WAL-delta 转发进行了逐个文件的优化。 这意味着，例如，如果周二完全删除了表或从表中完全删除了某些文件，那么当周一增量滚动并恢复周六的 pg_basebackup 时，我们甚至不会创建此数据。
我们希望将这项技术扩展到页面级别。 也就是说，如果文件的某些部分在周一发生了变化，但在周三会被覆盖，那么当恢复到周四的某个点时，我们不需要将前几个版本的页面写入磁盘。
但这仍然是我们内部正在积极讨论的一个想法，但尚未达到代码。
我们想在 WAL-G 中再添加一项功能。 我们希望使其可扩展，因为我们需要支持不同的数据库，并且希望能够以相同的方式进行备份管理。 但问题是 MySQL API 完全不同。 在MySQL中，PITR不是基于物理WAL日志，而是基于binlog。 而且我们在 MySQL 中没有归档系统来告诉外部系统这个 binlog 已经完成并且需要归档。 我们需要站在 cron 中数据库的某个地方，检查是否有准备好的东西？
同样，在MySQL恢复期间，没有恢复命令可以告诉系统我需要这样那样的文件。 在开始重建集群之前，您需要知道需要哪些文件。 您自己需要猜测您将需要哪些文件。 但这些问题或许可以通过某种方式规避。 （澄清：MySQL 已经支持）
在报告中，我还想谈谈WAL-G不适合你的那些情况。
如果您没有同步副本，WAL-G 不保证最后一个段将被保留。 如果归档落后于历史的最后几段，那就是一个风险。 如果没有同步副本，我不建议使用WAL-G。 尽管如此，它主要是为云安装而设计的，这意味着具有同步副本的高可用性解决方案，它负责最后提交的字节的安全。
我经常看到人们尝试同时运行 WAL-G 和 WAL-E。 我们支持向后兼容性，即 WAL-G 可以从 WAL-E 恢复文件，并且可以恢复在 WAL-E 中制作的备份。 但由于这两个系统都使用并行 wal-push，它们开始互相窃取文件。 如果我们在 WAL-G 中修复它，它仍然会保留在 WAL-E 中。 在 WAL-E 中，它查看归档状态，查看已完成的文件并将其归档，而其他系统根本不知道此 WAL 文件存在，因为 PostgreSQL 不会尝试再次归档它。
我们要在 WAL-G 方面修复什么？ 我们不会通知 PostgreSQL 该文件是并行传输的，当 PostgreSQL 要求我们归档它时，我们已经知道具有此模式时间和此 md5 的文件已经被归档，我们会简单地说 PostgreSQL -好的，一切都准备好了，基本上不需要做任何事情。
但这个问题不太可能在 WAL-E 端得到解决，因此目前无法创建将文件同时归档到 WAL-G 和 WAL-E 中的归档命令。
另外，现在有些情况WAL-G不适合您，但我们一定会修复它。
首先，我们目前没有内置的备份验证。 我们在备份或恢复期间都没有验证。 当然，这是在云端实现的。 但这是简单地通过预检查、简单地恢复集群来实现的。 我想把这个功能提供给用户。 但通过验证，我假设在 WAL-G 中可以恢复集群并启动它，并运行冒烟测试：pg_dumpall 到 /dev/null 和 amcheck 索引验证。
目前在 WAL-G 中，无法推迟 WAL 的一项备份。 也就是说，我们支持一些窗口。 例如，存储最近 XNUMX 天、存储最近 XNUMX 个备份、存储最近 XNUMX 个完整备份。 人们常常过来说：“我们需要备份新年发生的事情，我们希望永远保留它。” WAL-G 还不知道如何做到这一点。 （注意 - 这已被修复。阅读更多 - 备份标记选项 )
在验证 PITR 时，我们没有对所有轴段进行页面校验和和完整性检查。
由此，我为 Google Summer of Code 整理了一个项目。 如果你认识聪明的学生，他们想用 Go 写一些东西，并从一家带有字母“G”的公司获得几千美元，那么向他们推荐我们的项目。 我将担任这个项目的导师，他们可以做到。 如果没有学生，那么暑假我就拿去自己做。
我们还有许多其他小问题正在逐步解决。 一些非常奇怪的事情发生了。
例如，如果您给 WAL-G 一个空备份，它就会掉落。 例如，如果您告诉他需要备份一个空文件夹。 pg_control 文件将不存在。 他会认为他不明白某些事情。 理论上，在这种情况下，您需要向用户编写一条普通消息，向他解释如何使用该工具。 但这甚至不是编程的特征，而是良好的、易于理解的语言的特征。
我们不知道如何进行离线备份。 如果数据库撒谎，我们就无法备份它。 但这里的一切都很简单。 我们在启动时通过 LSN 来调用备份。 底层库的LSN必须从控制文件中读取。 这是一个尚未实现的功能。 许多备份系统可以备份底层数据库。 而且很方便。
我们目前无法正确处理备份空间不足的问题。 因为我们通常在家处理大量备份。 但他们没有抽出时间去做。 但是，如果有人现在想用 Go 进行编程，请将对空间不足错误的处理添加到存储桶中。 我一定会研究拉取请求。
让我们担心的主要事情是我们需要尽可能多的 docker 集成测试来检查不同的场景。 目前我们只测试基本场景。 在每次提交时，我们希望逐次检查我们支持的所有功能。 特别是，例如，我们将对 PostgreSQL 9.4-9.5 提供足够的支持。 我们支持它们是因为社区支持 PostgreSQL，但我们不会逐次检查提交以确保一切都没有损坏。 在我看来，这是一个相当严重的风险。
我们在 Yandex 数据库管理中的一千多个集群上运行 WAL-G。 它每天备份数百 TB 的数据。
我们的代码中有很多 TODO。 如果你想编程，来吧，我们正在等待拉取请求，我们正在等待问题。
问题
晚上好！ 谢谢你！ 我的猜测是，如果您使用 WAL-delta，您可能会严重依赖全页写入。 如果是这样，您是否进行了测试？ 你展示了一个漂亮的图表。 关闭FPW会变得多么美丽？
我们启用了全页写入，但我们没有尝试禁用它。 也就是说，我作为开发人员并没有尝试将其关闭。 研究过的系统管理员大概都研究过这个问题。 但我们需要 FPW。 几乎没有人禁用它，因为否则就不可能从副本中进行备份。
感谢您的报告！ 我有两个问题。 第一个问题是表空间会发生什么？
我们正在等待拉取请求。 我们的数据库驻留在 SSD 和 NMVE 磁盘上，我们并不真正需要此功能。 我现在还没有准备好花大量时间来做好这件事。 我衷心主张我们支持这一点。 有人支持它，但以适合他们的方式支持它。 他们做了一个分叉，但他们不做拉取请求。 （0.2.13版本新增）
第二个问题。 您一开始就说过，WAL-G 假设它单独工作，不需要包装器。 我自己用包装纸。 为什么不应该使用它们？
我们希望它像三弦琴一样简单。 这意味着除了三弦琴之外，您根本不需要任何东西。 我们希望系统简单。 如果您有需要在脚本中完成的功能，请告诉我们 - 我们将在 Go 中完成。
晚上好！ 感谢您的报告！ 我们无法让 WAL-G 与 GPG 解密一起使用。 它正常加密，但不想解密。 这对我们来说是不成功的事情吗？ 情况令人沮丧。
在 GitHub 上创建一个问题，让我们来解决这个问题。
也就是说，你没有遇到过这种情况吗？
错误报告有一个特点，当WAL-G不明白它是什么类型的文件时，它会询问：“也许它被加密了？” 也许问题根本不在于加密。 我想改进这个主题的日志记录。 他必须破译它。 我们目前正在研究这个主题，因为我们不太喜欢获取公钥和私钥的系统的组织方式。 因为我们调用外部 GPG，以便它为我们提供密钥。 然后我们将这些密钥传输到内部GPG，这是开放的PGP，它是在WAL-G内部为我们编译的，我们称之为加密。 对此，我们希望改进系统，希望支持Libsodium加密（在0.2.15版本中添加）。 当然，解码应该可以工作，让我们弄清楚 - 你需要的不仅仅是几个单词的症状。 您可以找个时间聚集在演讲者的房间并查看系统。 （无需外部 GPG 的 PGP 加密 - v0.2.9）
你好！ 感谢您的报告！ 我有两个问题。 我有一个奇怪的愿望，希望在两个提供商中执行 pg_basebackup 和 WAL 登录，即我想做一个云，另一个。 有什么方法可以做到这一点吗？
现在这个想法不存在了，但这是一个有趣的想法。
我只是不信任某个提供商，我想在另一个提供商处拥有相同的服务，以防万一。
这个想法很有趣。 从技术上来说，这并不难实现。 为了防止这个想法丢失，我可以请你在 GitHub 上提出一个问题吗？
是的，当然。
然后，当学生来到 Google Summer of Code 时，我们会将他们添加到项目中，以便他们有更多的工作来获得更多收益。
第二个问题。 GitHub 上有一个问题。 我认为它已经关闭了。 恢复期间出现恐慌。 为了打败它，你做了一个单独的组件。 在问题上是对的。 并且可以选择在一个线程中执行可变环境。 这就是为什么它运行得非常慢的原因。 而且我们也遇到了这个问题，而且还没有解决。
问题是，由于某种原因，当我们以高并发访问存储（CEPH）时，它会重置连接。 关于这个还能做什么？ 重试逻辑如下所示。 我们正在尝试再次下载该文件。 在一次传递中，我们有许多文件未下载，我们将为所有未登录的人制作第二个文件。 只要每次迭代至少加载一个文件，我们就会重复、重复、重复。 我们改进了重试的逻辑——指数退避。 但目前尚不完全清楚如何处理存储系统端的连接中断这一事实。 也就是说，当我们上传到一个流时，它不会破坏这些连接。 这里我们可以改进什么？ 我们有网络限制，我们可以通过每个连接发送的字节数来限制它。 否则，我不知道如何处理对象存储不允许我们从它并行下载或下载的事实。
没有 SLA？ 这不是写给他们如何让自己受折磨的吗？
关键是提出这个问题的人通常都有自己的金库。 也就是说，没有人来自 Amazon、Google Cloud 或 Yandex Object Storage。
也许这个问题不再适合你？
在这种情况下，问题对谁来说并不重要。 如果有任何关于如何处理这个问题的想法，让我们在 WAL-G 中实现。 但到目前为止我对如何处理这个问题还没有好的想法。 有一些对象存储支持以不同方式列出备份。 您要求他们列出对象，他们会在其中添加文件夹。 WAL-G 对此感到害怕 - 这里有某种不是文件的东西，我无法恢复它，这意味着备份没有恢复。 也就是说，事实上，您有一个完全恢复的集群，但它返回了一个错误状态，因为对象存储返回了一些它不完全理解的奇怪信息。
这是发生在邮件云中的事情。
如果你能建立一个重现...
它不断地被复制...
如果有重现，那么我认为我们将尝试重试策略，并找出如何重试并了解云对我们的要求。 也许对我们来说在三个连接上会很稳定，不会断开连接，那么我们就小心的达到三个。 因为现在我们很快就断开连接，也就是说，如果我们启动了 16 个线程的恢复，那么第一次重试后将有 8 个线程、4 个线程、2 个线程和 7,5 个线程。 然后它将把文件拉入一个流中。 如果有一些神奇的值，比如 7,5 线程最适合泵送，那么我们将详细讨论它们并尝试制作另一个 XNUMX 线程。 这是一个想法。
感谢您的报告！ 使用 WAL-G 的完整工作流程是什么样的？ 例如，在页面之间没有增量的愚蠢情况下。 我们取出并删除最初的备份，然后将轴归档，直到我们脸色发青。 据我了解，这里出现了故障。 在某些时候，您需要对页面进行增量备份，即某些外部进程正在驱动此备份，或者这是如何发生的？
增量备份 API 非常简单。 那里有一个数字——最大增量步数，这就是它的名字。 它默认为零。 这意味着每次执行备份推送时，它都会下载完整备份。 如果将其更改为任何正数，例如 3，那么下次执行备份推送时，它将查看以前备份的历史记录。 他看到你没有超过 3 个 delta 的链，并制作了一个 delta。
也就是说，每次我们启动 WAL-G 时，它都会尝试进行完整备份？
不，我们运行 WAL-G，如果您的政策允许，它会尝试实现增量。
粗略地说，如果每次都用零运行它，它的行为会像pg_basebackup吗？
不，它仍然会运行得更快，因为它使用压缩和并行性。 pg_basebackup 会将轴放在你旁边。 WAL-G 假定您已配置归档。 如果没有配置它会发出警告。
Pg_basebackup 可以在没有轴的情况下运行。
是的，那么他们的行为几乎是一样的。 pg_basebackup 复制到文件系统。 顺便说一句，我们有一个我忘记提及的新功能。 我们现在可以从 pg_basebackup 备份到文件系统。 我不知道为什么需要这个，但它就在那里。
例如，在 CephFS 上。 并不是每个人都想配置对象存储。
是的，这可能就是他们询问有关此功能的问题的原因，以便我们可以做到这一点。 我们做到了。
感谢您的报告！ 只是有一个关于复制到文件系统的问题。 开箱即用，您现在是否支持复制到远程存储，例如，如果数据中心或其他地方有某个架子？
在这个表述中，这是一个难题。 是的，我们支持，但此功能尚未包含在任何版本中。 也就是说，所有预发行版都支持这一点，但发行版不支持。 该功能是在0.2版本中添加的。 一旦我们修复了所有已知的错误，它肯定会很快发布。 但目前这只能在预发布中完成。 预发行版中有两个错误。 WAL-E 恢复存在问题，我们尚未修复。 在最新的预发行版中添加了有关增量备份的错误。 因此，我们推荐大家使用release版本。 一旦预发布中没有更多错误，我们就可以说我们支持 Google Cloud、S3 兼容的东西和文件存储。
您好，感谢您的报告。 据我了解，WAL-G 不是像酒保那样的某种集中式系统吗？ 你打算朝这个方向发展吗？
问题是我们已经偏离了这个方向。 WAL-G 存在于基本主机、集群主机以及集群中的所有主机上。 当我们搬到数千个集群时，我们安装了许多调酒师。 每当其中有什么东西崩溃时，这就是一个大问题。 因为它们需要修复，所以您需要了解哪些集群现在没有备份。 我不打算在备份系统的物理硬件方向上开发WAL-G。 如果社区想要这里的一些功能，我一点也不介意。
我们有负责存储的团队。 我们感觉很好，不是我们，而是有特殊的人将我们的文件放在安全的地方。 他们在那里进行各种巧妙的编码，以承受一定数量文件的丢失。 他们负责网络带宽。 当你有调酒师时，你可能会突然发现流量很大的小型数据库都聚集在同一台服务器上。 您似乎有很多空间，但由于某种原因，所有内容都无法通过网络。 结果可能恰恰相反。 那里有很多网络，有处理器核心，但这里没有磁盘。 我们厌倦了这种需要兼顾的事情，我们转向这样一个事实：数据存储是一项单独的服务，由单独的特殊人员负责。
PS 新版本已经发布 ，您可以在其中使用 .walg.json 配置文件，该文件默认位于 postgres 主目录中。 您可以放弃 bash 脚本。 示例 .walg.json 在本期中
视频：
来源： habr.com