linux主从架构中配置文件同步需人工或工具主动维护，因mysql复制不处理/etc/my.cnf等配置；核心是确保server-id唯一、log-bin在从节点关闭、relay-log路径有效，避免复制中断。

Linux 主从架构中配置文件同步，核心目标是确保从节点的配置与主节点保持一致、可追溯、可回滚，且不破坏主从复制逻辑本身。这不是数据库数据同步，而是运维层面的配置管理问题。常见做法分两类：手动/脚本化同步 和 自动化配置管理工具驱动，关键在于“谁来触发”“怎么验证”“如何避免误覆盖”。

配置文件同步不是靠 MySQL 自身完成的

MySQL 主从复制只同步 数据变更（通过 binlog → relay log → 执行），它不会、也不该同步 /etc/my.cnf 或其他系统配置文件。这些文件必须由运维人员主动维护或通过外部机制同步。否则容易导致 server-id 冲突、日志路径错乱、甚至复制中断。

用 rsync + SSH 实现轻量级同步（适合小规模环境）

适用于两台服务器、配置变更不频繁、需快速生效的场景。

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

• 主节点修改完 /etc/my.cnf 后，执行一次性推送：

  rsync -avz --delete /etc/my.cnf root@192.168.110.60:/etc/my.cnf

• 加 -e "ssh -p 2222" 指定非默认端口；加 --exclude="log-bin" 可防止意外覆盖从节点禁用的参数。
• 同步后务必在从节点重启服务：systemctl restart mariadb，并检查 SHOW VARIABLES LIKE 'server_id'; 是否仍为 2。
• ⚠️ 注意：不能直接同步整个 /etc/my.cnf.d/ 目录——从节点可能有专属配置（如 relay-log），需保留差异项。

用 Ansible 统一编排（推荐用于多节点或生产环境）

避免人工失误，支持版本控制、差异比对、滚动更新。

• 定义主、从角色变量：

  # group_vars/mysql_master.yml
  mysql_server_id: 1
  mysql_log_bin: true
  mysql_binlog_format: ROW

  # group_vars/mysql_slave.yml
  mysql_server_id: 2
  mysql_log_bin: false  # 从节点通常关闭 binlog
  mysql_relay_log: "mysql-relay-bin"

• Playbook 中用 template 模块生成配置，确保 server-id 动态注入、log-bin 开关按角色生效。
• 执行后自动校验：

  - name: Verify server-id is correct
    shell: mysql -e "SHOW VARIABLES LIKE 'server_id';" | grep "value.*{{ mysql_server_id }}"
    failed_when: false

同步前必须检查的三项关键点

• server-id 在全集群唯一且非零（主=1，从=2，绝不能重复或为 0）；
• 从节点的 log-bin 必须为 OFF（除非启用双主），否则可能干扰复制链路；
• relay-log 路径在从节点存在且 MariaDB 进程有写权限（如 /var/lib/mysql/ 下需属主 mysql:mysql）。

不建议的做法

• 直接 scp 整个 /etc/my.cnf 覆盖从节点：易抹掉从节点特有配置（如 read_only=ON）；
• 用 inotify + rsync 监控 /etc/my.cnf 自动同步：缺乏人工审核，一次错误配置会瞬间扩散；
• 依赖数据库导出导入同步配置：配置不是数据，SQL 无法表达文件结构和权限。

配置文件同步本质是运维一致性保障，不是技术难题，而是流程设计问题。重点不在“怎么传”，而在“传什么、谁批准、传完怎么验”。