November 4, 2013 at 10:25 am
Hi, I was wondering if experts here can help with an advise 🙂
Let's say I have a site A with 2 servers - PROC1 (where data processing happens) and WEB1 (used as web server database). There is a database MYDB that is replicated (both transactional and snapshot) from PROC1 to WEB1.
I have a new remote site B that I want to use as a backup. So I would need PROC2 and WEB2 to be kept in sync with PROC1 and WEB1.
Am I correct that the only option for this to work is to have 2 log shipping setup: one for PROC1-> PROC2, and another for WEB1->WEB2? And if site A having troubles I would need to bring both DBs on site B online and then setup replication there (PROC2->WEB2). Plus of course I'd need to start collecting logs for PROC2, WEB2 to get ready for roles reversal (to switch back to site A as primary if/when needed).
The thing is both PROC and WEB database are quite large and ideally it would be nice to have 1 log shipping set only (PROC1->PROC2) and have replication set for PROC2->WEB2. But it seems like there is no way to have replication set on a database that is in STANDBY or NORECOVERY.
Or perhaps there is some other way?
Thank you
November 4, 2013 at 8:43 pm
Can you give it in more clear way?
As far as i understand , you want to implement log shipping and replication.
I can tell you one thing from log shipping you can log ship to more than one server in that case. so you can ship from proc1 to proc2 , web1 and web2
I have no idea in replication so i dont how to go about replication and log shipping of same DB's.
Regards
Durai Nagarajan
November 17, 2013 at 3:44 am
Hi,
I think the better solution would be to have log shipping enabled on both Proc1 & Web1 to site B and then enable replication only if you want to put serves on site B on production, as per as i know you can not enable replication on databases on Standby or Norecovery mode.
hope this helps.
November 20, 2013 at 10:46 am
Praveen,
yes, it looks like that's not just a better solution, but the only one.
I've setup a test environment with 2 pairs of servers in different locations and checked different approaches. Unfortunately the replication needs to update replication status in syssubscriptions (and probably other) system table in the database under replication. And since it is in read-only mode while being the target of log shipping, it naturally fails.
I wonder why this status details wouldn't be stored (and updated) in Distribution database - after all most of replication info and data is there.
So I'm back to square one and have to move same data twice.
Regards,
Alex
November 21, 2013 at 1:55 am
You are right in that you cannot replicate from a logshipped database.
a) You could logship both databases
b) If the dbs could be mirrored and if needed to be readable, create a snapshot
c) Logship PROC1 to PROC2, add another subscriber to PROC1 to WEB2 (this may complicate things if you bring site 2 online)
November 21, 2013 at 1:59 am
_api_ (11/20/2013)
I wonder why this status details wouldn't be stored (and updated) in Distribution database - after all most of replication info and data is there.
The commands are marked as REPLICATE in the transaction log and these are written locally so the engine needs to have to knowledge of which commands to mark.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply