MariaDB主从复制是一种基于二进制日志的异步数据同步机制。主库把每一次已提交的事务写入二进制日志，从库通过网络把这些日志拉取过来，再在本地重放一遍，从而保持一份与主库高度一致的数据副本。对于读多写少的业务，从库可以承载大量查询请求；对于容灾场景，从库也能在主库发生故障时快速接管。理解这套机制并不需要有特别深厚的数据库内核知识，但要把复制链路跑稳，前提是主从双方的网络可达、二进制日志格式合适、复制账号权限正确。
一、搭建环境与前置检查
在Fedora上部署MariaDB主从复制，首先需要确保两台服务器上都已经安装并且启动了MariaDB服务。可以使用dnf包管理器直接安装，命令如下：
sudo dnf install mariadb-server mariadb -y sudo systemctl enable --now mariadb sudo systemctl status mariadb
安装完成后建议运行安全初始化脚本，设置root密码并清理匿名用户和测试库。这个步骤虽然不是复制的强制要求，但对于公网可访问的数据库来说非常必要。执行sudo mariadb-secure-installation并按照提示完成即可。Fedora默认使用SELinux并开启了防火墙，如果两台实例不是通过内网专线直连，而是经过防火墙，需要放行3306端口。可以使用sudo firewall-cmd --permanent --add-port=3306/tcp再重载防火墙。另外要注意，如果SELinux处于强制模式，修改MariaDB的数据目录或日志目录后需要调整上下文，这里保持默认路径一般不会触发策略问题。
主从复制的关键是每个实例必须有一个全局唯一的数字标识，也就是server-id。主库和从库不能相同，否则复制协议会在握手阶段就出现冲突。通常主库设为1，从库设为2，也可以根据实际情况分配不同数字。另一个前提是网络层能够通过MySQL协议访问到复制账号，主库如果只监听127.0.0.1，从库就无法建立连接，因此要把主库的监听地址改成0.0.0.0或指定内网IP。
二、主库配置与数据准备
主库的配置文件在Fedora中通常位于/etc/my.cnf.d/mariadb-server.cnf。打开这个文件后，在[mysqld]段中添加如下参数：
[mysqld] server-id = 1 log_bin = mysql-bin binlog_format = row expire_logs_days = 7 max_binlog_size = 1G bind-address = 0.0.0.0
其中log_bin指定二进制日志文件名前缀，开启后主库才会记录数据变更。binlog_format设置为行格式，可以有效避免使用statement格式时某些不确定函数或触发器导致主从结果不一致的问题。行格式日志量通常更大，但为了数据可靠性，这个代价是值得的。expire_logs_days控制二进制日志保留天数，避免磁盘被写满。修改配置后需要执行sudo systemctl restart mariadb让配置生效。
主库还需要创建一个专用的复制账号。直接给root权限给从库使用是不安全的，最佳实践是创建一个最小权限账号，只授予复制相关的权限。进入MariaDB命令行后执行以下SQL：
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'Str0ngPass!'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%'; FLUSH PRIVILEGES;
如果从库IP固定，建议把'%'换成具体的从库地址，例如'192.168.1.20'，这样更安全。创建完成后，可以用该账号在从库上手动测试一下连接，确认密码和权限都没有问题后再进行下一步。主库已有业务数据时，需要在导出前锁定写入，记录二进制日志坐标，然后做全量备份。对InnoDB表较多的库，推荐使用单事务快照导出，避免长时间锁表影响写入。
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;" mysql -u root -p -e "SHOW MASTER STATUS;" mysqldump -u root -p --all-databases --master-data=2 --single-transaction > /tmp/master_dump.sql mysql -u root -p -e "UNLOCK TABLES;"
执行SHOW MASTER STATUS后记录下File和Position这两个值，后续从库配置CHANGE MASTER TO时需要用到。备份文件/tmp/master_dump.sql也需要复制到从库服务器，可以使用scp或rsync。
三、从库配置与复制启动
从库的配置文件同样需要调整。打开/etc/my.cnf.d/mariadb-server.cnf，在[mysqld]段中添加以下内容：
[mysqld] server-id = 2 log_bin = mysql-bin relay_log = relay-bin read_only = 1 binlog_format = row
从库的server-id必须与主库不同。虽然从库本身不一定要开启二进制日志，但如果希望这个从库以后再作为其他从库的主库，就需要保留log_bin。relay_log是中继日志，从库I/O线程从主库接收到的日志会先写入这里，再由SQL线程执行。read_only设为1可以限制普通账号直接写入从库，只允许复制线程和具备SUPER权限的账号修改数据，这可以显著降低人为误操作导致主从数据分叉的风险。
修改完成后重启MariaDB，然后导入从主库复制过来的全量备份。导入前建议先在从库上停止任何已存在的复制进程，并清空旧的中继日志，避免状态混乱。执行以下命令完成数据导入和复制配置：
mysql -u root -p < /tmp/master_dump.sql
导入完成后进入MariaDB命令行，执行CHANGE MASTER TO指定主库地址、复制账号、以及之前记录的二进制日志文件名和偏移量。例如：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl_user', MASTER_PASSWORD='Str0ngPass!', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=123; START SLAVE;
这里MASTER_LOG_FILE和MASTER_LOG_POS必须与主库上SHOW MASTER STATUS的输出完全一致。如果主库在备份期间没有写入，这个位置通常就是准确起点；如果备份后主库又有写入，从库会通过中继日志继续追增量，不会丢失数据。
四、复制状态验证与常见故障处理
启动复制后，需要检查从库状态确认链路已经正常。执行SHOW SLAVE STATUS\G，重点看三个字段：Slave_IO_Running、Slave_SQL_Running和Seconds_Behind_Master。前两者都显示为Yes时，说明I/O线程和SQL线程都在正常工作；Seconds_Behind_Master表示从库落后主库的秒数，正常情况下应该为0或非常小的值。如果Slave_IO_Running一直是Connecting，多数原因是网络不通、复制账号密码错误、主库监听地址未调整或防火墙拦截。可以先在从库上用mysql -h 主库IP -u repl_user -p测试连通性。
SHOW SLAVE STATUS\G
当出现Got fatal error 1236 from master when reading data from binary log这类错误时，通常说明从库请求的二进制日志位置已经失效，可能主库已经清理了早期的日志。此时需要重新获取主库当前SHOW MASTER STATUS的坐标，然后在从库上执行STOP SLAVE;、RESET SLAVE;，再用新的坐标重新执行CHANGE MASTER TO并启动。另一个容易遇到的问题是两台机器复制过来的数据目录中auto.cnf文件携带了相同的UUID，这会导致复制启动失败。解决办法是在从库上停止MariaDB，删除/var/lib/mysql/auto.cnf文件，然后重启，让系统重新生成一份UUID。
对生产环境来说，建议在主从复制跑通后，定期观察Seconds_Behind_Master的变化趋势，并为从库配置监控告警。同时，如果主库使用了GTID模式，复制配置会更加灵活，可以在故障切换时减少手工定位日志位置的复杂度。不过传统基于二进制日志位置的方式已经足够稳定，在Fedora上按照上述流程搭建，绝大多数场景下都能获得一套可用的MariaDB读写分离基础架构。
Fedora MariaDB主从复制MariaDB复制配置数据库主从同步修改时间：2026-09-25 09:09:45