将本地 MySQL 迁移到 Azure Database for MySQL：性能基线
建立性能基线对于将 MySQL 数据库从本地环境迁移到 Azure Database for MySQL 极其重要。 本文旨在深入探讨性能基线的重要性，提供了有关测量和分析当前数据库性能的详细指南。 只有了解现有的性能指标，才能设定切合实际的期望，确定迁移过程中要改进的领域。 本指南旨在提供创建准确性能基线所需的知识，确保迁移的数据库达到或超过其在 Azure 环境中的当前性能级别。 无论是为了优化查询性能、增强可伸缩性还是确保一致的用户体验，本文都会提供实现性能目标所需的见解。
先决条件
将本地 MySQL 迁移到 Azure Database for MySQL：测试计划
概述
了解现有 MySQL 工作负荷是确保迁移成功的最佳投资之一。 优秀的系统性能取决于充足的硬件和优秀的应用程序设计。 必须对 CPU、内存、磁盘和网络等项进行适当的大小调整和配置，以满足预期负载。 硬件和配置是影响系统性能的因素之一。 开发人员必须了解数据库查询负载和要执行的计算量最大的查询。 专注于开销最高的查询可能会对整体性能指标产生显著影响。
创建查询性能基线对于迁移项目至关重要。 性能基线可用于验证迁移的数据工作负荷的 Azure 登陆区域配置。 大多数系统全天候不间断运行，并具有不同的峰值负载时间。 为基线捕获峰值工作负荷很重要。 系统将多次捕获指标。 我们稍后将在本文档中探讨源服务器参数及其对于总体性能基线图的重要程度。 在迁移项目的过程中，不应忽略服务器参数。
工具
下面是用于收集服务器指标和数据库工作负荷信息的工具。 使用捕获的指标可确定适当的 Azure Database for MySQL 层级和相关缩放选项。
MySQL Enterprise Monitor：此收费的企业版工具可提供开销最高的查询、服务器指标、文件 I/O 和拓扑信息的排序列表
Percona Monitoring and Management (PMM)：卓越的开源数据库监视解决方案。 无论部署在何位置，其都有助于降低复杂性、优化性能和提高关键业务数据库环境的安全性。
服务器参数
MySQL 服务器的默认配置可能无法充分支持工作负载。 MySQL 中有很多服务器参数，但迁移团队在大多数情况下应当重点关注一小部分参数。 应在“源环境”和“目标环境”中评估以下参数。 配置不当会影响迁移速度。 我们会在执行迁移步骤时再次重新访问这些参数。
innodb_buffer_pool_size：此值较高时，可确保在使用磁盘 I/O 之前先使用内存中资源。 典型值的范围为可用内存的 80 - 90%。 例如，具有 8 GB 内存的系统应为池分配 5-6 GB 大小的空间。
innodb_log_file_size：恢复日志用于确保写入操作快速、持久。 此事务备份在系统崩溃时会派上用场。 从 innodb_log_file_size = 512M（提供 1 GB 恢复日志）开始应可提供大量写入空间。 若是使用 MySQL 5.6 或更高版本的写入密集型应用程序，则应从 innodb_log_file_size = 4G 开始。
max_connections：此参数可能有助于缓解
Too many connections错误。 默认为 151 个连接。 首选在应用程序级别使用连接池，但服务器连接配置可能也需要增加。innodb_file_per_table：此设置告知 InnoDB 是应将数据和索引存储在共享表空间中，还是存储在每个表单独的 .ibd 文件中。 每个表都拥有一个文件，能让服务器在表被删除、截断或重新生成时回收空间。 若数据库中包含许多表，则不应使用“每个文件一个表”的配置。 对于 MySQL 5.6，默认值为“开启”。 如果是早期的数据库版本，应在加载数据之前将配置设置为“开启”。 此设置仅影响新创建的表。
innodb_flush_log_at_trx_commit：默认设置为 1 表示 InnoDB 完全符合 ACID 的要求。 由于需要额外的同步来刷新对恢复日志所做的每个更改，因此，较低的风险事务配置可能会在具有慢速磁盘的系统上产生很大的开销。 将参数设置为 2 没有那么可靠，因为系统仅仅会以每秒一次的频率将已提交的事务刷新到恢复日志。 在某些主要情况下，这种风险是可以接受的，对于副本来说，这具有良好的价值。 若该值为 0，系统性能将有所提升，但数据库服务器在发生故障期间丢失部分数据的可能性也会增加。 最重要的是仅对副本使用 0 值。
innodb_flush_method：此设置控制将数据和日志刷新到磁盘的方式。 如果存在具有受电池保护的写回缓存的硬件 RAID 控制器，请使用
O_DIRECT。 其他情况下请使用fdatasync（默认值）。innodb_log_buffer_size：此设置是尚未提交的事务的缓冲区大小。 默认值 (1 MB) 是可接受的。 包含大型 blob/文本字段的事务可快速填充缓冲区，并触发额外的 I/O 负载。 查看
Innodb_log_waits状态变量，如果其不为 0，应增加innodb_log_buffer_size。query_cache_size：众所周知，查询缓存是中度并发时可能会出现的瓶颈。 应将初始值设置为 0 以禁用缓存。例如 query_cache_size = 0。 这是 MySQL 5.6 和更高版本上的默认设置。
log_bin：此设置用于启用二进制日志记录。 如果将服务器作为复制主机，则必须启用二进制日志记录。
server_id：在复制拓扑中，此设置对于标识服务器是唯一的。
expire_logs_days：此设置控制自动清除二进制日志的天数。
skip_name_resolve：禁止执行客户端主机名解析。 如果 DNS 速度较慢，则连接速度也会很慢。 禁用名称解析时，GRANT 语句必须仅使用 IP 地址。 如要能使用该 IP，则需恢复之前的任何 GRANT 语句。
运行以下命令，将服务器参数导出到文件以供查看。 使用一些简单分析时，输出可在迁移后酌情将相同的服务器参数重新应用到 Azure Database for MySQL 服务器。 参阅使用 Azure 门户配置 Azure Database for MySQL 中的服务器参数。
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
可以在附录中找到 MySQL 5.5.60 默认安装的服务器参数。
迁移开始之前，请导出源 MySQL 配置设置。 迁移后，将这些值与 Azure 登陆区域实例设置进行比较。 如果目标 Azure 登陆区域实例中的默认设置发生了任何更改，请确保在迁移后恢复这些设置。 此外，迁移用户在迁移之前应该验证是否可以设置服务器参数。
有关无法配置的服务器参数的列表，请参阅不可配置的服务器参数。
流出量和流入量
必须针对每个单独的数据迁移工具和路径修改源和目标 MySQL 服务器参数，以支持可能实现的最快流出和流入。 参数因工具而异。 例如，与单线程工具相比，并行执行迁移的工具在源和目标之间需要的连接数可能更多。
查看可能受数据集影响的任何超时参数。 这些设置包括：
此外，查看会影响最大值的任何参数：
注意
常见迁移错误是 MySQL server has gone away。 此处提到的参数是解决该错误的典型方法。
WWI 方案
WWI 查看了其会议数据库工作负载，并确定其负载较小。 尽管基本层服务器适合他们，但他们不想稍后执行工作以迁移到另一层。 正在部署的服务器最终要托管其他 MySQL 数据工作负载，因此他们选择了 General Performance 层。
在评审 MySQL 数据库时，我发现 MySQL 5.5 服务器使用初次安装服务器时设置的默认服务器参数进行运行。