数据库镜像和服务代理,镜像路由无法运行
我们有一个服务代理运行了相当长的一段时间(在同一台服务器上运行)。现在我们要在两台服务器之间添加数据库镜像。
为此,我们必须为服务代理创建新的路由和新的端点(以在故障转移时支持镜像)。
我们已经在运行完全相同版本的 Windows 和 sql-server 的开发环境中进行了尝试。即:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1734.0 (X64) Aug 11 2010 12:51:02 版权所有 (c) Windows NT 6.1 上的 Microsoft Corporation Enterprise Edition(64 位)(Build 7600:)
一个区别就是开发环境运行在虚拟系统中。
当我们在生产环境中实现这一点时,我们遇到了在开发环境中从未见过的问题。
服务代理更新变得非常慢,但我们可以看到一些消息已通过。
我们收到的错误消息是:
镜像路由无法运行。 “TCP://server1.domain.local:4022”充当“未知” []。 “TCP://server2.domain.local:4022”充当“未知” []。
镜像路由可运行,但仅连接到主体。 “TCP://server1.domain.local:4022”充当“主体”[]。 “TCP://server2.domain.local:4022”充当“未知”[]。
在我们的开发服务器上,我们收到了类似的消息:
镜像路由正在运行。 “TCP://server1.devdomain.local:4022”充当“镜像” []。 “TCP://server2.devdomain.local:4022”充当“主体” []。
镜像路由可运行,但仅连接到主体。 “TCP://server1.devdomain.local:4022”充当“未知”[]。 “TCP://server2.devdomain.local:4022”充当“主体”[]。
正如您所看到的,我们收到有关镜像路由在我们的生产服务器上无法运行的消息,但在我们的开发服务器上却无法运行。
数据库镜像是通过端口 5022 设置的,服务代理是 4022。
如何创建路由/端点的一些示例:
--created on booth principal and mirror
CREATE ENDPOINT [Mirroring]
AUTHORIZATION [domain\sqlservice]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = DISABLED)
--created on booth principal and mirror
CREATE ENDPOINT [BrokerEndpoint]
AUTHORIZATION [domain\sqlservice]
STATE=STARTED
AS TCP (LISTENER_PORT = 4022, LISTENER_IP = ALL)
FOR SERVICE_BROKER (MESSAGE_FORWARDING = DISABLED, MESSAGE_FORWARD_SIZE = 10, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = DISABLED)
--created in DB1 (on principal)
CREATE ROUTE [RouteToDB2] AUTHORIZATION [dbo] WITH SERVICE_NAME = N'ExecSPReceiveService' , BROKER_INSTANCE = N'DF46452B-97F3-4924-AD2A-A130FDC2016F' , ADDRESS = N'TCP://server1.domain.local:4022' , MIRROR_ADDRESS = N'TCP://server2.domain.local:4022'
--created in DB2 (on principal)
CREATE ROUTE [RouteToDB1] AUTHORIZATION [dbo] WITH SERVICE_NAME = N'ExecSPSendService' , BROKER_INSTANCE = N'91CBA730-48A2-47A8-95C8-0558706250AB' , ADDRESS = N'TCP://server1.domain.local:4022' , MIRROR_ADDRESS = N'TCP://server2.domain.local:4022'
当我们删除数据库镜像端点时,一切都开始正常工作。
有什么想法吗?
谢谢!
We have had a service broker running for quite some time (running on the same server). Now we want to add database mirroring between two servers.
For this to work we had to create new routes and new endpoints for the service broker (to support mirroring in case of a failover).
We have tried this in a development environment running the exact same version of windows and sql-server. Which is:
Microsoft SQL Server 2008 R2 (RTM) - 10.50.1734.0 (X64) Aug 11 2010 12:51:02 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7600: )
One difference is that the development environment is running in a virtual system.
When we implemented this in our production environment we got problems that we never saw in the development envornment.
The service broker updates became really slow, but we could see that some of the messages came through.
The error message that we get is:
The mirror route is not operational. 'TCP://server1.domain.local:4022' is acting as 'Unknown' []. 'TCP://server2.domain.local:4022' is acting as 'Unknown' [].
The mirror route is operational, but only connected to principal. 'TCP://server1.domain.local:4022' is acting as 'Principal' []. 'TCP://server2.domain.local:4022' is acting as 'Unknown' [].
On our development servers we got a similar message:
The mirror route is operational. 'TCP://server1.devdomain.local:4022' is acting as 'Mirror' []. 'TCP://server2.devdomain.local:4022' is acting as 'Principal' [].
The mirror route is operational, but only connected to principal. 'TCP://server1.devdomain.local:4022' is acting as 'Unknown' []. 'TCP://server2.devdomain.local:4022' is acting as 'Principal' [].
As you can see we get messages about that the mirror route is not operational on our production servers, but not on our development servers.
The database mirroring is setup over port 5022, and service broker for 4022.
Some example of how routes/endpoints were created:
--created on booth principal and mirror
CREATE ENDPOINT [Mirroring]
AUTHORIZATION [domain\sqlservice]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (ROLE = PARTNER, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = DISABLED)
--created on booth principal and mirror
CREATE ENDPOINT [BrokerEndpoint]
AUTHORIZATION [domain\sqlservice]
STATE=STARTED
AS TCP (LISTENER_PORT = 4022, LISTENER_IP = ALL)
FOR SERVICE_BROKER (MESSAGE_FORWARDING = DISABLED, MESSAGE_FORWARD_SIZE = 10, AUTHENTICATION = WINDOWS NEGOTIATE, ENCRYPTION = DISABLED)
--created in DB1 (on principal)
CREATE ROUTE [RouteToDB2] AUTHORIZATION [dbo] WITH SERVICE_NAME = N'ExecSPReceiveService' , BROKER_INSTANCE = N'DF46452B-97F3-4924-AD2A-A130FDC2016F' , ADDRESS = N'TCP://server1.domain.local:4022' , MIRROR_ADDRESS = N'TCP://server2.domain.local:4022'
--created in DB2 (on principal)
CREATE ROUTE [RouteToDB1] AUTHORIZATION [dbo] WITH SERVICE_NAME = N'ExecSPSendService' , BROKER_INSTANCE = N'91CBA730-48A2-47A8-95C8-0558706250AB' , ADDRESS = N'TCP://server1.domain.local:4022' , MIRROR_ADDRESS = N'TCP://server2.domain.local:4022'
When we remove the database mirroring endpoint everything starts to work normal again.
Any ideas?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
问题是由于我们为服务代理设置了“即发即忘”模式。
http://rusanu.com/2006/04/06/fire-and-forget-good-for-the-military-but-not-for-service-broker-conversations/
我们实施了一个更好的rusanu 推广的解决方案,此后一切正常。
我们还使用了此处显示的“快速数据推送”示例 http://msftsbprodsamples.codeplex.com/
The problem were due to that we had the "fire and forget" pattern setup for service broker.
http://rusanu.com/2006/04/06/fire-and-forget-good-for-the-military-but-not-for-service-broker-conversations/
We implemented a better solution that rusanu promotes and everything has been working after that.
We also used the "fast data push" examples that are shown here http://msftsbprodsamples.codeplex.com/
据我所知,这些消息不是错误,而是主体与镜像服务器建立连接时记录的预期信息消息。未使用的镜像连接会在 90 秒不活动后被断开,然后根据需要重新连接,因此根据您的镜像数据移动模式,您可能会或多或少地看到这些路由消息。
当您说 Service Broker 更新变得非常慢时,您能否提供一些数字来说明它与基准相比慢了多少?
As far as I know, these messages are not errors, but rather expected informational messages that get logged when the principal establishes a connection with the mirror server. Mirroring connections that are not used get dropped after 90 seconds of inactivity and then re-connect on demand, so depending on your mirroring data movement pattern, you may see these routing messages more or less often.
When you say that Service Broker updates became really slow, can you provide some numbers saying how much slower it is compared to baseline?