- 使用复制会产生哪些不利影响
- 哪些情况下复制是有益的？
答案1
添加一些有关事务复制的内容：
- 它使用 SQL 代理日志读取器作业从发布数据库的事务日志中收集已提交的事务。这意味着在读取日志记录之前无法清除日志。如果更改了日志读取器代理周期，则您的日志可能会意外增长。日志读取器代理还可能导致高容量 OLTP 系统上的事务日志争用，当然这取决于您的 IO 子系统。
- 复制不能保证零数据丢失，因为读取日志记录并将其通过分发器传递给订阅者存在延迟。要实现零数据丢失，请查看同步数据库镜像或同步 SAN 复制
- 对等复制是扩展查询工作负载的好方法，也可以为数据添加一些冗余
- 您必须对点对点进行一些仔细的架构设计，以避免不同节点的类似更改导致冲突。不要为此使用分区标识。使用复合代理键（例如节点标识符 + bigint）
- 对于点对点，很难为拓扑中的各个节点添加额外的冗余。发布者可以镜像，订阅者也可以镜像（在 2008 年还算容易，在 2005 年就不那么容易了），但分发者不能。必须将其集群化才能增加冗余。
这只是一些想法。您也可以查看我去年在以下网址撰写的有关镜像 + repl 的白皮书：http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/ReplicationAndDBM.docx
编辑：好的 - 现在是午餐时间，我还有一些内容要补充：
- 对等复制：在 2005 年，如果您想要更改拓扑结构（添加或删除节点），则必须使整个拓扑静止。而在 2008 年，您无需这样做。
- 对等复制直到 2008 年才具有冲突检测功能，但即便如此，它的冲突解决也相当愚蠢 - 具有最高 ID（称为对等发起者 ID）的节点获胜 - 也许不是您想要的。
- 对等复制：所有节点都可以看到来自其他节点的所有更改。这意味着，在三向拓扑中，例如西雅图、伦敦、东京 - 如果西雅图出现故障，伦敦和东京将继续运行。如果东京出现故障而西雅图恢复在线，它将从伦敦获得所有伦敦更新，并从伦敦获得伦敦知道的所有东京更新。非常巧妙。
- 没有形式的故障检测或自动故障转移与复制。也许可以考虑镜像。我猜你可以使用某种形式的 NLB。
在选择任何类型的 HA 解决方案时（时机很好，因为我今天正在为内部 Microsoft DBA 教授 HA 课程），您需要先进行需求分析，然后再评估技术。如果不知道您的所有需求，很难给出建议。
我在博客中提到了制定 HA 策略时需要问自己的问题：请参阅http://www.sqlskills.com/BLOGS/PAUL/post/HA-Where-do-you-start-when-choosing-a-high-availability-solution.aspx
再次编辑：
- 其用途示例：数据层中的各种服务器，具有中间层负载平衡。点对点允许所有节点（最终）保持同步。
- 但问题很棘手：如果用户被路由到节点 1 并进行交易，由于复制延迟可能有所不同，数据需要多长时间才能复制到其他节点？如果用户再次连接到服务，将她路由到哪个节点？与之前相同的节点，还是有足够的时间可以安全地路由到任何节点并保证她之前进行的交易已复制到所有节点？
好的 - 不再编辑！:-)
答案2
复制是一种非常多样化的技术，可用于满足许多不同的场景，其选择将决定实施的具体复制类型。
例如，可以通过将应用程序的工作负载分散到多台服务器上来支持分布式处理，即分布式处理架构。
合并复制通常要求应用程序对其环境有相对的了解。还必须考虑诸如冲突解决之类的技术，以确保整个集成环境中的数据一致性。
事务复制的使用方式与日志传送类似，但是您可以限制复制到订阅者的特定对象。如果报告目的只需要表的子集，那么这将非常有用。
有关可用体系结构的完整列表，请参阅以下 Microsoft Replication 参考。
http://msdn.microsoft.com/en-us/library/ms151827.aspx
您使用的复制类型将决定您可能遇到并需要考虑的问题类型。例如，合并复制要求对数据库进行架构更改。
还需要考虑安全问题，例如，是否要在公共互联网上复制数据，或者是否需要加密通信等。
复制是一个大话题，但我希望这些信息能够为您指明正确的方向。
答案3
如果您出于某种原因必须关闭复制并重新启动它（或者只是第一次启动），这往往会导致两个服务器在处理过程中几乎无响应。一旦启动并运行（并保持不动），它就不会引人注意（至少对我们来说不是）。