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</password></user></port></host>

其中 --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></password></admin-user></flexible-server-fqdn>

14、 进入 MySQL 交互式终端后，执行：

source /path/to/full_backup.sql;

或使用管道方式加速：

mysql -h <flexible-server-fqdn> -P 3306 -u <admin-user> -p <password><p>15、 若涉及多个数据库，重复步骤 8–14，或在 dump 文件中确保 <code>CREATE DATABASE</code> 语句存在且未被注释，以便自动建库。</p><p>16、 配置目标服务器为复制从节点（即启用“数据传入复制”功能）</p><p>17、 在 Azure 门户中打开该灵活服务器实例，在左侧菜单选择 <strong>“复制”</strong> → <strong>“数据传入复制”</strong>。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2334" title="MySQL"><img
														src="https://img.php.cn/upload/skill/000/000/081/178900927846657.jpg" alt="MySQL" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="overflowclass">MySQL</a>
													<p class="overflowclass">编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div><p>18、 点击 <strong>“配置数据传入复制”</strong>，切换角色为 <strong>“从属服务器”</strong>，并填写主服务器连接信息。</p><p>19、 将步骤 3 获取的 <code>File</code> 和 <code>Position</code> 值分别填入 <strong>“Binlog 文件名”</strong> 与 <strong>“Binlog 位置”</strong> 字段。</p><p>20、 如主服务器启用了 SSL/TLS 加密连接，请勾选 <strong>“启用 SSL”</strong>，并将主服务器的 CA 证书（PEM 格式）完整内容粘贴至 <strong>“主服务器 CA 证书”</strong> 文本框。</p><p>21、 核对所有字段无误后，点击 <strong>“保存”</strong> 启动复制链路。</p><p><img src="https://img.php.cn/upload/article/001/246/273/178286609757903.jpg?x-oss-process=image/resize,p_40" alt="配置数据同步至Azure MySQL"></p><p><img src="https://img.php.cn/upload/article/001/246/273/178286609798183.jpg?x-oss-process=image/resize,p_40" alt="配置数据同步至Azure MySQL"></p><p>22、 复制异常诊断与恢复</p><p>23、 当复制中断时，Azure 门户中复制状态将显示为 <strong>“复制错误”</strong>，并提供错误码与简要描述。典型原因之一是主从 <code>max_allowed_packet</code> 参数不匹配：若从服务器值小于主服务器，大事务 DML 将因包超限被拒绝，导致复制中止。解决方法是在从服务器（即 Azure 灵活服务器）中通过服务器参数页将 <code>max_allowed_packet</code> 调整为 ≥ 主服务器值（例如统一设为 <code>536870912</code> 即 512MB），保存后无需重启即可生效（该参数为动态）。</p><p><img src="https://img.php.cn/upload/article/001/246/273/178286609721644.jpg?x-oss-process=image/resize,p_40" alt="配置数据同步至Azure MySQL"></p><p>24、 若主服务器连接参数（如主机地址、端口、用户名）填写错误，从服务器将无法建立初始连接，状态持续为“正在连接”或快速失败。</p><p>25、 主从数据不一致现象（如从库报“Duplicate entry”）常见于以下情形：  </p><ul>
<li>主库执行了 <code>SET sql_log_bin = 0;</code> 后的 DML 操作，未写入 binlog；  </li>
<li>在开启复制前，误向从库执行了写入；  </li>
<li>启动复制时指定的 binlog 文件名或位置已过期或指向错误事务。</li>
</ul><p>26、 主库中显式关闭二进制日志记录（<code>SET sql_log_bin = 0</code>）的操作不会被复制，属于设计行为，但需在运维规范中明文禁止。</p><p>27、 在启用复制前，严禁对目标从服务器执行任何业务写入，否则将破坏数据一致性。</p><p>28、 若 binlog 文件名或 position 输入有误，复制将无法定位正确起点，导致跳过或重复应用事务，务必复核步骤 3 的原始输出。</p><p>29、 出现复制错误后，请按如下流程处理：  </p><p>30、 在 Azure 门户中，进入 <strong>“复制”</strong> 页面，点击 <strong>“禁用复制”</strong>，使服务器转为可读写模式，便于人工干预。  </p><p>31、 根据错误详情采取针对性措施：调整 <code>max_allowed_packet</code>、清理冲突数据、修复主库 binlog 可用性，或重置复制起点（需谨慎评估 GTID/binary log 有效性）。  </p><p>32、 问题修复后，在同一页面点击 <strong>“启用复制”</strong>，重新输入正确的主服务器参数与 binlog 坐标。  </p><p>33、 binlog 坐标应严格沿用首次成功配置时的 <code>File</code> 与 <code>Position</code>，除非执行了 <code>CHANGE MASTER TO ...</code> 手动重置，否则不可随意变更，以防数据丢失或重复。  </p><p>34、 出于安全策略，Azure 门户不回显已配置的主服务器密码与 CA 证书内容。若未主动修改，系统将保留原有凭证继续使用。  </p><p>35、 其他连接参数（如主机、端口、用户名）将在配置页面中显示历史值，确认无误后可直接复用。</p></password></admin-user></flexible-server-fqdn>