即将举行的几场讲座将基于第一届Y. Subbotnik
的春季数据库发布。 首先，开发人员Andrei Borodin在Y. Subbotnik上发表了讲话。 他谈到了WAL-G（一种将PostgreSQL备份到云中的简单有效的工具），以及允许WAL-G更快创建备份的算法和技术。 WAL-G的主要功能是增量备份。 在讲座中，您将了解它们的实现以及如何在PostgreSQL中开发对此技术的支持。
-嗨！ 我是叶卡捷琳堡的Yandex开发人员。 以快速备份技术。 我们已经进行了一段时间的备份；
Vladimir Borodin和
Evgeny Dyukov进行了有关我们如何研究以及如何安全，可靠，方便，高效地存储数据的研究报告。 本系列致力于该领域的最新发展。
我们原则上谈谈PostgreSQL中的备份。 传输数据的标准实用程序
pg_dump被定义为控制台实用程序，该实用程序创建具有数据逻辑表示的文件。
这是一个逻辑副本非常方便。 您始终可以在不同版本之间传输数据，可以将数据库切成小块，这是一个标准工具，例如，在PgAdmin管理实用程序的包装盒中。
首先，关于pg_dump，您需要知道这是一个开发人员工具。
这不是数据库维护工具。 pg_dump不适用于高负载数据库。
假设一切都很认真，您想使用“时间点恢复”技术，该技术使用PostgreSQL API来处理在线备份。 您调用pg_start_backup函数并制作数据库的文件副本。 实际上，pg_start_backup强制数据库执行CHECKPOINT。 并在预写日志中启用全页写入。 调用API时创建的数据库副本不是数据的一致副本。 您还需要一个预写日志，以便能够在pg_stop_backup调用期间（即在备份结束时）恢复数据库。
在备份删除的结束时间之后，并且在存在重要记录的情况下，您可以恢复到数据库生命周期中的所需时间。
包装盒中提供了pg_basebackup实用程序，该实用程序以规范的形式实现了所有此技术，并允许您以最少的必需功能进行备份。
如果您仍然比以前更认真，则可以使用某种备份管理软件，通常是Barman。
他有几个优点。 主要优点是一个非常通用的实用程序，它具有庞大的社区，并且在Stack Overflow上存在大量问题。
您只需要选择一台备份服务器，然后将所有PostgreSQL备份在那里。 这非常方便-只要一台备份服务器就足够了。
一旦有很多备份服务器，就需要监视其中是否已满。 万一某些备份服务器发生故障，您需要了解哪些数据库现在处于危险之中。 您需要原则上了解在创建新数据库集群时将其复制到何处。
有一个更简单的备份删除实用程序，称为WAL-E。
WAL-E执行四个主要命令。 WAL-PUSH命令将一个WAL文件发送到云，如果需要恢复restore_command，则WAL-FETCH将获取一个WAL文件。
还有BACKUP-PUSH（删除备份API）和BACKUP-FETCH（从云中获取所有数据）。 数据存储在云中，因此您不需要监视任何东西，这已经是云服务的问题，如何在需要时确保数据的可用性。 这可能是WAL-E的主要优势。
有很多功能。 有一个备份列表，有一个保留策略，也就是说，我们要存储最近7天的备份，例如最后5天的备份。 WAL-E可以备份到各种各样的云服务：S3，Azure，Google，它可以将本地文件系统称为云。
它具有几个属性。 首先，它是用Python编写的，并且积极地使用Unix管道，部分原因是因为它具有依赖性并且效率不高。 这是正常现象，因为WAL-E注重易用性和易于设置性，因此在制定备份计划时不会出错。 这是一个非常好的主意。
用WAL-E编写了许多功能，作者进一步开发它的地方对作者来说还不是很清楚。 我想到我需要一个新工具。
它的主要功能是用Go重写，如果不使用外部加密，几乎没有外部依赖关系，并且效率更高。
WAL-G最初是由两位来自Citus Data的作者创建的，其主要优势在此直方图中得以显示-发送“轴”的速度。 我们看到WAL-E速度很快，可以是任何东西，也可以是接近零的大列。
WAL-G具有相当稳定的带宽。 在Citus Data的测试中，他表明他稳定地发送了大约800 Mb / s的“轴”。
另外，例如，在WAL-G中，我编写了一项功能，该功能实现了副本的备份。 您不需要用读取负载来加载数据库主数据库，您可以从副本数据库中删除备份。
但是有一个小问题。 在开始进行备份的那一刻，应该以某种方式命名备份。 该名称包括一个时间轴，如果升级了副本，它将被更改。 如果您要备份的副本之前的副本链中发生了故障转移，您会注意到某些副本，时间线将被更改。 WAL-G理解这种情况是不一致的，因为在旧的时间轴上有一个名称，该名称向您保证可以继续在任何现有方向上开发数据库历史记录。 但是事实并非如此。 您已经去过其中一个指示；您无法使用后座汽车跳至另一个时间轴。 因此，WAL-G会了解这种情况，并且不会将财务JSON文件上传到云中。 您创建一个物理副本。 但是需要管理员干预，以便可以使用此副本。
我们已经在WAL-G中实现了增量副本，我也致力于此开发。 这样，您可以在下一次基本备份中获取较少的数据，而不必复制与上次备份相比没有更改的那些数据页。
设置WAL-G时，您指定与基本备份，增量备份最远的步骤数，并指定增量复制策略。 您可以从最后一个现有增量创建副本，也可以从原始完整备份创建增量。 当同一数据库组件始终在数据库中更改而同一数据在不断更改时，这是必需的。
为什么原则上我们需要数据库的增量副本？ 从理论上讲，您拥有WAL，因此您可以在任何地方滚动。
在繁忙的服务器上，播放过去五个物理秒的WAL可能需要当前四个物理秒。 如果要求您在四天内推出WAL，则意味着要求这样做的人可能还要再等待三天。 并非总是可以接受的情况。
您每天都需要基础备份，但是，尽管WAL-G会存档它们，但仍不能在其中保留7或14个数据库的完整副本。 在这种情况下，增量复制会有所帮助。
开发增量副本时，讨论了几种可能的数据文件格式。 首先，提出了格式，当我们不使页面不稳定时，我们只需将其无效即可。 但是我们得出的结论是，这不是一种非常有效的方法，然后对零进行有效地压缩，但是随后我们拒绝了这种存储方法，因为在紧急情况下很难对其进行调试。
考虑的下一个技术是首先存储块号，然后存储更改的块。 但是在这里，我们面临着TAR文件中存储的特殊性，我们需要首先指出要在其中存储增量副本的TAR文件的大小，然后再开始记录它。 我想以最少的RAM消耗来实现该技术，因此我们必须使用第三种格式，即首先完全读取每个数据文件，查找更改的数据页，首先将更改的块的编号存储在TAR文件中，然后才更改的块本身。
此功能尚未实现。 我正在寻找她，或者正在寻找想要在WAL-G中提出拉取请求的人。 从增量副本中恢复时，数据库在增量备份的每个步骤中都保留了数据库的每次重新生成。 有时在生活中某些文件会被删除。 同时，如果它们被删除，然后从增量副本中重新创建，我们将不必担心它们的状况。 这似乎不是一个非常复杂的功能，所以如果您有兴趣在Go上编写某些内容，请查看此功能。
安排有关网络，CPU和磁盘的使用情况。 正如我们所看到的，在WAL-E上，备份尚未结束，它是从早上一开始在莫斯科开始的，直到我们看到的最后一份报告都没有结束。 WAL-G计划已结束，它可以更快地工作，甚至在资源消耗方面也要多得多。
最有趣的是增量复制期间的资源消耗图。 我们看到所有资源几乎都为零。 CPU上的负载几乎是数据库上的标准负载；在晚上，会执行一些查询。 我们看到大量的阅读。 我也处理它，我也想提出请求，否则我会在夏天自己处理。 最重要的是，我们仍然必须读取我们的数据以找出其中发生了什么变化。 该阅读本可以避免。
当我们指出备份的数量或需要存储所有WAL和所有基本备份的日期时，WAL-G中就会删除。 WAL-G已经在解决需要什么WAL和基本备份的问题。 到目前为止，我们还没有可以删除所有内容的功能。 在WAL-E中，也是一个请求请求的场合。 一个有趣的DELETE EVERYTHING命令尚未实现。
有一个备份列表。
我们设置WAL-G起作用所需的环境变量，并调用控制台实用程序WAL-G。 显示我们需要查看的备份。
WAL-G实现了许多技术来并行化备份和通常的各种操作。 例如，该技术用于将“轴”发送到存档。 PostgreSQL调用archive_command发送一个文件后，WAL-G就会查看附近是否有更多文件准备就绪。
通常，这不是一个非常详尽的功能，它在最新版本的PostgreSQL中非常稳定，许多技术都在使用它。 我们查看存档状态下是否有现成的WAL文件，并将它们与要求将数据库发送到存档的文件一起发送。 当PostgreSQL要求他们发送时，我们已经发送了，我们已经准备好了。 这大大加快了在已加载的基础上发送WAL的速度，并使您使其不成为单线程。 通常，PostgreSQL准备一个文件，然后等待它运行，准备下一个文件。 我们设法避免这项连贯的工作。
在WAL-FETCH期间，在还原群集时，我们还将尝试下载以下N个文件，并尝试平衡新WAL文件预填充开始之间的暂停，以便我们可以利用我们拥有的所有资源：运行到网络或网络中。在极少数情况下会碰到磁盘。
这全部由环境变量设置。
也有并发制作副本。 尽管此功能在多个版本中均不存在-A.B.已于2018年6月在版本0.1.10中发布-因为从磁盘读取的并行性可以确保您运行到网络或磁盘中。 对于已加载的数据库，这不是很好。 WAL-E具有允许节流的功能。 到目前为止，我们还没有这个。 有必要限制备份删除的速度，以便该基地能够度过自己的生命并服务于负载。
我们的主要功能与技术无关。
两年前，Zhenya Dyukov为Barman实施了
增量备份技术 ，该
技术尚未举行，社区仍在讨论中。
大约一年前，Zhenya修复了WAL-E错误，我们将其发送了六个月（
链接到GitHub-大约编辑）。 在开放源代码解决方案中，经常会出现一个问题，即它们的维护得不够好。
使用WAL-G，一切都非常简单：我们使用并维护它。 如果我们或您需要某些东西，只需报告您有问题。 我们将尝试解决它。
社区的标准要求很简单-“让我们去做最多。”
更多密码，更多平台。 也许不仅是PostgreSQL，而且MySQL仍在备份或其他？ 我看到其他一些事情。
首先，现在在发送“轴”时，我们可以了解哪些数据库块已更改，扫描这些WAL文件并保存有关已更改内容的信息。
当cron提供另一个增量备份时，我们将无法扫描整个数据库，无法读取磁盘上的文件，也无法知道我们需要将哪些页面拖到云中。
我们试图使用页面跟踪技术。 它在数据库内核级别实现页面更改的跟踪。 备份被快速删除。 PTRACK的主要问题是它具有很高的侵入性。 它在非常敏感的地方对PostgreSQL内核进行了许多更改，因此不太可能很快被采用。
此外，其增量与我们现在拥有的增量略有不同。 删除基于LSN的增量时，我们将删除增量文件中从上次开始到当前时间的所有更改。
对于PTRACK，我们从先前收到的增量开始，在增量文件中进行更改。 在备份开始之前，更改开始之前，我们没有确切的增量时间。 通常，这不是PTRACK的主要问题，它运作良好，但是到目前为止很难接受。
PTRACK不允许在LATEST_FULL模式下删除增量，因为它存储了先前删除该映射后已更改的块的映射。 Oracle有一项有趣的技术，为防止万一，以前保存了8张卡。 也许我们可以做类似的事情，但是到目前为止我们还没有朝这个方向努力。
去年9月，我尝试基于以下事实为社区提供技术：我们仅将所需的钩子添加到内核，然后对扩展中的更改页面进行跟踪，以使页面跟踪补丁不会太具有侵入性。 在讨论了这项技术之后，我们得出的结论是我们需要几个原型，并且在有原型时我们将添加钩子。 也许我们会看看它们是如何工作的。 我目前正在研究这些扩展的原型，这些扩展可以使用内核挂钩来跟踪数据库更改。
社区中有一种表达，即每个postgresista必须拥有自己的备份工具。 不好 每个人都做自己的事，这是关键任务。 必须有一件事，一切都将在盒子里，在理想的世界中，一切都会完美。
我想在basebackup的框中看到什么？ 我们可能希望看到归档到云中。 和增量副本。
我还希望压缩，并发，加密，限制，备份列表，验证，备份验证……很多事情。 我们知道，如果现在将所有这些内容提供给社区，将导致产生数十个补丁，而这些问题很难通过commitfest进行讨论和实施。 因此，现在我们仍在使用单独的工具，但是希望将时间和技术投入社区，以使PostgreSQL更好。