Skip to main content

SQL AON backup is configured and it is known that the DB backup runs via primary node and log backup runs based on the preference settings. It was running as expected. 

 

However, when the failover happens at DB side primary becomes secondary and vice versa. But the SQL Backup Master is still pointing to the same old primary node. 

 

How can we make the SQL backup master services to be rolled back to the new primary node.

Just double checking, do you have an availability group pseudoclient configured?

https://documentation.commvault.com/11.24/essential/121924_creating_sql_always_on_availability_group_instance.html

Commvault should track failovers and redirect backups to the primary nodes etc. The pre-requisite is if you configured the SQL availability instance type rather than treating each physical node independently. 


Yes @Damian Andre . AG Pseudoclient configured. Though I can see the primary node is showing properly in the instance properties, it is trying to take the backup from the primary node via secondary node. 

 

This leads to enable the commvault port communication between primary and secondary node.


Hello - it is recommended to have communication open between the Primary and Secondary AG nodes as the SQLBackupMaster process will need it to negotiate which machines to run backups on. The two AG nodes need to be able to communicate to each other for this process. 

Are you sure they are enabled for this communication?


No. The communication ports are not opened between the nodes. 

SQLBackkupMaster process is not getting transferred when failover happens. 

What if the primary node is completely down and secondary node becomes primary. In this case how the backup will perform ?


Hello,

Thank you for the clarification. So the SQLBackupMaster process is still spawning on the original node, but are the backups running from the correct primary replica still? The SQLBackupMaster process is a coordinator thread that reads the AG replica configuration to best determine which AG node to delegate the task out to. Regardless of which node this does spawn on, it should read the proper replica status from SQL and negotiate the backups successfully. In the event that one of the AG nodes is completely down, the SQLBackupMaster could run on the available node and negotiate the backups still. 


@Ron Potts Yes the SQLBackupMaster process is still running on the original primary node (which becomes secondary now). i.e the SQL Backup Master process is available in the secondary node now.  

 

The backup was working fine with the actual primary and secondary node. It started failing when the failover happens. 

 

The question here is why the SQL Backup Master process is not getting rolled over to other node during the failover ? 


I am not sure if SQLBackupMaster needs to switch nodes during the failover of the AG as SQLBackupMaster is a coordinator thread that determine who is Primary and who is Secondary. As long as that node is still online and the two SQL Server nodes can communicate to each other. The SQLBackupMaster will reach out to the nodes to start be backups accordingly on either node depending on the backup preference. If one of the nodes are not reachable, SQLBackupMaster should spawn on the next node that is. 

 

Now, if you are seeing a failure after the failover of the AG nodes - can you provide the error that you are receiving from the JAVA Console/Command Center? That would help us narrow down the failure further. 


@psbsanthoshkumar , following up to see if you had a chance to review @Ron Potts ‘ response.

Thanks!


Enabling the communication between the nodes fixed the issue. However, it is not as per our design


@psbsanthoshkumar , can you clarify the second sentence?  What do you mean by ‘not per our design’?

Thanks!


Reply