Azure Database for MySQL - 单一服务器服务层级
适用于： 
Azure Database for MySQL - 单一服务器
重要
Azure Database for MySQL 单一服务器即将停用。 强烈建议升级到 Azure Database for MySQL 灵活服务器。 有关如何迁移到 Azure Database for MySQL 灵活服务器的详细信息，请参阅 Azure Database for MySQL 单一服务器发生了什么情况？
在“基本”、“常规用途”和“内存优化”这三个不同的服务层级中，Azure Database for MySQL 服务器可以在其中的一个服务层级中创建。 服务层级的差异表现在可以预配的 vCore 中的计算量、每个 vCore 的内存，以及用于存储数据的存储技术。 所有资源都在 MySQL 服务器级别预配。 一个服务器可以有一个或多个数据库。
| 属性 | 基本 | 常规用途 | 内存优化 |
|---|---|---|---|
| 计算的代 | 第 4 代、第 5 代 | 第 4 代、第 5 代 | 第 5 代 |
| vCore 数 | 1, 2 | 2, 4, 8, 16, 32, 64 | 2, 4, 8, 16, 32 |
| 每个 vCore 的内存 | 2 GB | 5 GB | 10 GB |
| 存储大小 | 5 GB 到 1 TB | 5 GB 到 16 TB | 5 GB 到 16 TB |
| 数据库备份保留期 | 7 到 35 天 | 7 到 35 天 | 7 到 35 天 |
可以从下表着手来选择定价层。
| 服务层级 | 目标工作负荷 |
|---|---|
| 基本 | 需要轻型计算和 I/O 性能的工作负荷。 示例包括用于开发或测试的服务器，或不常使用的小型应用程序。 |
| 常规用途 | 大多数业务工作负荷。此类工作负荷需要均衡的计算和内存以及可缩放的 I/O 吞吐量。 相关示例包括用于托管 Web 和移动应用的服务器，以及其他企业应用程序。 |
| 内存优化 | 高性能数据库工作负荷。此类工作负荷需要内存中性能来实现更快的事务处理速度和更高的并发性。 相关示例包括用于处理实时数据的服务器，以及高性能事务性应用或分析应用。 |
注意
目前不支持向/从基本服务层级动态缩放。 基本层 SKU 服务器不能扩展到常规用途或内存优化级别。
创建常规用途或内存优化服务器后，可以在数秒内更改 vCore、硬件生成和定价层的数目。 也可在不关闭应用程序的情况下，独立调整存储容量（向上调整）和备份保留期（上下调整）。 创建服务器之后，不能更改备份存储类型。 有关详细信息，请参阅缩放资源部分。
计算代数和 vCore 数
计算资源以 vCore 的形式提供，代表基础硬件的逻辑 CPU。 中国东部 1、中国北部 1、美国 DoD 中部和美国 DoD 东部利用基于 Intel E5-2673 v3 (Haswell) 2.4-GHz 处理器的第 4 代逻辑 CPU。 所有其他区域均利用基于 Intel E5-2673 v4 (Broadwell) 2.3-GHz 处理器的第 5 代逻辑 CPU。
存储
预配的存储是指可供 Azure Database for MySQL 服务器使用的存储容量。 此存储用于数据库文件、临时文件、事务日志和 MySQL 服务器日志。 预配的总存储量也定义了可供服务器使用的 I/O 容量。
Azure Database for MySQL – 单一服务器支持服务器的以下后端存储。
| 存储类型 | 基本 | 常规用途 v1 | 常规用途 v2 |
|---|---|---|---|
| 存储大小 | 5 GB 到 1 TB | 5GB 到 4TB | 5 GB 到 16 TB |
| 存储增量大小 | 1 GB | 1 GB | 1 GB |
| IOPS | 变量 | 3 IOPS/GB 至少 100 IOPS 最大 6000 IOPS |
3 IOPS/GB 至少 100 IOPS 最大 20,000 IOPS |
注意
基本存储不提供 IOPS 保证。 在“常规用途”存储中，IOPS 使用已预配的存储大小，按 3:1 的比例进行缩放。
基本存储
基本存储是支持基本定价层服务器的后端存储。 基本存储使用的是后端中的 Azure 标准存储，而后端中不提供预配 iops 保证，且延迟可变。 基本层最适用于需要轻量计算、低成本与 I/O 性能（用于开发或小规模低频使用的应用程序）的工作负载。
常规用途存储
常规用途存储是支持“常规用途”与“内存优化”层服务器的后端存储。 在“常规用途”存储中，IOPS 使用已预配的存储大小，按 3:1 的比例进行缩放。 有两代常规用途存储，如下所述：
常规用途存储 v1（最高支持 4 TB）
常规用途存储 v1 基于传统存储技术，最高可支持每个服务器 4 TB 存储及 6000 IOP。 优化后的常规用途存储 v1，可利用运行 MySQL 引擎的计算节点中的内存，进行本地高速缓存及备份。 常规用途存储 v1 上的备份过程，是从计算节点内存中的数据和日志文件中读取数据，再将其复制到目标备份存储中，最多可保留 35 天。 因此在备份期间，存储的内存及 io 消耗都相对较高。
所有 Azure 区域都支持常规用途存储 v1
对于常规用途存储 v1 上的“常规用途”或“内存优化”服务器，建议考虑
- 规划计算 SKU 层，令存储高速缓存和备份缓冲区的多余内存占比达 10-30%
- 预配比数据库工作负载所需还高 10% 的 IOP，以考虑备份 IO
- 或者，如果下方共享的首选 Azure 区域中的基础存储基础结构可用，则可迁移到下述最高支持 16 TB 存储的常规用途存储 v2。
常规用途存储 v2（最高支持 16 TB 存储）
常规用途存储 v2 基于最新的存储基础结构，最高可支持 16 TB 及 20000 IOP。 在基础结构可用的 Azure 区域的子集中，所有新预配的服务器默认都位于常规用途存储 v2 上。 与常规用途 v1 存储相比，常规用途存储 v2 不占用 MySQL 计算节点的任何内存，并且可提供更好的可预测 IO 延迟。 常规用途 v2 存储服务器上的备份基于快照机制，无需额外的 IO 开销。 对于存储及预配 iops 相同的 MySQL 服务器，其在常规用途 v2 存储上的预期性能，比在常规用途存储 v1 上的预期性能要高。最高支持 16 TB 存储的常规用途存储无需额外的成本支出。 若要获得有关迁移到 16 TB 存储的帮助，请从 Azure 门户创建支持工单。
以下 Azure 区域支持常规用途存储 v2：
| 区域 | 常规用途存储 v2 的可用性 |
|---|---|
| 澳大利亚东部 | ✔ |
| 澳大利亚东南部 | ✔ |
| 巴西南部 | ✔ |
| 加拿大中部 | ✔ |
| 加拿大东部 | ✔ |
| 美国中部 | ✔ |
| 美国东部 | ✔ |
| 美国东部 2 | ✔ |
| 东亚 | ✔ |
| Japan East | ✔ |
| 日本西部 | ✔ |
| 韩国中部 | ✔ |
| 韩国南部 | ✔ |
| 北欧 | ✔ |
| 美国中北部 | ✔ |
| 美国中南部 | ✔ |
| 东南亚 | ✔ |
| 英国南部 | ✔ |
| 英国西部 | ✔ |
| 美国中西部 | ✔ |
| 美国西部 | ✔ |
| 美国西部 2 | ✔ |
| 西欧 | ✔ |
| 印度中部 | ✔ |
| 法国中部* | ✔ |
| 阿拉伯联合酋长国北部* | ✔ |
| 南非北部* | ✔ |
注意
*在这些区域中，Azure Database for MySQL 公共预览版中拥有常规用途存储 v2
*对于这些 Azure 区域，可选择在常规用途存储 v1 和 v2 中创建服务器。 对于在公共预览版中使用常规用途存储 v2 创建的服务器，存在以下限制：
- 不支持异地冗余备份
- 副本服务器应处于支持常规用途存储 v2 的区域。
如何确定我的服务器正在运行的是哪类存储？
可以通过转到“设置”>“计算 + 存储”页找到服务器的存储类型
- 如果使用基本 SKU 预配服务器，则存储类型为基本存储。
- 如果使用常规用途或内存优化 SKU 预配服务器，则存储类型为常规用途存储
- 如果服务器上可预配的最大存储为 4 TB，则存储类型为常规用途存储 v1。
- 如果服务器上可预配的最大存储为 16 TB，则存储类型为常规用途存储 v2。
能否从常规用途存储 v1 移动到常规用途存储 v2？如果可以，如何操作，是否有额外的成本？
可以，如果基础存储基础结构在源服务器的 Azure 区域可用，则支持从常规用途存储 v1 迁移到常规用途存储 v2。 迁移和 v2 存储无需额外成本。
预配服务器后，能否增加存储大小？
在创建服务器的过程中和之后，可以添加更多的存储容量，这样系统就可以根据工作负荷的存储使用情况自动增加存储。
重要
存储只能增加，不能减少。
监视 IO 消耗
可以通过 Azure 门户或 Azure CLI 命令监视 I/O 使用情况。 要监视的相关指标包括存储限制、存储百分比、已用存储和 IO 百分比。具有常规用途存储 v1 的 MySQL 服务器的监视指标负责报告 MySQL 引擎所占用的内存和 IO，但限制在于，其可能无法捕获存储层的内存和 IO 消耗。
达到存储限制
对于预配存储小于或等于 100 GB 的服务器，如果可用存储少于预配存储大小的 5%，则会将其标记为只读。 对于预配存储超出 100 GB 的服务器，当可用存储不到 5 GB 时，会将该服务器标记为只读。
例如，如果已预配 110 GB 的存储，而实际使用量超过 105 GB，则会将服务器标记为只读。 或者，如果已预配 5 GB 的存储，则当可用存储少于 256 MB 时，服务器会标记为只读。
当服务试图将服务器标记为只读时，会阻止所有新的写入事务请求，现有的活动事务将继续执行。 当服务器设置为只读时，所有后续写入操作和事务提交均会失败。 读取查询将继续不间断工作。 增加预配的存储后，服务器将准备好再次接受写入事务。
我们建议你启用存储自动增长或设置警报，以便在服务器存储接近阈值时通知你，避免进入只读状态。 有关详细信息，请参阅有关如何设置警报的文档。
存储自动增长
存储自动增长可防止服务器耗尽存储空间并变为只读。 如果启用了存储自动增长，存储会在不影响工作负荷的情况下自动增长。 对于预配存储小于或等于 100 GB 的服务器，当可用存储小于预配存储的 10% 时，预配存储大小会增加 5 GB。 对于预配存储大于 100 GB 的服务器，可用存储空间小于预配存储大小 10 GB 时，预配存储大小会增加 5%。 适用上面指定的最大存储限制。
例如，如果已预配 1000 GB 的存储，而实际使用量超过 990 GB，则服务器存储大小会增加到 1050 GB。 或者，如果已预配 10 GB 的存储，则当可用存储少于 1 GB 时，存储大小会增加到 15 GB。
请记住，存储只能增加，不能减少。
备份存储
Azure Database for MySQL 最高可以提供 100% 的已预配服务器存储作为备份存储，不收取任何额外费用。 使用的任何备份存储量超过此数量将按每月 GB 量收费。 例如，如果为服务器配置了 250 GB 的存储空间，则可以为服务器备份提供 250 GB 的额外存储空间，而不收取任何费用。 超过 250GB 的备份存储量按定价模型收费。 若要了解影响备份存储使用率的因素、监视和控制备份存储成本，可以参考备份文档。
缩放资源
创建服务器之后，可以独立地更改 vCore 数、硬件生成、定价层（基本层的操作除外）、存储量和备份保留期。 创建服务器之后，不能更改备份存储类型。 可以向上或向下调整 VCore 数。 备份保留期可以从 7 天到 35 天进行上下调整。 存储大小只能增加。 可以通过门户或 Azure CLI 缩放资源。 有关使用 Azure CLI 进行缩放的示例，请参阅使用 Azure CLI 监视和缩放 Azure Database for MySQL 服务器。
更改 vCore 数、硬件生成或定价层时，将会使用新的计算分配创建原始服务器的副本。 启动并运行新服务器后，连接将切换到新服务器。 在系统切换到新服务器的短暂期间，无法建立新的连接，所有未提交的连接将会回退。 缩放期间的停机时间大约为 60-120 秒。 缩放期间的停机时间取决于数据库恢复时间，如果在执行缩放操作时服务器上有大量的事务活动，这可能会导致数据库需要更长的时间才能联机。 为了避免重启时间过长，建议在服务器上的事务活动较少的时段，执行缩放操作。
缩放存储和更改备份保留期是真正的联机操作。 不会造成停机，应用程序不会受影响。 当 IOPS 随已预配存储的大小缩放时，可以通过扩大存储来增加提供给服务器的 IOPS。
定价
有关最新定价信息，请参阅服务的定价页。 若要查看所需配置的具体成本，可以单击 Azure 门户的“定价层”选项卡，系统就会根据选定的选项显示每月成本。 如果没有 Azure 订阅，可使用 Azure 定价计算器获取估计的价格。 在 Azure 定价计算器网站上，选择“添加项”，展开“数据库”类别，选择“Azure Database for MySQL”自定义选项。
后续步骤
- 了解如何在门户中创建 MySQL 服务器。
- 了解服务限制。
- 了解如何使用只读副本进行横向扩展。