在这篇文章中，我们将了解最近在Azure数据库中为PostgreSQL引入的高可用性功能。
简介
数据库承载着交易型、分析型、关系型、结构型、半结构型、键值型、文档型和各种类型的数据格式。尽管数据库可以承载各种数据类型，但从数据消费的角度来看，数据库的一些方面是共同的，如数据安全、数据治理、数据可用性等。根据数据的性质和消费的性质，一些类型的数据可用性对时间的要求并不高，可以通过奢侈的时间来处理以及提供。但许多类型的数据通常是交易性数据或对决策至关重要的数据，可能对时间非常关键，需要高可用性。任何由服务器故障、连接故障等事件造成的停机，使数据不可用，都是不可接受的，也会对业务造成很大影响。由于这个原因，在设计数据解决方案时，高可用性仍然是最优先的功能之一。
为了解决高可用性问题，使用了不同类型的方法，如数据复制和同步、服务器故障切换、DNS交换等，以解决托管数据的主服务器不可用的事件。几乎所有的数据库都采用的一般解决方案是创建一个或多个副本，当主服务器不在时，这些副本就可以使用。Azure云平台提供各种数据库服务，如Azure SQL、Azure MySQL数据库、Azure CosmosDB、Azure PostgreSQL数据库和其他。本文将帮助我们了解PostgreSQL的Azure数据库的高可用性特点。
创建一个Azure数据库的PostgreSQL实例
探索PostgreSQL的Azure数据库的高可用性功能的第一步是创建它的实例。假设你有Azure云平台的必要访问权，并有管理Azure Database for PostgreSQL服务的权限。导航到Azure Database for PostgreSQL的仪表板，点击创建按钮。这将唤起一个新的数据库创建向导，如下图所示。第一步是选择我们打算创建的PostgreSQL服务器的版本。提供了四个版本来创建PostgreSQL实例 - 单一服务器、灵活服务器、超大规模服务器和Azure Arc启用的PostgreSQL，如下所示。
我们打算创建一个高可用性的配置，所以我们需要选择灵活服务器选项。如果我们选择单服务器选项，在本文的草稿中，它不提供高可用性功能。一旦我们选择这个选项，我们将被导航到一个屏幕，如下图所示。提供实例的主要细节，如订阅、资源组、服务器名称和区域。对于我们的用例，我们也可以继续选择开发作为选项。默认情况下，选择的选项是生产，如下图所示。
向下滚动，你会发现其余的细节，如下所示。我们可以根据需要选择计算和存储容量。现在，我们可以继续使用容量、可用性区域和PostgreSQL版本的默认选项。
配置的下一个部分是高可用性部分。如上图所示，它在默认情况下是不启用的。如果我们选择启用高可用性配置，它将在一个单独的可用性区域创建一个主实例的备用副本，并采用自动故障切换配置。这意味着主实例以及备用实例之间的复制和同步是由Azure Database for PostgreSQL服务管理的。监测主实例的可用性并切换到备用实例，也就是所谓的故障转移，也是由Azure Database for PostgreSQL服务器执行的。我们确实可以选择何时执行故障转移，以及测试故障转移的经验，以了解在故障转移发生时的预期和如何管理依赖于数据库实例的系统。我们将在本文的后半部分了解这一点。下面是高可用性和故障切换过程的示意图。
启用高可用性配置后，提供实例的用户名和密码相关细节，然后点击网络按钮。在这一部分，我们需要配置网络连接。默认情况下，公共访问被选中。我们可以继续使用这种连接模式，因为在我们的练习中，我们需要从一台本地机器上连接到这个实例。我们还需要将我们的机器，即客户端IP添加到防火墙设置中，以允许从我们的本地机器到正在创建的实例的传入连接。完成这些配置后，我们可以选择向实例配置添加标签，最后审查配置并启动新实例的创建。
创建一个按钮来创建一个新的实例。在激活高可用性配置的情况下，数据库实例可能需要几分钟的时间才能被创建。实例创建后，导航到实例的仪表盘，你会发现在仪表盘的左边窗格中有一个名为高可用性的菜单项。点击这个项目，你会发现如下所示的细节。
一旦高可用性配置到位，重点就转移到规划故障转移和建立其他系统的准备工作，以便在故障转移过程中保持一致。停机可以是有计划的，也可以是无计划的，取决于导致停机的情况。当故障转移发生时，与主实例的连接可能会在一段时间后停止，随后的连接将被路由到备用实例，现在将成为主实例。一个新的待机实例将被创建。这个过程在下图中得到了解释。
上述故障转移过程发生在一个意外事件发生的情况下，该事件会使主实例瘫痪。但有时，人们也希望以有计划的方式进行故障切换--为了测试在发生故障时如何应对，或在预定时间内执行故障切换，以便其他系统不会因为不及时的故障切换而受到影响。这些功能是在前面的高可用性页面上提供的，如上图所示。假设我们想启动一个强制故障切换，以测试与数据管道集成的上游和下游应用程序或直接与实例集成的应用程序在故障切换期间将受到何种影响。对于这样的分析，我们可以通过点击强制故障切换按钮来启动强制故障切换。它将调用一个弹出窗口，其中的信息如下所示。
该弹出窗口将明确指出，故障转移过程将把主实例切换到备用实例。将会有停机时间，恢复的时间可能因正在进行的操作和最后的数据库检查点而异，同时数据库也将不可用。点击 "OK"，体验一下故障转移过程中会发生什么，并记录故障转移完成的时间。为了测试实例何时可达，何时不可达，可以使用pgAdmin这样的工具来连接到实例。
另一种模式是计划性故障切换。我们可以点击Planner Failover按钮，它将显示一个弹出窗口，如下图所示。这种故障切换模式是一种更优雅的故障切换形式，故障切换不需要立即发生。备用服务器将首先被准备好，然后发生切换。这有助于减少停机时间，因为主实例不会立即停机，一旦发生切换，在几秒钟内实例就会可用。考虑使用pgAdmin这样的工具来测试停机时间，以评估强制故障切换与计划故障切换之间在停机时间上的差异，前者是突然的故障切换，后者是较慢但更优雅的故障切换。
Azure Database for PostgreSQL中的这些新的故障转移选项提供了测试故障转移的影响以及计划故障转移的选项。
总结
在这篇文章中，我们了解了高可用性和数据库故障切换的重要性。我们探讨了在Azure Database for PostgreSQL中配置高可用性的方法，并了解了Azure Database for PostgreSQL中新引入的故障转移测试选项，以测试和规划故障转移过程。
