I'm in a unique situation and trying to figure out how to "reset" log shipping back to 2 secondaries after a dry run of a migration. A little background is needed to explain more.
I am practicing a migration from a standalone install to a 2 node AG setup in the cloud. I currently have log shipping setup from the source to both node1 and node2.
Once the dry run completes, the setup will then be as follows, which is where my problem starts:
- Node 1 is primary, node2 secondary. The DB is in an AG
- Log shipping is setup from node1 to the old standalone server to allow for a rollback if needed.
What I need to do now is to "reset" log shipping to what it was prior to the dry run (source being the on prem, log shipping to the 2 node AG in the cloud) so we can do another dry run. I'm trying to avoid doing a fresh backup and restore on the cloud server due to the time it takes to transfer a backup there. What I am running into is below:
- I remove the DB from the AG, which puts node2 into recovery mode
- Take a tail of the log backup on node1, and apply it to the source DB, full recovering it. This leaves node1 and node2 in restoring state.
I should have to restore the tail of the log to node2 as well, but when I try it I get an error as below
The log in this backup set begins at LSN 80000000080700001, which is too recent to apply to the database. An earlier log backup that includes LSN 80000000080400001 can be restored.
prior to taking the tail of the log backup, there were no other log backups taken, as I disabled the log backup job previously. I don't know why I cannot apply the tail of the log to Node2 in this instance.
When i moved on and then configured log shipping back from the on prem to node 1 and node2, node 1 applies the new log backups like normal, but node2's restore job cannot find any backups to apply to the DB.
Is there a different way that I should go about this? Do I need to take a fresh backup of the On Prem DB and restore that to node1 and node2 and allow log shipping to catch it up?