One of my clients contacted me for whom I assisted in configuring Always On Availability Groups for the first time. They were getting an error whole taking log backup on secondary replica: Log backup for database “SQLAuthority” on secondary replica failed because the new backup information could not be committed on the primary database.
During implementation, I explained to them various topologies, pros, and cons and assisted them in doing the end-to-end implementation as this was their first availability group. If you want any such implementation related assistance, feel free to contact me.
Secondary Replica
After I implemented their first availability group, they got comfortable and implemented distributed availability group on their own. They contacted me and informed that things are going well but they are seeing an error when they take log backup of an availability database on a secondary replica of the secondary availability group. Below is the message from job history.
Log backup for database “SQLAuthority” on secondary replica failed because the new backup information could not be committed on the primary database. Check the database status in the SQL Server error log of the server instance that is hosting the current primary replica. If the primary database is participating in the availability group, retry the operation. Check the database status in the SQL Server error log of the server instance that is hosting the current primary replica. If the primary database is participating in the availability group, retry the operation. [SQLSTATE 42000] (Error 35296) BACKUP LOG is terminating abnormally.
To make things simple, you can imagine a deployment like this.
myAG1 (mynode1, myNode2) <- myDistributedAG –> myAG2 (myNode3, myNode4)
Distributed availability group is created between myAG1 and myAG2. myNode1 is global primary and myNode3 is a forwarder. The failure of the job is happening on myNode4.
SOLUTION/WORKAROUND
I tried this in my lab, and I was able to get exactly the same error. I searched further and found that this is by design. I found below information in this link.
In a distributed availability group, backups can be performed on secondary replicas in the same availability group as the active primary replica, or on the primary replica of any secondary availability groups. Backups cannot be performed on a secondary replica in a secondary availability group because secondary replicas only communicate with the primary replica in their own availability group. Only replicas that communicate directly with the global primary replica can perform backup operations.
When I informed this to my client, they were able to understand this limitation and modify the scripts to take backup accordingly.
Have you seen such errors while working with the availability group? Please share via comments.
Reference: Pinal Dave (https://blog.sqlauthority.com)