linux多机集群数据同步无内置一键功能，需按数据类型选机制：rsync+inotify用于小文件秒级同步；rsync daemon支持多节点集中分发；nfs/glusterfs适用于静态资源伪同步；数据库同步须依赖mysql主从或postgresql流复制。
多机集群数据同步在 Linux 环境中没有“一键开启”的内置功能，而是依赖组合式网络技术与工具链协同完成。核心思路是：**按数据类型选机制、按实时性定方案、按一致性要求加保障**。下面从实际可落地的四个方向展开说明。
rsync + inotify 实现轻量级实时文件同步
适用于配置文件、静态资源、日志归档等非结构化小文件场景，延迟通常控制在秒级。
- inotify 监控源目录的增删改事件（如 IN_CREATE、IN_MOVED_TO），触发后调用 rsync 命令
- rsync 使用 -avz --delete 参数保证目标端与源端内容完全一致，且只传差异块
- 需注意单向推送逻辑，避免多节点互推导致循环同步；建议统一设定一个“主源节点”，其余为只读接收端
- 示例命令：rsync -avz --delete /data/web/ user@192.168.1.10:/data/web/
rsync daemon 模式支撑多节点集中分发
当集群规模扩大（如 5 台以上 Web 节点），用 SSH 逐台连接效率低，可部署 rsync 服务端统一响应请求。
- 在主节点运行 rsync --daemon，监听 873 端口，配置 /etc/rsyncd.conf 定义模块（如 [app_config]）、路径、权限和认证方式
- 各客户端使用 rsync -avz rsync://user@master/app_config/ ./local_config/ 拉取更新
- 密码通过 secrets file 管理，权限设为 600 防泄露
- 配合 cron 每 5 分钟拉一次，或由发布系统主动触发，兼顾实时性与可控性
共享存储（NFS/GlusterFS）实现伪同步访问
适合读多写少、多个节点需同时访问同一份数据的场景，如 CMS 内容池、图片库。
- NFS 由一台服务器导出目录（/etc/exports），其他节点 mount 后直接读写，修改即时可见
- GlusterFS 提供分布式冗余能力，支持 replica 2/3 模式，单点故障不影响可用性
- 注意 NFS 的锁机制较弱，高并发写入易冲突；GlusterFS 需额外维护集群状态，运维复杂度略高
- 不适用于数据库文件等强一致性要求场景，仅推荐用于静态资源类数据
数据库级同步保障结构化数据一致
若集群承载的是动态业务（如订单、用户信息），必须依赖数据库自身的复制机制，而非文件层同步。
- MySQL 主从复制：主库 binlog 写入 → 从库 IO 线程拉取 → SQL 线程回放，支持半同步提升可靠性
- PostgreSQL 流复制：WAL 日志实时传输 + replay，延迟可压至毫秒级，配合 Patroni 可自动故障转移
- 关键点：应用层需明确读写分离策略（写主库、读从库），避免因复制延迟导致脏读
- 切勿用 rsync 直接同步 MySQL data 目录——可能破坏事务一致性，引发崩溃
