Question

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!

Was it helpful?

Solution 2

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/

OTHER TIPS

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?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top