如何使用svnsync进行双向同步搭建异地容灾SVN版本库

先说一个直接的结论：svnsync 这个工具，说到底，它就不支持真正的双向同步。它的设计初衷很明确——做一个单向、只读的复制工具，用来搭建主从备份（master-sla ve）。从源库向目标库单向推送变更，这是它的本职工作。如果非要在“双向”上做文章，只会引发版本历史冲突、修订版本号错乱、以及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 失败：主备服务器的系统时间误差应尽量小。

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