Microsoft Azure – Azure SQL 的数据库可用性和一致性

当您或您的公司决定将数据库从本地服务器/计算机迁移到云环境时，一致性和可用性是需要考虑的两个重要因素。

数据库一致性要复杂得多。这意味着无论您以何种方式或在何处访问数据，相同的查询都会为您提供相同的数据输出。这也意味着您的数据在应用程序故障、自然灾害等情况下保持完整。

在本文中，我们旨在简化 Azure Database for MySQL 如何在不同的部署选项中实现数据一致性和高可用性的目标。我们将概述以下概念：

了解 Azure 提供的两种部署模式
单服务器部署的可用性和一致性。
灵活部署的可用性和一致性。

关键术语

在开始之前，请先熟悉以下关键字：

PaaS：平台即服务
实例：在物理硬件上运行的虚拟服务器（在本例中为 Azure）
SLA：服务水平协议

Azure 中的部署模式

Azure Database for MySQL 是一种 PaaS（平台即服务）。这意味着 Azure 为您提供了 MYSQL 服务器的一个（或多个）实例。从修补到升级的一切都由 Azure 处理。对于这种模式，有 2 个可用的部署选项 -

单服务器部署：仅当您当前有一个使用单服务器的应用程序/工作负载并且您希望将其迁移到 Azure 云时，才建议使用此选项。单个服务器需要最少的用户定制。它在单个区域内提供了 99.99% 的可用性 SLA。
灵活的服务器部署：强烈建议将此选项用于生产工作负载。它非常灵活，允许您选择可用区、定价层、成本优化等。

现在您对部署节点有了基本的了解，让我们深入了解这两种模式的可用性和一致性。

可用性和一致性

对于单服务器部署

计划停机时间：例如，假设您开始在 Azure 数据库实例上使用 4 个虚拟内核。随着您添加越来越多的应用程序，您的数据库负载也会增加。要处理此问题，您可能需要增加虚拟内核。这是计划停机的一个实例。正如您在体系结构中看到的，Azure Database for MySQL 由单独的组件构建而成，例如

网关/代理
数据库服务器
Azure 存储

如果您需要扩大/缩小计算实例，则提供了一个新的数据库服务器。这发生在最短的停机时间。
扩展存储不需要停机。
升级、补丁修复和错误修复需要最少的停机时间，最长可达 60-120 秒。但是，建议用户在计划的停机时间内消除在其数据库实例上运行的繁重事务。
计划外停机：每当您的服务器面临意外停机时，Azure 会在一分钟内自动部署另一台服务器。对于 Azure 存储故障，没有停机时间。这是因为数据被复制了 3 次，如果一个副本失败，Azure 服务器会切换到从其他 2 个副本读取数据。
您还可以在多个 Azure 区域中配置 Azure只读副本（备份数据库副本），以确保在整个区域发生故障时进行灾难恢复 (DR)。

对于灵活的服务器部署：

有两种主要的设计模式：

区域冗余架构：这种设计将在可用区（如美国东部）创建一个主数据库服务器。具有完全相同配置的另一台服务器将放置在同一区域内的不同可用区中（如东部美国 2）。该模型提供更高的容错性，但传输流量的延迟更高。
同一区域架构：在此设计中，您的主服务器和辅助服务器都放置在同一可用区内。由于服务器物理上接近，数据传输更快，延迟更低。但是，容错性较低。
使用这两种架构，用户都可以为备份和数据库一致性提供只读副本。只读副本是 Azure 数据库的只读副本，旨在减少主服务器上的负载。您可以在此处找到阅读副本的详细指南。

Azure Database for MYSQL 具有一套全面的服务，可确保数据的可用性和一致性。有多种选项供您在不同的服务器、架构之间进行选择，并且只需为您使用的服务付费。