>它使用sql代理日志阅读器作业从发布数据库的事务日志中获取已提交的事务.这意味着在读取日志记录之前无法清除日志.如果更改了日志读取器代理程序周期,则您的日志可能会意外增长.日志读取器代理也可能导致高容量OLTP系统上的事务日志争用,具体取决于您的IO子系统.
>复制不保证零数据丢失,因为在读取日志记录并将它们通过分发器传递给订户时涉及延迟.要实现零数据丢失,请查看同步数据库镜像或同步SAN复制
>对等复制是扩展查询工作负载的好方法,也可以为数据添加一些冗余
>您必须使用点对点进行一些仔细的架构设计,以避免因不同节点的类似更改而导致的冲突.不要使用分区标识.使用复合代理键(例如node-identifier bigint)
>使用点对点,可能很难为拓扑中的各个节点添加额外的冗余.发布者可以被镜像,订户可以被镜像(在2008年相当容易,在2005年不那么容易),但是经销商不能.必须对其进行群集才能添加冗余.

只是一些想法.您也可以查看我去年http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/ReplicationAndDBM.docx写的关于镜像repl的白皮书

编辑：好的 – 这是午餐时间,我还有更多要补充的内容：

>对等复制：在2005年,如果要根据需要更改拓扑(添加或删除节点),则必须停顿整个拓扑.在2008年你不需要.
>点对点复制直到2008年才有冲突检测,但即便如此,它的冲突解决方案仍然是脑死亡 – 具有最高ID(称为对等创建者ID)的节点获胜 – 可能不是您想要的.
>对等复制：所有节点都可以看到来自其他节点的所有更改.这意味着,在西雅图,伦敦,东京这样的3向拓扑中 – 如果西雅图出现故障,伦敦和东京将继续发展.如果东京随后下降,西雅图上线,它将获得伦敦的所有伦敦更新以及伦敦所知的伦敦所有东京更新.很简约.
>没有形式的故障检测或复制自动故障转移.也许看看镜像.我想你可以使用某种形式的NLB.

在选择任何类型的HA解决方案时(我现在正在为内部Microsoft DBA教授HA类的时机很好),您需要在评估技术之前先开始需求分析.在不了解您的所有要求的情况下提出建议有点困难.

我在博客中提出了在提出医管策略时要问自己的问题：见http://www.sqlskills.com/BLOGS/PAUL/post/HA-Where-do-you-start-when-choosing-a-high-availability-solution.aspx

再次编辑：

>它的一个使用示例：数据层中的各种服务器,具有中间层负载平衡.点对点允许所有节点保持(最终)同步.
>令人讨厌的问题：如果用户被路由到节点1并执行事务,那么在将数据复制到其他节点之前多久,因为repl延迟可能会有所不同？如果用户再次连接到该服务,将她路由到哪个节点？与之前相同的节点或者有足够的时间来安全地路由到任何节点并保证她所做的上一个事务已被复制到所有节点？

好的 – 没有更多的编辑！ 原文链接：/mssql/80246.html