代码之家 › 专栏 › 技术社区 › Paul Suart Wes

是否可以通过事务复制获得亚1秒的延迟?

replication architecture performance sql-server-2005

Paul Suart Wes · 技术社区 · 15 年前

我们的数据库体系结构由两个SQL Server 2005服务器组成,每个服务器都有一个相同数据库结构的实例:一个用于所有读取,一个用于所有写入。我们使用事务复制来保持读取数据库的最新状态。

这两个服务器确实是非常高规格的(写服务器有32GB的RAM),并且通过光纤网络连接。

当我们决定使用这种体系结构时,我们会认为将数据复制到读服务器的延迟将是几毫秒(显然取决于负载)。实际上,即使在最简单的情况下,我们也能看到约2-5秒的延迟,这并不令人满意。在最简单的情况下,我的意思是在写数据库的单个表中的单个行中更新单个值,并查看在读数据库中观察新值需要多长时间。

我们应该考虑哪些因素来实现低于1秒的延迟?这是可以实现的吗?

或者,我们是否应该考虑不同的复制模式?数据和日志文件位置的最佳实践是什么?

编辑

感谢大家的建议和见解-我相信我们正在经历的延迟期是正常;我们被我们的数据库托管公司错误地引导到了预期的延迟时间!

我们使用的技术是 this MSDN article (标题为“缩放数据库”),我们未能正确处理此警告:

创建这样的专用数据库的结果是延迟:现在要将写操作分发到读卡器数据库需要一些时间。但是,如果您能够处理延迟,那么扩展的潜力是巨大的。

我们现在正在研究实现对缓存机制的更改,当数据项被认为是“易失性”时,该机制强制从写数据库中读取数据。

3 回复 | 直到 15 年前

Mitch Wheat Scott Wisniewski 15 年前

不可能。使用SQL Server事务性复制(即使使用快速硬件),也很难达到子1延迟时间。

如果你能得到1-5秒的延迟,那么你做得很好。

从 here :

使用事务复制用户可能是少数比出版商晚了几秒。用一个潜伏期只有几秒钟, 用户可以很容易地用作报表服务器,卸载成本高昂用户查询和报告发布服务器到订阅服务器。

在以下场景中(使用此中稍后显示的客户表 (第节)订户只有四个比出版商晚了几秒。偶数更令人印象深刻的是,60%的有两秒钟的延迟时间或更少。时间是从插入记录时,或在发布服务器上更新到实际写入订阅数据库。

Bravax 15 年前

我认为这是绝对可能的。

我会看看:

你的网络
在两台服务器之间运行ping命令,查看是否有任何问题
如果服务器相邻,您应该有1毫秒的时间。
服务器上的瓶颈
这可能是网络流量(卷)
就像网卡没有配置为每秒1GB
防病毒或其他东西
对一些查询做一些分析,看看是否可以识别索引或锁定,这可能是一个问题。
查看读取数据库上的任何选择是否可能阻止写入。
添加(nolock),看看这对您正在分析的一个或两个查询是否有影响。

本质上,您有一个复杂的系统,您有一个问题,您需要确定哪个组件是问题,并解决它。

如果需要运行的报告/选择需要最新,则事务复制可能是最好的。如果没有,您可以查看日志传送,尽管这会增加每次导入的停机时间。

对于数据/日志文件,请确保它们位于不同的驱动器上,以便最大限度地提高性能。

mrdenny 15 年前

关于事务复制,需要记住的一点是,一个更新现在需要执行多个操作才能发生更改。

首先更新源表。接下来,日志阅读器将看到更改并将更改写入分发数据库。接下来,分发代理在分发数据库中看到新条目并读取该更改,然后在订阅服务器上运行正确的存储过程以更新该行。

如果监视这两个服务器上的语句运行时间,您可能会看到它们仅在几毫秒内运行。但是,这是等待日志读取器和分发代理看到他们需要做一些会杀死您的事情时的延迟时间。

如果您确实需要次秒的处理时间,那么您将希望编写自己的处理引擎来处理从一台服务器到另一台服务器的数据移动。我建议使用SQL Service Broker来处理这一问题,因为这样所有内容都是SQL Server固有的,不需要编写任何第三方代码。