Good day
In production I have a Basic Availability group over two Windows 2019 VM's, setup as WSFC with SQL 2016 STD installed.
These VM's sit on a Server 2019 2 node Cluster.
Being Windows 2019, my backup software wants to do a Hyper-V production checkpoint to invoke VSS to backup the nodes.
This works successfully for whichever node is the primary but never the secondary. I believe this is because as per SQL 2016 STD licencing, the secondary is non-readable. This is also repeatable by using Hyper-V manager to checkpoint the VM.
When looking at the event viewer on a failing VM (whichever is the secondary at the time ) I see the following
Sqllib error: OLEDB Error encountered calling ICommandText::Execute. hr = 0x80040e14. SQLSTATE: 42000, Native Error: 3013
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: BACKUP DATABASE is terminating abnormally.
SQLSTATE: 42000, Native Error: 976
Error state: 1, Severity: 14
Source: Microsoft SQL Server Native Client 11.0
Error message: The target database, 'RDSFARMDB', is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to
this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group. For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online.
I don't mind that the secondary cannot be read, but my issue is that it doesn't gracefully fail and continue, but halt the checkpoint procedure which then stops the backup from working for all other data on that VM.
Assuming this is all intended behaviour, is there a way to tell SQL VSS writer to ignore failing to read the secondary read only SQL database, allowing VSS to complete, the production checkpoint to get created and then the backup software to do its thing?
I have contacted the Vendor, who said their software has to use Hyper-v production checkpoints, which has lead me to looking at the SQL writer on the secondary as a potential fix
Kind regards
James