更新50 Terabyte PostgreSQL数据库

由于一些原因，我们在Adyen的数据库设置是唯一的。我们目前在多个集群中处理每秒5,000+ PostgreSQL事务。此外，作为处理敏感的财务数据的付款服务提供商，冗余比正常更为关键，并且停机是不可接受的。

最重要的是，我们以快速的速度缩放我们的基础架构。 2015年，我们的数据库低于10岁。但我们最新的升级为50岁，仍然快速增长。随着全球数字付款卷预计到2020年，我们需要达到超过7000亿美元的年度交易，我们需要考虑比现在更大的卷。

在这篇文章中，我将了解Adyen的不断发展的方法来更新我们的PostgreSQL数据库，以防止冗余，正常运行时间和可扩展性提出的要求和挑战。

我的同事Michiel在选择解决方案时，我们如何在我们如何在选择“无情”时写道。我们做出了仔细决定，为解决方案的可靠性以及生态系统（支持，社区，文档等）的可靠性以及功能的成熟。我们使用PostgreSQL构建了数据库堆栈，因为它提供了我们需要的一致性，隔离和可靠性。此外，它是开放的来源，并拥有有源生态系统，包括多个支持和咨询公司。最后，当我们使用敏感的财务数据时，具有交易数据库的关键，因为它确保我们不会失去记录。

我们的PostgreSQL数据库群集包括一个主服务器和至少三个从服务器，传播多个数据中心。数据库服务器是双插座机，具有768 GB的RAM。每个服务器都使用光纤通道或iSCSI连接到自己的共享存储设备，并具有150多个Tberytes的SSD和平均压缩比为1：6的原始容量。

另一个详细信息要注意的是，我们以这样的方式构建了软件架构，即我们可以将流量停止到我们的PostgreSQL数据库，队列事务，并在不影响付款接受的情况下运行PostgreSQL更新。

最近作为2015年，我们的数据库需求更加简单。我们升级到新PostgreSQL版本的方法遵循以下步骤：

1.牺牲奴隶服务器。 2.将从站升级到新PostgreSQL版本。 3.使用镶嵌设置数据库的逻辑复制。 4.切换镶嵌主人。 5.将其他两个从站升级到新版本。 6.取下逻辑复制。 7.将上次从站升级到新版本。

在10岁的时候，我们花了几天时间在我们获得新的服务器上运行，而且这个过程正在变得逐渐变得更加耗时。此外，我们可以在长期内预见到卫生的潜在影响，因为在该过程中某些点处于处分奴隶而处死。在地平线上有一个50tbybyte数据库，所需的时间长度以及冗余的潜在风险开始变得不可接受。

到9.6的时间被释放，我们需要更聪明，更可扩展的解决方案。实际上，我们的选择有限。由于我上面概述的原因，继续持续逻辑复制是不可能的。 PostgreSQL透视图中唯一的其他选项是在主设备上运行pg_upgrade。但是，这意味着您只有一个大师，这也是冗余视角的不可接受的情况。

由于PostgreSQL选项不适合下一次升级，并行我们认为其他可能性。我们的存储设备能够在更小的时间范围内通过网络进行即时快照，并在远程存储设备上可用。我们开始结合选项，最终，我们的解决方案涉及以下步骤：

1.停止数据库群集的流量。 2.使用脚本在主服务器上运行PostgreSQL升级，以便尽可能多的步骤自动化。这种方法的优点是加快过程，使其轻松可重复。 （3-5分钟）3。停止升级的主机上的PostgreSQL并创建卷的快照。 （最多10分钟）4.将升级的主的快照复制到从站的存储设备。 （2-5分钟）5。重新启动主人。 6.将快照导入从服务器，在从服务器上安装（已升级的）主卷。 7.通过简单地放入正确的recovery.conf文件，将Slave Server重新连接到主站。 8.只有在线，连接和最新的站点至少有两个从站，我们允许再次访问群集。因此，在访问群集时从来没有瞬间，在线少于两个从头开始。 9.再次启动软件。

然后需要在所有集群中重复该过程。完全，该过程需要一天，包括准备工作。

1.一旦设置了，它就会相对容易，因为某些测试运行并编写脚本，可以自动执行许多步骤。 2.它非常快，因为后续快照只有原件的差异。实际上，要复制快照只需几分钟。 3.它符合我们对冗余的要求。在我们开始升级之前，我们会制作所有服务器的快照。如果升级在某些时候会失败，我们可以简单地恢复到旧快照。这意味着我们可能会失去一个小时的时间，但我们不会丢失任何数据或妥协冗余。

我们的新方法的美丽是，通过使用具有增加的容量的存储设备，通过添加更多群集和垂直地，可以继续无限制地缩放。 事实上，我们在过去一年中的活群数量增加了一倍，我们的最大群集已经长大到了74磅。 今年年晚些时候，我们期待着使用这种方法来更新到PostgreSQL 10.3+，没有任何与先前方法相关的头痛。