MySQL主从复制搭建，CMS网站数据容灾方案

MySQL主从复制是CMS网站实现数据容灾的常用方案，通过将主库数据实时同步到从库，当主库故障时可切换从库继续提供服务。
本文面向零基础用户，以两台Linux服务器为例，详细说明搭建步骤、配置要点和验证方法，帮你完成一套可落地的数据库容灾环境。

环境准备与基础检查

开始前需要准备两台服务器，建议配置相近，操作系统为CentOS 7或Ubuntu 20.04以上。
主库和从库都要安装相同版本的MySQL，推荐5.7或8.0系列，避免版本差异导致复制异常。

假设主库IP为192.168.1.10，从库IP为192.168.1.11，均开放3306端口。
在两台服务器上分别执行以下命令确认MySQL运行状态：

systemctl status mysqld
mysql -uroot -p -e "SELECT VERSION();"

如果尚未安装MySQL，可通过包管理器安装，例如CentOS使用yum install mysql-server，Ubuntu使用apt install mysql-server。
安装后运行mysql_secure_installation设置root密码并移除匿名用户。

主库配置与复制账号创建

登录主库，编辑MySQL配置文件。
CentOS路径通常为/etc/my.cnf，Ubuntu为/etc/mysql/mysql.conf.d/mysqld.cnf。
在[mysqld]段落中添加或修改以下参数：

[mysqld]
server-id = 1
log-bin = mysql-bin
binlog_format = ROW
expire_logs_days = 7

server-id必须全局唯一，主库设为1，从库设为2。log-bin启用二进制日志，binlog_format建议使用ROW模式，能更精确地记录数据变更。
修改后重启MySQL：

systemctl restart mysqld

接着创建用于复制的专用账号，并授予复制权限：

CREATE USER 'repl'@'192.168.1.11' IDENTIFIED BY 'YourStrongPassword';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.11';
FLUSH PRIVILEGES;

将密码替换为高强度密码，并确保从库IP正确。
执行SHOW MASTER STATUS;记录输出中的File和Position值，后续从库配置需要用到。

从库配置与数据同步

在从库上编辑配置文件，添加：

[mysqld]
server-id = 2
relay-log = mysql-relay-bin
log-bin = mysql-bin
read_only = ON

read_only可防止从库被意外写入（拥有SUPER权限的用户仍可写，生产环境建议配合super_read_only）。
重启从库MySQL服务。

如果主库已有数据，需要先备份并导入从库。
在主库执行：

mysqldump -uroot -p --all-databases --master-data=2 > /tmp/full_backup.sql

将备份文件传输到从库并导入：

scp /tmp/full_backup.sql root@192.168.1.11:/tmp/
mysql -uroot -p < /tmp/full_backup.sql

导入完成后，在从库执行CHANGE MASTER命令，指向主库的二进制日志位置：

CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='YourStrongPassword',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=154;

其中MASTER_LOG_FILE和MASTER_LOG_POS填写主库SHOW MASTER STATUS中记录的值。
然后启动复制：

START SLAVE;

复制状态验证与常见报错处理

在从库执行SHOW SLAVE STATUS\G，重点关注两个字段：

• Slave_IO_Running 和 Slave_SQL_Running 都应为 Yes
• Seconds_Behind_Master 表示延迟秒数，正常应为0或较小值

如果Slave_IO_Running为Connecting，检查网络连通性、复制账号密码和防火墙规则。
若Slave_SQL_Running为No，通常由主从数据不一致或主键冲突引起，可查看Last_SQL_Error字段定位。

常见避坑点：

• 主从server-id不能相同，否则复制无法启动
• 从库写入数据会导致复制中断，务必设置read_only
• 防火墙需放行主库3306端口，或使用telnet测试连通性
• 备份导入前应停止从库的复制线程，避免数据错乱

容灾效果验证与日常维护

搭建完成后，在主库创建一张测试表并插入数据，观察从库是否同步：

-- 主库执行
CREATE DATABASE cms_test;
USE cms_test;
CREATE TABLE t1 (id INT PRIMARY KEY, msg VARCHAR(20));
INSERT INTO t1 VALUES (1, 'sync_check');

在从库查询：

SELECT * FROM cms_test.t1;

若返回相同记录，说明复制链路正常。
日常维护建议定期检查SHOW SLAVE STATUS，监控Seconds_Behind_Master，并保留至少一周的二进制日志以便故障恢复。

常见疑问：

• 主库宕机后如何切换？手动将从库提升为主库，需停止从库复制线程并执行RESET MASTER，然后修改应用连接地址。
• 复制延迟高怎么办？检查主库写入压力、网络带宽和从库硬件性能，必要时启用并行复制参数。
• 能否多个从库？可以，每个从库使用独立server-id，并重复CHANGE MASTER步骤即可。

按照以上步骤操作，你可以为CMS网站构建一套基础的数据容灾方案。
遇到异常时优先查看错误日志和SHOW SLAVE STATUS输出，多数问题都能快速定位。