svnsync双向同步搭建异地容灾SVN版本库方案

首先需要明确结论：svnsync 工具本质上并不支持真正的双向同步。它的设计初衷十分清晰——作为一个单向、只读的复制工具，用于搭建主从备份（master-slave）。从源仓库向目标仓库单向推送变更，这才是它的本职工作。如果强行追求“双向”，只会引发版本历史冲突、修订版本号错乱以及 svn:sync-* 属性污染等一系列问题。Subversion 官方对此早已给出定论：不推荐，也不保障双向场景。

不过，如果你的目标是实现异地容灾——即当主站点宕机时，能够快速切换到备用站点，并尽可能保持数据一致性——完全可以换一种思路：采用“主备切换 + 单向同步 + 手动接管”的方案。这套方案既务实又落地，运行逻辑非常清晰明了。

一、明确主备角色与网络可达性

首先选定一台稳定的服务器作为主库（Production），另一台异地机房的机器作为备库（DR Site）。两者之间需要满足以下几个基本条件：

• 主库能通过网络访问备库（HTTP/HTTPS 或 svn:// 协议）；
• 备库能反向访问主库（主要用于故障后的手动回切或验证，并非实时同步的必需品）；
• 主库和备库的 SVN 版本最好保持一致（至少 1.4 以上版本），避免属性兼容问题。

二、在备库初始化只读镜像

备库必须是全新创建的空库，并且需要配置一个专门的钩子，允许 svnsync 写入元数据。具体操作步骤如下：

• 创建空库：svnadmin create /path/to/backup_repo；
• 进入 hooks/ 目录，将 pre-revprop-change.tmpl 复制为 pre-revprop-change（Linux）或 pre-revprop-change.bat（Windows）；
• 编辑该文件，确保最后一行是 exit 0（Linux）或 exit /b 0（Windows），切记不加任何条件判断；
• 赋予执行权限：chmod a+x pre-revprop-change（Linux）或确认 bat 文件能被 svn 进程调用（Windows）。

三、建立单向同步链路

所有操作均在备库所在机器上执行。首先初始化同步关系：

输入主库的读账号和备库的写账号。建议使用独立且低权限的账号，例如 sync_reader 和 sync_writer。然后进行首次全量同步：

后续的增量同步（可以定时运行）使用如下命令：

四、实现容灾切换能力

备库默认是只读的（svnsync 不开放提交入口）。切换时需要人工干预，具体流程如下：

• 先停止主库服务，确认没有新的提交产生；
• 在备库的 hooks 中，临时移除或重命名 pre-revprop-change，防止意外属性修改造成干扰；
• 修改备库的 conf/authz 和 conf/passwd，启用正常开发用户的写权限；
• 更新客户端工作副本的 URL，指向备库地址（可以使用 svn switch --relocate 或重新 checkout）；
• 可选步骤：通过 svnadmin dump + load 将主库最后的几个 revision 补充到备库，确保数据零丢失。

五、避免常见陷阱

以下错误几乎都源于权限或钩子配置不当：

• “DA V request failed; pre-revprop-change hook failed”：检查备库的 pre-revprop-change 文件是否存在、是否可执行、是否返回 0；
• 同步卡在 rev 0 或报 auth 失败：确认主库提供读权限、备库提供写权限，且账号密码未被 svn cache 缓存干扰（加 --no-auth-cache 参数）；
• 备库无法提交：这是正常现象，svnsync 镜像库默认就是禁写的，切换时才开放，不要提前开启；
• 时间不同步导致 propset 失败：主备服务器的系统时间误差应尽量小。

这项技术并不复杂，但容易被忽略的是：容灾的真正价值不在于“自动双向”，而在于“可控、可验证、可回退”的单向镜像，再加上一个明确的切换流程。真正可靠的异地容灾，靠的是定期演练切换，而不是依赖工具自动兜底。