香港服务器部署MySQL 5.7主从复制配置解析

前几天帮朋友模拟面试，他被问到"香港服务器部署MySQL 5.7主从复制该怎么操作"，支支吾吾半天答不全。这其实是运维岗位的高频考点——既考技术实操，又考问题排查能力。今天结合实际案例，把配置流程和常见坑点掰开揉碎讲清楚。

为什么要在香港服务器做MySQL主从复制？

主从复制（Master-Slave Replication）是通过二进制日志（Binlog）实现数据同步的技术，简单说就是主库写数据，从库同步复制。在香港服务器部署这套架构，既能提升数据库可用性（主库挂了从库顶），又能分担读写压力（读请求分流到从库），是高并发业务的基础保障。

配置前的3个关键准备

在香港服务器上操作，第一步不是改配置，而是确认基础环境：
1. 主从服务器都装好了MySQL 5.7（版本一致避免兼容问题）；
2. 网络必须通——用telnet命令测试主库3306端口，从库能连上；
3. 防火墙放行3306端口（CentOS用`firewall-cmd --add-port=3306/tcp --permanent`）。

主服务器配置：开启日志并授权

主库是数据源头，核心是开启二进制日志并创建复制账号。

编辑主库配置文件（通常在/etc/my.cnf），添加这三行：

server-id = 1       # 全局唯一标识，主库设1，从库必须不同
log-bin = mysql-bin # 开启二进制日志，文件前缀是mysql-bin
binlog-do-db = test # 只复制test数据库（按需修改）

改完重启MySQL服务（`systemctl restart mysqld`）。

接着登录主库MySQL，创建复制用户：

CREATE USER 'repl'@'%' IDENTIFIED BY 'Rep12345';  # 创建用户，%表示所有IP可连
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';     # 授予复制权限
FLUSH PRIVILEGES;                                 # 刷新权限

最后执行`SHOW MASTER STATUS;`，记下File（如mysql-bin.000001）和Position（如154）这两个值，从库配置要用。

从服务器配置：关联主库并启动复制

从库的核心是告诉它"主库在哪、用哪个用户、从哪份日志开始同步"。

先改从库my.cnf，只需要设置server-id（比如2），其他保持默认。改完同样重启服务。

登录从库MySQL，执行关键命令：

CHANGE MASTER TO
MASTER_HOST='192.168.1.100',   # 主库IP
MASTER_USER='repl',             # 刚才创建的用户
MASTER_PASSWORD='Rep12345',     # 用户密码
MASTER_LOG_FILE='mysql-bin.000001',  # 主库的File值
MASTER_LOG_POS=154;             # 主库的Position值

然后启动复制进程：`START SLAVE;`。

检查是否成功，执行`SHOW SLAVE STATUS\G`，重点看两个状态：
- Slave_IO_Running: Yes（IO线程正常，从主库拉日志）
- Slave_SQL_Running: Yes（SQL线程正常，执行日志同步数据）

实战踩坑：时间不同步导致复制失败

去年帮客户部署时，从库启动后两个状态一直是Connecting。排查半天发现主从服务器时间差了3分钟——MySQL复制依赖时间戳校验，时间不同步会导致日志解析错误。用`ntpdate ntp.aliyun.com`同步时间后，问题立刻解决。

面试加分项：说清"为什么这么做"

面试官不会只问步骤，更在意你是否理解原理。比如：
- 为什么要设置server-id？因为MySQL通过这个值区分不同节点，重复会导致复制冲突。
- 为什么要开启binlog？主从复制的本质是从库重放主库的binlog，不开日志就没数据可同步。
- 从库状态异常怎么排查？先看IO线程错误（网络/账号问题），再看SQL线程错误（数据不一致/表结构差异）。

在香港服务器上部署MySQL 5.7主从复制，关键是理清"准备-主库配置-从库配置-验证"的逻辑链，遇到问题时能快速定位网络、权限、时间同步这些常见因素。面试时别只背步骤，结合实际案例讲排查思路，能让你的回答更有说服力。