May 17, 2016 at 8:33 pm
Hi Guys,
Need your expert advise on 2 node alwayson.
For async mode, understand that there will be potential data loss. Reason is because transacations commited at primary site may not been replicated over the secondary at any point of time as commit confirmation is not required from secondary before the primary db commit transactions.
In this case after a manual force failover, the original primary db may consists of commited transations that are not in the secondary (new primary). If this is the case, since the original primary db (new secondary) is not longer in sync with the new primary... do we have to restore the db from new primary to the new secondary before resuming the alwayson replication? Or basically we can just resume it and the new secondary will sync with the new primary? (probably by discarding commited transaction in new secondary resulting in data loss).
thanks
May 17, 2016 at 8:51 pm
People chose async because they made a decision to allow losing data. Since you already made that decision before hand, there is no reason to now do a restore, right?
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
July 16, 2016 at 12:37 am
thanks SQLGuru.
Yup, just want to gain more knowledge on this. after a manual force failover, if we did not do a full restore on the new secondary and we opt to resume the replication, will it discard the committeed transactions automatically.
seeking advise.
In this case after a manual force failover, the original primary db may consists of commited transations that are not in the secondary (new primary). If this is the case, since the original primary db (new secondary) is not longer in sync with the new primary... do we have to restore the db from new primary to the new secondary before resuming the alwayson replication? Or basically we can just resume it and the new secondary will sync with the new primary? (probably by discarding commited transaction in new secondary resulting in data loss).
July 16, 2016 at 7:11 am
You can force the secondary to become the primary and accept the data loss that happens due to unaccepted tlog activity from the primary. Or you can shut down everything and do a complete restore to the best of your backup availability and timing. Or if you have access to the primary and the database tlog you could back it up and manually restore to secondary to get what wasn't sent.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply