Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
MuadDBA
628 Posts |
 Posted - 2012-10-23 : 14:31:41
|
| I have 5 servers in production which participate in Merge and Transactional Replication. We'll call these servers PS1 - PS5.At my DR Site, I have 5 servers as well. We will call these DRS1 - DRS5.The DR site is separated from the primary site by nearly 1,000 miles. The data is sent to our DR site using SAN replication, not DB replication/mirroring, as it allows for a much reduced bandwidth footprint.Currently, our DR site is enabled for replication but the various publications and articles are not set up there, as the DBs are not mounted until a DR event or exercise is initiated.At that point, the DBs are mounted, and sp_removedbreplication is executed against each published DB. The publications are then regenerated, subscribers added, and snapshots created.Since I have a very small window in order to complete the DR stand-up, I am looking to simplify and streamline wherever possible. I have noticed that to run the sp_removedbreplication proc, it takes 10 minutes on the publisher. That's 10 minutes I need back, if possible.My plan is to cease the execution of sp_removedbreplication. Instead, I'd like to mount the DBs on the DR side just long enough to create the publications/articles/jobs for merge and transactional replication in the system DBs (which are not part of the SAN replication topology), so that when I mount the volumes during a DR exercise I don't have a need to rip out the replication. I just need to drop the production subscribers, add the DR subscribers, and do the snapshots.Does this sound feasible? Is there a better approach to this given the constraints of using SAN replication to duplicate my environment? |
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2012-10-23 : 22:10:01
|
| So some of the SAN replicated databases in production also participate in Transactional and/or Merge Replication?I have a similar topology.But...we detach the DR databases, copy the mirrors over, and re-attach em every night so the DR site is always current. For databases on the DR site that participate in transactional replication but won't do so in a DR event, we do nothing. Having replication enabled won't hurt. So don't waste your time there.What SAN vendor/product do you have? If it's the same as ours, I can give you a lot of pointers. We've pioneered some techniques that our vendor highlights to new customers today. |
 |
|
|
MuadDBA
628 Posts |
Posted - 2012-10-24 : 15:03:52
|
| Since the prod environment is Merge/Transactionally replicated, the DR servers also must be configured to talk to each other in the same way. I don't want the prod servers merging with DR servers, or vice versa, I want them to each be in their own little bubbles.We're using NetApp 6070 appliances. |
|
|
|
russell
Pyro-ma-ni-yak
5072 Posts |
Posted - 2012-10-25 : 17:05:11
|
| How often are you synching?Surprising it's taking 10 minutes to remove replication.Also, I don't think the production subscribers will participate with the DR distributor...they will be looking for the production one. Do the machines have the same names on both sides?What we do is to mount the production dbs in the DR site on a schedule and apply the replication scripts. This way, in a DR event, we have only to apply the deltas. |
|
|
|
MuadDBA
628 Posts |
Posted - 2012-10-30 : 10:48:37
|
| Sorry this took so long to get back to. Are you using merge replication at your DR site? What do you mean "you only have to apply the deltas." If you create new subscribers for merge replication, they need to be synced with a snapshot, no? Otherwise you have to manage the identity ranges manually.... |
|
|
|
|
|
|
|
|
Removing/Rebuilding Replication during DR