June 17, 2008 at 10:49 am
Hi all,
This is about T-replication,
i want to know whether we can subscribe a database from other publication and then for this same database can we create a publisher and create subsciber for this publisher.
Ex: A- publisher1
B- subscriber of publisher 1 and publisher 2
C- subscriber of publisher 2
A-->B-->C
i want to implement like this.
if A goes off, then B would be in sync with A to that point before going down and so B and C will be in sync
June 17, 2008 at 10:52 am
A, B and C are all separate servers.
June 17, 2008 at 11:12 am
Yes, you can chain subscriptions like this.
Remember that replication is not designed as a DR solution. By default, foreign keys, identity column definitions, and a few other things do not end up at the subscriber. To make a replicated database a complete copy of a well-defined OLTP system can be a bit tricky. It also does not really provide you with much failover support - Database B would not know if it is supposed to be getting transactions directly against it or not.
June 17, 2008 at 12:29 pm
Thanks,
i am planning for a DR for our production at site A actually, here the production has publisher which is used for report server. we want a setup like this at the other end in a case of DR,
if we are using mirroring we cannot replicate that on the DR side for a DR report server, In order to setup this completely can we use replication chain which i mentioned, what do you suggest doing mirroring is good or replication chain.
Kindly let me know
Thanks again
June 17, 2008 at 12:37 pm
I would typically recommend you do not try to multi-task a server and use it for both a DR solution and a reporting solution. They tend to conflict with each other just enough to make a single solution a little bad for reporting and a little bad for DR. Mirroring is a pretty good, inexpensive DR solution. Replication will work for reporting. So, I think you are on the right path already.
If your mirror is running Enterprise SQL, you would create a database snapshot (not to be confused with "Snapshot Replication" or "Snapshot Isolation" can they use that term a fourth time?) and then transfer this data to a reporting server, but it is a lot of complication with little reward.
June 17, 2008 at 1:07 pm
Mike,
I have only one problem before implementing mirroring in my case, since the database would be in restoring mode on the mirror side i cannot replicate it to the DR report server, so in a case of DR, i need to manually setup the DR reporting server.
Any way where i can acheive failover as well as running my report server at the DR.
June 17, 2008 at 1:22 pm
That is what I meant by don't multi-task your server. You "could" mirror and then use a database snapshot of your mirror so you can see the data on your failover server. I would not really recommend doing this though.
Keep them as two individual processes. Mirror your server for DR - regular mirroring, do not do anything fancy. Then, create a publication from your production server and subscribe to it from your report server - regular replication. Assuming you are doing transactional replication, the bandwidth it uses is the majority of the overhead. Mirroring is pretty low overhead.
If both of these running does not cause a performance bottleneck (it shouldn't) just do both and don't get all fancy.
June 17, 2008 at 1:33 pm
Thank a lot,
i can do mirroring from production server at site A to DR site production server,
and create a subsriber from site A report server to DR site report server
And i dont think there will be any bottleneck in this case, compare to when i would have tried the chain replication.
Thanks
June 17, 2008 at 1:38 pm
my mistake, we dont want to touch our production server, so instead of mirroring from production server at site A, i will do both the mirroring and replication from the report server at site A and mirror on the production at DR and replicate on the report server at DR.
kindly let me know if this sounds good.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply