HDR with Synchronous replication

On Wed, 23 Jun 2004 15:01:50 -0400, rkusenet wrote: > I have few questions about replication: > > (a) if we use sychronous replication (DRINTERVAL set to zero) what happens Ahh, so that's what you meant (separate communication) by synchronous. Not really synchronous, just asynchronous with no delay. There is no direct connection between the servers that's connected to the transactions themselves. Nothing waits for replication to occur, so truly it's always asynchronous. > if > the secondary goes down or the connectivity between P and S goes off. > Will the primary server continue, albeit with a replication queue > building inside it. Or will it stop working all together. What is the > performance penalty for using DRINTERVAL to zero. Unlike ER there IS no replication queue to build. HDR replication happens because IFF there is a current connection to a secondary from a primary, each logical log file is shipped to the secondary. If the secondary goes down, when it comes back up and handshakes with the primary it sends "I last processed logical log # 12345, please synch me.". If logical log #12346 is still online on the primary the primary begins shipping all logical logs from 12346 to the current log over to the secondary to be applied. If log 12346 is no longer online (archived, freed, and reused) the replication startup of the secondary will fail and you will have to either do a physical restore of a new level 0 archive taken from the primary or perform a logical restore of all logical logs from 12346 at least to the earliest one still available on the primary before attempting to bring the secondary up in secondary mode again. > (b) if we have asynchronous replication (DRINTERVAL set to nonzero), what > happens > when the primary goes down and secondary is made the new primary. It > will not have those transactions which weren't pushed out from the > original primary. In other words there is always a chance of missing out > some transactions which couldn't be pushed out to secondary. How much we > miss, will of course depend on the latency. Same as above. Nothing is lost as there is no 'pushing' being done. When the secondary tries to change from stand-alone mode to secondary mode it tells the primary where it was up to when it crashed and if it can the primary sends the secondary what it needs to catch up. If it cannot then you either load the 'missing' logical logs from archive in a logical restore or perform a level 0 archive on the primary and perform a physical restore of that on the secondary. As I stated above and offline, there IS ONLY asynchronous HDR replication. > So it looks like, if we want to have an assurance that all commited > transactions should never be lost, it has to be a sychronous replication. No! Transactions are never lost either way. The only difference is how soon you can depend on the results of a transaction on the primary to be available on the secondary. That's about ALL that DRINTERVAL affects. Art S. Kagel

I have few questions about replication: (a) if we use sychronous replication (DRINTERVAL set to zero) what happens if the secondary goes down or the connectivity between P and S goes off. Will the primary server continue, albeit with a replication queue building inside it. Or will it stop working all together. What is the performance penalty for using DRINTERVAL to zero. (b) if we have asynchronous replication (DRINTERVAL set to nonzero), what happens when the primary goes down and secondary is made the new primary. It will not have those transactions which weren't pushed out from the original primary. In other words there is always a chance of missing out some transactions which couldn't be pushed out to secondary. How much we miss, will of course depend on the latency. So it looks like, if we want to have an assurance that all commited transactions should never be lost, it has to be a sychronous replication. TIA.