解锁 Azure：如何构建高度灵活的 SQL 数据库基础架构

近年来，基础设施即服务和平台即服务由于其功能，特别是资源效率和灵活性，在各种项目中变得越来越普遍，这已不是什么秘密。因此，微软花费了大量的时间和精力来创建一个用户友好的可以使用 SQL 的环境。

Social Discovery Group 团队使用包括 SQL 在内的各种数据库来为我们的产品提供支持。我们拥有 40 多项全球服务组合，有助于在全球范围内见面和联系，我们的用户群包括全球超过 2.5 亿人。为了保证我们产品对用户的可靠性，我们将部分关键基础设施保留在云端。这有助于增强其弹性、安全性和灵活性。

我们在各种平台（包括 Kubernetes 集群）上部署服务器和服务数据库方面拥有丰富的经验。然而，我们需要使 Azure 云中相关 SQL 数据库基础架构的一部分尽可能灵活、高效和可靠。在 Microsoft Azure 云中使用 SQL 的方法有 3 种：

• Azure SQL 数据库
• Azure SQL 托管实例
• Azure 虚拟机上的 SQL Server

经过研究，我们决定使用 Azure SQL 数据库。只是为了向那些从未听说过所谓的 Azure SQL 数据库的人澄清一下，它们是作为 Microsoft Azure 的一部分提供的托管云数据库。

我强调了以下好处：

• 无需担心更新或停产支持；
• 轻松配置和部署；
• 部署速度（以及开发速度）和可扩展性；
• 高可用性;
• 容错；
• 易于备份；
• 成本优化；
• 集成的 Microsoft Azure 监控系统。

现在我们一步一步来，看一下部署和创建数据库的过程。这可以使用 Power Shell 脚本或 Azure CLI 来完成，但为了清楚起见，我使用门户的图形界面查看该过程。为此，请转到 Azure SQL，单击“创建”，然后选择“SQL 数据库”。

我们指定资源组，选择是否存在现有服务器或创建一个新服务器（指示管理员的名称和数据），并为数据库命名。我建议选择基于 DTU（数据库事务单元）的捆绑包，并为我们的常见工作负载均衡地组合计算和存储资源。

还有一些设置选项卡：网络、安全、其他设置和标签；对于最低标准配置，默认情况下可以保持不变。然后我们等待数据库创建完成。这样就完成了最低限度的设置，基础也完成了。

数据库资源的大小可以非常轻松地更改，只需单击一下即可，并且在资源不足的情况下，我们可以在大小和性能方面设置我们需要的参数。

然后，您可以按照您喜欢的任何方式从外部连接到数据库，而无需忘记添加您的 IP 地址或子网，或者允许托管此数据库的服务器的防火墙中的所有连接。

通过 SQL Server Management Studio (SSMS) 可以方便地进行连接和进一步管理，但也可以通过其他工具和 Azure 门户本身来完成此操作。

除了公共连接点之外，您还可以通过将服务器添加到所需子网并配置私有 DNS 区域来创建私有连接点。

说到容错，这里我们看到了一种非常方便直观的故障转移实现，一组保护位于不同区域的服务器。

在 Azure 中，可以在故障转移组、强制故障转移和自动故障转移模式中的服务器上添加和删除数据库。

您可以在下面的屏幕截图中看到这一点。让我们为故障转移组命名，并将服务器置于故障转移状态。指定数据库的同步将自动开始。第二个服务器将处于只读模式。当发生故障时，流量自动切换到第二区域，主备服务器自动切换位置。

但如果数据库本身存在数据级问题，故障转移将无济于事。当然，在这种情况下，您需要创建备份。可以在门户内以及通过第三方工具或 Azure DevOps（在管道中，您可以使用 SqlAzureDacpacDeployment + AzureFileCopy 任务）来配置备份。在门户内，在“备份”选项卡上配置备份并设置必要的存储策略。

如果您更喜欢使用第三方备份工具，我建议考虑 Azure DevOps 或 SQL 包工具。

我认为门户网站本身的恢复过程不是很方便。您首先注意到的是简单测试数据库的恢复时间很长。例如，我花了半个多小时才从昨天的备份中恢复了一个30MB的基本大小的数据库！联系Microsoft Azure支持后，建议我使用PowerShell脚本进行恢复，并通知恢复过程的数据库大小至少应为S3，稍后可以减小大小。下面我将介绍我在这个主题上的一些脚本和开发，它们可以改进和增强，但我相信你们中的许多人会发现它们很有用。

我将带你一步一步：

1. 如果您没有在 Windows 上安装 PowerShell ISE，请在此处下载： https://github.com/PowerShell/Pohell/releases/download/v7.3.0/PowerShell-7.3.0-win-x64.msi
   https://github.com/PowerShell/PowerShell/releases/download/v7.3.0/PowerShell-7.3.0-win-x86.msi
2. 接下来，需要安装Azure模块：Install-Module Az
3. 安装AZ模块后，导入AZ模块：Import-Module Az
4. 导入后，您可以连接到您的 Azure 帐户：Connect-AzAccount。将出现一个弹出窗口，要求您登录您的 Azure 帐户，然后您就可以连接
5. 运行 PowerShell 脚本本身。

 “ #Variables in use $Database = Get-AzSqlDatabase -ResourceGroupName "Test" -ServerName "test-serv1" -DatabaseName "dbforscript" $TargetDB = "dbforscript_new" $PITRtimedate = "2022-12-02 10:00:00Z" ##вам нужно увидеть действительную дату и время на портале $PITRSLO = "S3" $PITRNEWSLO = "S0" $PITRedition = "Standard" $failoverGroupRG = "Test" $failoverGroupS = "test-serv1" $failoverGroupDB = "dbforscript" $removedbfromfgRG = "Test" $removedbfromfgS = "test-serv1" $removedbfromfgDB = "XXXXX" $dropreplicaRG = "Test" $dropreplicaS = "test-serv2" $dropreplicaDB = "dbforscript" $sourcedbRG = "Test" $sourcedbS = "test-serv1" $sourcedbDBname = "dbforscript" $sourcedbDBNEWname = "dbforscript_old" $TargetDBNEWname = "dbforscript" “

1 - 此代码使用不同的名称启动数据库恢复。如果正在恢复的数据库的原始名称是“dbforscript”，则恢复的数据库的名称将为dbforscript_new。恢复的数据库将是 SLO 版本 S3 或更高版本，这是执行此操作的推荐方法，其变量为 $PITRSLO = "S3"，您可以使用 S3 或更高版本。此后，我们会将 SLO 级别重置为原始级别，这仅用于恢复。

 “Restore-AzSqlDatabase -FromPointInTimeBackup -PointInTime $PITRtimedate -ResourceGroupName $Database.ResourceGroupName -ServerName $Database.ServerName -TargetDatabaseName $TargetDB -ResourceId $Database.ResourceID -Edition $PITRedition -ServiceObjectiveName $PITRSLO”

2 - 此代码将从故障转移组中删除源数据库：源数据库：dbforscript。

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $failoverGroupdb | Remove-AzSqlDatabaseFromFailoverGroup -ResourceGroupName $removedbfromfgRG -ServerName $removedbfromfgS -FailoverGroupName $removedbfromfgDB”

3 - 此代码将从副本数据库所在的服务器中删除副本数据库：test-serv2 服务器上的 dbforscript。

 “Remove-AzSqlDatabase -ResourceGroupName $dropreplicaRG -ServerName $dropreplicaS -DatabaseName $dropreplicaDB”

4 - 此代码会将原始数据库重命名为不同的名称：重命名后，dbforscript 将是 dbforscript_old。

 “Set-AzSqlDatabase -ResourceGroupName $sourcedbRG -DatabaseName $sourcedbDBname -ServerName $sourcedbS -NewName $sourcedbDBNEWname”

5 - 此代码会将恢复的数据库重命名为原始数据库名称，将 dbforscript_new 重命名为 dbforscript。

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDB -ServerName $Database.ServerName -NewName $TargetDBNEWname”

6 - 此代码会将数据库 SLO 级别返回到之前的（原始）S0 值。如果您的数据库是基础数据库，请在门户中从 S0 升级到基础数据库。

 “Set-AzSqlDatabase -ResourceGroupName $Database.ResourceGroupName -DatabaseName $TargetDBNEWname -ServerName $Database.ServerName -Edition $PITRedition -RequestedServiceObjectiveName $PITRNEWSLO -MaxSizeBytes 10737418240”

7 - 最后一个代码将恢复的数据库添加到故障转移组，该组已经具有原始名称（因为我们在前面的代码中更改了它）。

 “$failoverGroup = Get-AzSqlDatabase -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -DatabaseName $TargetDBNEWname | Add-AzSqlDatabaseToFailoverGroup -ResourceGroupName $failoverGroupRG -ServerName $failoverGroupS -FailoverGroupName $removedbfromfgDB”

可以考虑在命令后面添加--ErrorAction Stop参数。这样可以防止出现错误时执行以下命令，并且不会出现滚雪球的情况。

另外，您可以在脚本的开头和结尾添加Get-Date来计算执行时间。就我而言，通过这样的脚本在不到 6 分钟的时间内恢复了大约 3.3 GB 的数据库。

如果您愿意，您当然可以优化脚本、通过 Azure DevOps 添加它、减少变量数量或硬编码某些内容，但我已尝试以每个人都能理解的方式尽可能详细地描述它。

Azure 上的数据库监控以及与 Datadog 等各种系统集成的能力值得特别关注。监控非常方便，但并非没有细微差别（例如，在撰写本文时，只读用户只能看到对一个数据库的监控，而不是一次看到所有数据库......好吧，这是阴影）。

总之，我们的团队成功地优化了费用，同时也解决了与更新和支持中断相关的问题。我们在性能、弹性、开发速度和灵活性方面取得了进步。此外，脚本的实施显着增强了我们在需要时快速恢复的能力。

由 Social Discovery Group 首席 DevOps 工程师 Pavel Shapurau 撰写。