mysql database on azure 提供主从复制能力及标准数据同步机制，支持将本地或其他环境中的 mysql 数据库自动同步至云端从节点，实现高效的数据冗余、灾备与读写分离，确保数据一致性与业务连续性，助力用户在云环境中构建高可用、弹性可扩展的数据库架构。
1、 请确认主 MySQL 服务器的系统变量 lower_case_table_names 值为 1。由于 Azure 上托管的 MySQL 服务（包括灵活服务器）默认将该参数设为 1，而主从复制要求两端该参数严格一致，否则可能引发表名解析异常或复制中断。如当前值非 1，需修改配置并重启 MySQL 服务（仅限支持动态修改的版本可尝试 SET PERSIST lower_case_table_names = 1;，但多数场景仍需重启）。操作前请评估对现有大小写敏感应用的影响，并在维护窗口内执行。
2、 将主服务器临时设为只读模式，以保障同步起点的一致性：先执行 FLUSH TABLES WITH READ LOCK; 加全局读锁，再运行 SET GLOBAL read_only = ON;。此组合可有效阻止写入操作，为获取准确的 binlog 位点提供安全窗口。
3、 在主服务器上执行 SHOW MASTER STATUS;，获取当前活跃的二进制日志文件名（File）及起始偏移位置（Position），该信息将作为从服务器启动复制的关键坐标。
4、 使用 mysqldump 工具导出用户数据库（不包含 mysql、information_schema、performance_schema、sys 等系统库）：
mysqldump -h<host> -P<port> -u<user> -p<password> \ --single-transaction \ --order-by-primary \ --routines \ --databases db1 db2 ... > full_backup.sql
其中 --single-transaction 保障 InnoDB 表一致性快照，--order-by-primary 优化导入性能，--routines 包含存储过程与函数。请勿导出系统库，避免权限冲突或元数据污染。
5、 导出完成后，立即解除主服务器锁定并恢复写入能力：执行 UNLOCK TABLES; 后，再运行 SET GLOBAL read_only = OFF;，使服务回归正常读写状态。
6、 在主服务器创建专用复制账号，提升安全性与可审计性：
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'StrongPass123!'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES;
建议使用强密码、限制 IP 范围（如 'repl_user'@'10.0.0.%'），并禁用不必要的全局权限。
7、 登录 Azure 门户，进入 Azure Database for MySQL 灵活服务器（推荐替代已停用的单一服务器），新建实例，选择合适计算与存储配置，启用公网/私网访问及必要防火墙规则。
8、 在新建的灵活服务器中，通过 mysql 客户端或 Azure 门户 SQL 查询工具，为每个待迁移的业务数据库执行 CREATE DATABASE db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，确保字符集与排序规则与源库一致。
9、 重建用户账号体系：因主从复制不传输账号信息，需在目标服务器上重新创建所有应用所需用户，并精确授予对应数据库的 SELECT, INSERT, UPDATE, DELETE, ... 权限，避免权限过大风险。
10、 将导出的 SQL 文件导入 Azure MySQL 灵活服务器。对于大体积备份，推荐将文件上传至同区域 Azure VM，再由该 VM 执行导入，以规避公网带宽瓶颈与连接超时。
11、 将 MySQL 客户端工具（如 mysql 命令行客户端）部署至该 Azure VM。
12、 将 full_backup.sql 文件上传至 VM，建议采用压缩传输（如 .sql.gz），再解压使用。
13、 在 VM 中执行连接命令：
mysql -h <flexible-server-fqdn> -P 3306 -u <admin-user> -p <password>
14、 进入 MySQL 交互式终端后，执行：
source /path/to/full_backup.sql;
或使用管道方式加速：
mysql -h <flexible-server-fqdn> -P 3306 -u <admin-user> -p <password> < full_backup.sql
15、 若涉及多个数据库，重复步骤 8–14，或在 dump 文件中确保 CREATE DATABASE 语句存在且未被注释，以便自动建库。
16、 配置目标服务器为复制从节点（即启用“数据传入复制”功能）
17、 在 Azure 门户中打开该灵活服务器实例，在左侧菜单选择 “复制” → “数据传入复制”。
18、 点击 “配置数据传入复制”，切换角色为 “从属服务器”，并填写主服务器连接信息。
19、 将步骤 3 获取的 File 和 Position 值分别填入 “Binlog 文件名” 与 “Binlog 位置” 字段。
20、 如主服务器启用了 SSL/TLS 加密连接，请勾选 “启用 SSL”，并将主服务器的 CA 证书（PEM 格式）完整内容粘贴至 “主服务器 CA 证书” 文本框。
21、 核对所有字段无误后，点击 “保存” 启动复制链路。
22、 复制异常诊断与恢复
23、 当复制中断时，Azure 门户中复制状态将显示为 “复制错误”，并提供错误码与简要描述。典型原因之一是主从 max_allowed_packet 参数不匹配：若从服务器值小于主服务器，大事务 DML 将因包超限被拒绝，导致复制中止。解决方法是在从服务器（即 Azure 灵活服务器）中通过服务器参数页将 max_allowed_packet 调整为 ≥ 主服务器值（例如统一设为 536870912 即 512MB），保存后无需重启即可生效（该参数为动态）。
24、 若主服务器连接参数（如主机地址、端口、用户名）填写错误，从服务器将无法建立初始连接，状态持续为“正在连接”或快速失败。
25、 主从数据不一致现象（如从库报“Duplicate entry”）常见于以下情形：
- 主库执行了
SET sql_log_bin = 0;后的 DML 操作，未写入 binlog； - 在开启复制前，误向从库执行了写入；
- 启动复制时指定的 binlog 文件名或位置已过期或指向错误事务。
26、 主库中显式关闭二进制日志记录（SET sql_log_bin = 0）的操作不会被复制，属于设计行为，但需在运维规范中明文禁止。
27、 在启用复制前，严禁对目标从服务器执行任何业务写入，否则将破坏数据一致性。
28、 若 binlog 文件名或 position 输入有误，复制将无法定位正确起点，导致跳过或重复应用事务，务必复核步骤 3 的原始输出。
29、 出现复制错误后，请按如下流程处理：
30、 在 Azure 门户中，进入 “复制” 页面，点击 “禁用复制”，使服务器转为可读写模式，便于人工干预。
31、 根据错误详情采取针对性措施：调整 max_allowed_packet、清理冲突数据、修复主库 binlog 可用性，或重置复制起点（需谨慎评估 GTID/binary log 有效性）。
32、 问题修复后，在同一页面点击 “启用复制”，重新输入正确的主服务器参数与 binlog 坐标。
33、 binlog 坐标应严格沿用首次成功配置时的 File 与 Position，除非执行了 CHANGE MASTER TO ... 手动重置，否则不可随意变更，以防数据丢失或重复。
34、 出于安全策略，Azure 门户不回显已配置的主服务器密码与 CA 证书内容。若未主动修改，系统将保留原有凭证继续使用。
35、 其他连接参数（如主机、端口、用户名）将在配置页面中显示历史值，确认无误后可直接复用。
