在迁移本地 MySQL 数据库时，为Oracle 云基础设施(OCI)中的MySQL HeatWave实例选择正确的配置需要评估当前的工作负载需求，并将其与可用的MySQL HeatWave 配置进行匹配。OCI 中的“配置”定义了分配给 MySQL 数据库系统 (DB System) 和 HeatWave 集群的计算资源（CPU、内存、最大网络带宽等）。以下是一份快速的分步指南，可帮助您做出明智的决策。如果您想收集有关 MySQL 实例的更多详细信息，请参阅此文 - “用于收集运行时统计信息以评估数据库性能的 MySQL 命令”。
了解您的本地工作负载
为了了解当前的工作负载，您需要了解数据大小、工作负载类型、查询性能要求和当前资源使用情况等信息。对于数据大小，您需要估算数据库的总大小，包括表、索引以及任何预期的增长。HeatWave 针对内存分析进行了优化，因此您计划使用 HeatWave 查询的数据必须能够容纳集群的内存。
您的工作负载主要是 事务性（OLTP）、分析性（OLAP），还是两者兼而有之？HeatWave 擅长加速分析查询，因此如果您要添加 HeatWave 集群，也请注意分析部分。
您正在运行哪些类型的查询？MySQL 在 OLTP 查询方面表现出色，但您需要确定分析查询的复杂性和频率。更复杂的查询或更高的并发性可能需要更高的计算能力或额外的 HeatWave 节点。 分析您的本地系统在峰值负载下的 CPU、内存和 I/O 使用情况，以建立基准，从而复制所需的计算能力，使其与您当前的本地系统相匹配。
HeatWave 形状
在 OCI 中，主要有两类形状 -用于MySQL DB 系统（OLTP）的ECPU 形状和用于 HeatWave OLAP 集群节点的 HeatWave 特定形状。
形态是一个模板，用于确定分配给 MySQL 数据库系统、HeatWave 集群节点或只读副本的 ECPU 数量、内存量和其他资源。数据库系统和 HeatWave 集群都有各自的形态。只读副本的形态可以与数据库系统相同或不同，但对于写入操作繁重的源实例，只读副本应与源数据库具有相同的形态，以便能够处理复制的事务而不会落后于源数据库。数据库系统或只读副本的每个形态都与一系列默认配置相关联。这些配置包含一组定义 MySQL 实例操作的变量。大多数形态有两种默认配置：
适用于 OLTP 的独立数据库系统：ECPU 配置与架构无关（支持 AMD 或 Intel 处理器），并且大多数 ECPU 配置支持 HeatWave 集群。ECPU 配置针对独立数据库系统和只读副本进行了优化。并且大多数配置（MySQL.8 及以上版本）支持只读副本。请参阅支持配置。
HA：针对高可用性数据库系统进行了优化。请参阅高可用性。
对于 OLAP，HeatWave 特定形状定义了 HeatWave 集群节点的资源，这些资源与数据库系统形状是分开的。示例包括 HeatWave.32GB（小型工作负载）和 HeatWave.512GB（大型工作负载）。
根据您的要求匹配形状
对于 MySQL 数据库系统 (OLTP)，您需要选择一种能够支持事务性工作负载的配置。该数据库系统负责处理所有传入的客户端连接、事务性 (OLTP) 查询，并作为 HeatWave 分析数据的来源。确定峰值负载期间的最大并发连接数。例如，如果您的本地 MySQL 在峰值时处理 500 个并发连接，则需要复制或超过该容量。每个连接都会消耗内存（例如，用于线程堆栈、缓冲区）和 CPU（用于查询处理）。高并发性会增加对 CPU 和内存的争用，如果容量不足，可能会降低性能。
例如，小型事务工作负载可能使用具有 4-8 个 ECPU 的形状，而混合 OLTP/OLAP 的高可用性 (HA) 设置可能需要 16+ 个 ECPU。
对于 HeatWave OLAP，根据您的分析数据大小和性能需求选择 HeatWave 形状。
- 对于 50 GB 以下的数据集，请使用 HeatWave.32GB。
- 对于更大的数据集使用 HeatWave.512GB，并根据需要扩展节点数量。
- 对于超过 10 TB 的数据集，与 MySQL.HeatWave.BM.Standard 配对并估算节点数。
在 Oracle 云控制台中配置 HeatWave 集群时，请使用“估算节点数”功能。输入您的数据大小和所选的存储类型（HeatWave.32GB 或 HeatWave.512GB），系统会提示所需的节点数。这有助于确保您的集群能够处理内存中的数据。
HeatWave 需要将数据加载到内存中进行分析，因此所有 HeatWave 节点的总内存必须超过您的分析数据集大小。例如：一个 1 TB 的数据集，使用 HeatWave.512GB（每个节点 512 GB）时，至少需要 2 个节点（1 TB ÷ 512 GB ≈ 2）。（前提是您决定不使用数据压缩。）HeatWave 会在加载数据时进行压缩，从而使 HeatWave 节点能够存储更多数据。每个节点的数据越多，通过最小化存储数据所需的 HeatWave 集群规模来降低成本。
虽然数据压缩会缩小 HeatWave 集群，但访问数据时进行的解压缩操作会对性能产生轻微影响。具体而言，解压缩操作对查询运行时间、变更传播期间查询卸载到 HeatWave 的速率以及从对象存储恢复的时间影响较小。如果不考虑数据存储大小，请在加载数据之前将rapid_compression会话变量设置为OFF来禁用数据压缩。
您可以添加更多节点，以实现冗余、性能或更大的数据集。最低节点数为一个，但最高节点数取决于您的租户限制和工作负载。
关键形状考虑因素
确保 MySQL DB 系统和 HeatWave 实例中的 ECPU 和内存数量可以处理峰值连接数，需要重点分析工作负载的并发性、资源需求以及 DB 系统和 HeatWave 集群的特定角色。
数据库系统（运行 MySQL）负责处理所有传入的客户端连接、事务性 (OLTP) 查询，并作为 HeatWave 分析数据的来源。HeatWave 集群负责加速分析性 (OLAP) 查询，并且不直接管理客户端连接——它依靠数据库系统将查询路由到它。因此，峰值连接处理主要由数据库系统负责。
确定峰值负载期间的最大并发连接数。例如，如果您的本地 MySQL 在峰值时可处理 500 个并发连接，则您需要在云端复制或超过该容量。请记住 - 每个连接都会消耗内存和 CPU。高并发性会增加 CPU 和内存的争用，如果形状过小，可能会降低性能。
逐步方法 - 评估当前峰值连接负载
您将需要评估当前本地 MySQL 实例上的当前峰值连接负载：
在峰值使用率期间运行SHOW STATUS LIKE ‘Threads_connected’;来查看活跃连接数。
使用SHOW VARIABLES LIKE ‘max_connections’;来查看配置的限制（默认值为 151，但通常会增加）。在峰值负载期间
监控 CPU 和内存使用情况（例如，通过top或htop），以便与连接数关联。
例如，您可能会发现当前实例有 500 个峰值连接、8 核 CPU 使用率为 70%、使用了 32 GB 内存。
估计每个连接的资源需求
MySQL 根据以下设置为每个连接分配内存：thread_stack（默认 256 KB）、read_buffer_size、sort_buffer_size等。粗略估计每个连接 0.5-2 MB，具体取决于查询复杂度和配置。因此，对于 500 个连接：500 × 1 MB（平均值）= 最小 500 MB，加上额外的缓冲区。
每个连接的 CPU 需求实际上取决于查询类型。简单的 OLTP 查询可能只使用一小部分核心，而复杂的查询则需要更多核心。假设每个活动连接使用 0.01-0.05 个 ECPU 作为起始值。例如：如果您的峰值连接数为 500 个：500 × 0.02 个 ECPU = 峰值期间至少使用 10 个 ECPU。这里的关键词是“最小值”——您肯定需要在概念验证期间改进此公式。
如果您使用 HeatWave 集群（用于 OLAP），请记住 HeatWave 不会直接管理连接，因为查询是通过数据库系统路由的。因此，数据库系统的 ECPU 必须承担将分析查询卸载到 HeatWave 的开销。如果您的 500 个连接中有 20%（100 个）正在运行分析查询，请确保您的数据库系统拥有足够的 ECPU 来管理这些连接，同时 HeatWave 负责处理复杂的查询。
选择数据库系统形状
Oracle Cloud 基于 ECPU 的配置将计算和内存同时定义。对于 ECPU，请满足或超出您的峰值 CPU 需求。对于 500 个连接，每个连接占用 0.02 个 ECPU，请从 10-16 个 ECPU 开始。对于内存，请考虑连接开销、InnoDB 缓冲池（用于数据/索引缓存）和操作系统开销。对于 500 个连接 + 32 GB 基准，目标内存为 40-64 GB（5-8 个 ECPU，每个 ECPU 占用 8 GB）。具有 16 个 ECPU（128 GB 内存）的配置可为 500 个连接和中等 OLTP 负载提供余量。
MySQL 配置变量
配置具有一组默认的用户变量、系统变量或初始化变量。您可以编辑用户变量和初始化变量，但不能编辑系统变量。
HeatWave 维护着几个用于配置其运行的变量。这些变量在 HeatWave 集群启用时设置。大多数 HeatWave 变量设置由 OCI 管理，无法直接修改。
在数据库系统配置中将 max_connections 设置为大于峰值负载。例如，如果峰值连接数为 500 个，则将此数字设置为 600，这样 500 个连接加上一个缓冲区即可。
需要检查一些与内存相关的变量。MySQL HeatWave 中innodb_buffer_pool_size的默认值 并非明确固定，而是根据实例大小和工作负载自动配置的。为了优化性能，MySQL HeatWave 通常会将实例内存的 70% 到 80% 分配给 InnoDB 缓冲池。请务必检查该值，确保其至少为可用数据库系统内存大小的 70%，但不要超过 80%。 除非您有需要进行一些调整的特定工作负载，否则我不会更改其他内存变量（例如thread_stack、 read_buffer_size等）的推荐值。
在 POC 期间，请监控threads_running（活跃查询）与threads_connected（总连接数）的对比，以确保 CPU 和内存充足。务必为 ECPU 和内存预留一个缓冲区（20-50%），以应对意外的活动高峰和未来的增长。
考虑附加功能
如果您需要高可用性 (HA)，请选择具有足够资源以支持三个 MySQL 实例（主实例 + 两个辅助实例）的配置。HeatWave 集群将连接到主实例。
如果您计划通过 HeatWave Lakehouse 查询对象存储中的数据，请确保您的形状支持它（例如，MySQL 8.4.0-u3 之前版本的 HeatWave.512GB 或 MySQL.HeatWave.VM.Standard）。
别忘了增长——要考虑未来数据的增长和可扩展性。ECPU 的配置允许灵活地进行后期扩展。
测试和验证
您（显然）需要进行概念验证 (POC)。在 Oracle 云中预置一个小型测试数据库系统和 HeatWave 集群，其中包含您的部分数据。测试您的查询以验证性能。如果性能滞后，请扩展数据库系统配置（增加 ECPU）或添加 HeatWave 节点。您可以在迁移后通过重启来更改配置。对于 OLAP 查询，请务必修改每个表以使用辅助存储引擎 RAPID，然后启动从数据库系统到 HeatWave 集群的初始加载。
您还可以使用mysqlslap或sysbench等工具模拟峰值负载。在 POC 或压力测试期间，请检查 CPU 利用率（通过 Oracle Cloud 控制台）、内存使用情况（通过控制台）、缓冲池统计信息（通过 SHOW ENGINE INNODB STATUS）以及连接错误（通过SHOW STATUS）。如果 CPU 使用率超过 80% 或大部分内存已被消耗，请将形状扩展至下一个最大尺寸并重复测试。
规划迁移
数据库和应用程序的迁移可能很复杂，值得专门写一篇博文——但并非所有应用程序都一样，因此很难写一篇文章来涵盖所有类型的迁移。对于大多数迁移，您只需使用MySQL Shell导出本地 MySQL 数据库即可。注意： mysqldump是一个选项，但 MySQL Shell 比单线程的 mysqldump 有很多优势。您还可以使用MySQL 的复制功能实现几乎零停机时间的迁移。将 Shell 转储文件导入到已配置的数据库系统中，该系统具有支持 HeatWave 的 ECPU 配置，添加 HeatWave 集群并将您的分析表加载到其中以加速——然后将您的应用程序指向新的 HeatWave 实例。
最后提示
在概念验证 ( POC) 期间，甚至在最终迁移期间，请先从保守的配置开始，然后根据需要进行扩展 - MySQL 数据库系统允许在最大程度上减少停机时间的情况下更改配置。对于大于 10 TB 的数据集或特殊需求（例如 MySQL.256 配置），由于硬件可用性有限，请联系Oracle 支持或您的销售代表。随着选项的不断演变，请务必查看最新的Oracle HeatWave 服务指南，了解更新的配置详情。
原文地址：https://blogs.oracle.com/mysql/post/migrating-from-onpremise-mysql-to-heatwave-on-oracle-cloud-how-to-select-the-best-shape
原文作者：Tony Darnell
