基于FILESTREAM的双实例文件同步场景下合并复制的可靠性问询

作为常年处理SQL Server复制场景的老玩家，针对你这个用合并复制同步FILESTREAM大文件（最高2GB）、双向上传同步的需求，我来拆解下它的可靠性情况，以及你需要注意的坑：

1. 大文件同步的核心挑战：性能与稳定性 #

合并复制本身支持FILESTREAM，但默认配置可不是为2GB级别的文件设计的。首先要调整的是合并代理的-MaxTextSize参数——默认值远小于2GB，不调整的话，大文件同步直接会因为数据大小超限失败。好在SQL Server里这个参数的上限刚好是2147483647字节（约2GB），刚好能覆盖你的需求，一定要记得改。

然后是网络问题，这是大文件同步的头号杀手。如果同步中途网络断了，合并代理确实会重试，但2GB的文件重试一次要花的时间和资源都不少，运气差的话可能直接导致代理进程挂掉。建议你把代理的重试间隔调长一点，超时时间设得足够大，尽量降低重试带来的额外负担。

2. FILESTREAM专属的复制风险 #

FILESTREAM数据是“半数据库半文件系统”的存在，合并复制同步的时候，既要传数据库里的元数据行，还要传文件系统里的实际文件。这里有两个坑：

• 只要FILESTREAM对应的行有修改（哪怕只是改个文件名），整个2GB的文件都会被重新同步——如果你经常更新文件，网络开销会爆炸，同步失败概率也会飙升；
• 要是其中一个实例的FILESTREAM存储目录出问题（比如权限不对、磁盘满了），同步会直接失败，而且有时候合并代理不会把这种文件系统层面的错误明确报出来，得自己加监控盯着磁盘和权限。

3. 双向同步的冲突处理 #

你允许两边都上传文件，那合并复制的双向同步就必然会碰到冲突。虽然你说没有唯一性限制，但要注意：合并复制的冲突检测是看行的元数据（比如修改时间、主键），不是文件内容。比如你在A和B分别上传了一模一样的文件，但两行的主键或修改时间不同，合并复制会判定为冲突，然后按你设置的策略处理（默认是“最后写入的赢”）。如果想要基于文件内容判断是否冲突，你得自己写自定义冲突解决器，这就有点麻烦了。

4. 到底可靠不可靠？ #

如果你的环境能满足这几个条件，合并复制的可靠性是能打几分的：

• 网络带宽够硬（至少1Gbps，不然2GB文件传半天，中间出问题的概率太高）；
• 两个实例的FILESTREAM配置完全一致（权限、磁盘空间、NTFS格式都得对齐）；
• 已经调好合并代理的参数（-MaxTextSize、重试、超时）；
• 能接受默认的行级冲突处理，不需要基于文件内容的判断。

但如果你的网络环境不稳定，或者对同步实时性要求极高，那合并复制可能不是最优解。这种情况下可以考虑：

• 换成事务复制——但它的双向同步不如合并复制灵活，大文件同步的问题还是存在；
• 分开处理：用Robocopy这类文件同步工具管FILESTREAM的文件，再用简单的复制同步数据库里的元数据；
• 上Always On可用性组——如果两个实例能搭AG，它原生支持FILESTREAM同步，可靠性比复制高很多，但得用SQL Server企业版。

内容的提问来源于stack exchange，提问作者pgerchev