Oracle RAC集群中的ACFS（Oracle Automatic Storage Management Cluster File System）是一种构建在ASM动态卷管理（ADVM）之上的集群文件系统，能够为多个节点提供并发读写能力。当企业需要在同城或异地数据中心之间保护存放在ACFS中的配置文件、归档日志或应用共享目录时，ACFS文件系统复制（ACFS Replication）就成为关键的技术手段。它不同于传统的存储阵列远程镜像，而是在文件系统层面实现卷级别的异步或同步复制，保障灾难发生时远端数据可用且崩溃一致。
ACFS复制的底层原理与核心组件
ACFS复制并不是简单地将文件拷贝到另一个位置，而是依托于ADVM卷的写前日志与变更跟踪机制。当ACFS文件系统在primary节点发生数据块修改时，ASM实例会记录对应的卷变更元数据，复制守护进程（acfsutil repl）周期性地读取这些增量并压缩传输到standby端的接收进程。由于捕获的是卷级块变更，无论用户写入的是大文件还是海量小文件，复制效率都较为平稳，且不会因文件目录结构复杂而显著下降。
在部署层面，复制涉及两个核心角色：发送端（primary）与接收端（standby）。发送端运行acfsutil repl start命令发起复制，接收端则需提前通过acfsutil repl receive初始化空卷以接收数据。两端必须处于同一个集群域或至少拥有互通的网络与信任关系。特别要注意，ACFS复制许可证需要在两个集群都激活，否则命令会报license错误而无法启动。从一致性角度看，复制流会按照卷写入顺序传递，因此远端挂载后不会出现文件系统元数据错乱。
与基于RMAN的备份集传输相比，ACFS复制的优势在于接近实时的保护间隔和更细的RPO控制。但它也有局限，例如不支持跨不同操作系统平台的复制，且复制卷在接收端默认处于只读状态，只有在切换（failover）之后才能转为可读写。理解这些边界条件，是设计容灾方案的前提。
配置ACFS复制的具体实施步骤
在开始配置前，应先在两端集群创建同名的磁盘组与ADVM卷，但standby端的卷可以不格式化文件系统，仅作为接收目标。假设primary端已有挂载于/u01/app/acfs的ACFS，我们可以使用如下命令启动发送端复制：
# 在primary节点执行 acfsutil repl start -v vol1 -m /u01/app/acfs -s standby_host1,standby_host2 -w 30 # -v 指定ADVM卷名 # -m 指定已挂载的ACFS路径 # -s 指定standby端主机列表 # -w 指定同步间隔秒数
上述命令中，-w 30表示每30秒推送一次增量，实际值需根据业务写入峰值与网络带宽权衡。若网络带宽有限，可适当调大间隔以减少对生产链路的占用。在standby端，管理员需要预先准备接收卷并启动接收服务，示例如下：
# 在standby节点执行 acfsutil repl receive -v vol1 -m /u01/app/acfs_standby -p primary_host1 # -p 指定primary端主机 # 接收卷初始为空，复制开始后自动同步数据
配置完成后，可通过acfsutil repl info查看复制状态、延迟与剩余数据量。如果状态长时间停留在initializing，通常是因为防火墙阻断了复制端口（默认1521相关ASM通道）或两端磁盘组兼容参数不一致。此时应检查asmcmd lsattr -G DGNAME compatible.advm的输出，确保两端版本匹配。此外，复制过程中不建议对primary卷做离线收缩操作，否则可能导致接收端出现卷尺寸不匹配的致命错误。
故障切换、回切与日常运维要点
当primary数据中心不可用时，需要在standby端执行failover操作，使接收卷变为可写并挂载供业务使用。命令为acfsutil repl failover，执行后原只读卷会被提升为读写状态。这一步必须确认primary端确实已停止写入，否则会造成脑裂。failover后，应用连接串应指向standby端RAC的VIP或SCAN地址，完成业务接管。由于ACFS复制不依赖数据库实例，因此即使数据库未启动，文件系统层也能独立切换。
待primary端恢复后，常规做法是反向建立复制将standby的新数据回灌，或选择放弃primary旧数据重新全量初始化。若采用回切（reinstate），应先在primary端以接收角色拉取standby变更，再恢复原有发送角色。该过程容易因卷UUID冲突失败，因此建议在初次搭建时就记录好卷属性，并在文档中明确标注切换顺序。日常运维中，应配置监控脚本定时抓取acfsutil repl info的lag值，一旦延迟超过阈值就触发告警。
从资源规划角度，ACFS复制会消耗额外的CPU用于压缩与ASM日志解析，在密集型写入场景下建议预留至少15%的空闲CPU。网络方面，跨机房链路应保证稳定且低抖动，若使用公网加密隧道，还需在命令中指定加密选项。通过合理的容量、带宽与监控设计，ACFS文件系统复制能够成为RAC集群轻量级容灾的有效补充，而不是运维负担。
Oracle_RACACFS文件系统复制修改时间：2026-08-14 09:48:31