Avamar : Comment restaurer correctement les bases de données SQL sur le réplica secondaire dans les paramètres d’un cluster AlwaysOn

• Une restauration redirigée d’une base de données SQL sauvegardée par Avamar est exécutée vers le réplica secondaire.
• La restauration est terminée.
• La base de données du secondaire est à l’état « Restoring ».
• Lorsque vous tentez de joindre le groupe de disponibilité, une erreur s’affiche :

Impossible de joindre la base de données « ABC » au groupe de disponibilité « AG » sur le réplica de disponibilité « secondary\AG_Sec ».

Cette procédure est décrite dans le Guide d’Avamar SQL dans la section « Restauration vers le groupe de disponibilité d’origine ». Elle se lit comme suit :
 

When you restore to the original availability group, the restore process can automatically restore the databases on both the primary replica and the secondary replicas. 
You can also restore databases only on the primary replica. 
When you restore a  database only on the primary replica, the corresponding database on the secondary replicas is in a restoring state. 
To restore the databases on the secondary replicas as part of the availability group, manually prepare and restore the databases, and join them to the availability group on the secondary replicas. 
You can also set the databases on a secondary replica online without rejoining them to the availability group by restoring the databases with the RECOVERY recovery operation. 

Le secondaire doit être à l’état de restauration. Le problème est que la base de données « ABC » sur le réplica secondaire « secondary\AG_Sec » n’est pas synchronisée avec le réplica principal. Cela est dû au fait qu’il manque certains enregistrements de journaux.

SQL Server AlwaysOn n’est pas en mesure d’appliquer les journaux restants pour les maintenir synchronisés. 

Dans ce cas, la première étape consiste à vérifier la séquence LSN de la base de données ABC à partir des deux nœuds de réplica.

Pour le vérifier, exécutez la requête suivante :
 

SELECT msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_start_date,
msdb.dbo.backupset.backup_finish_date,
msdb.dbo.backupset.type,
msdb.dbo.backupset.database_backup_lsn,
msdb.dbo.backupset.first_lsn,
msdb.dbo.backupset.last_lsn
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset
ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 
WHERE database_name IN ('ABC')
--and msdb.dbo.backupset.backup_finish_date between '1/20/2022' and '12/23/2022'
ORDER BY 
2 DESC,
3 DESC

Cela vous donne une description complète de l’historique des sauvegardes pour ('ABC') pour l’année 2022.
Vous pouvez personnaliser la plage de dates pour répondre à vos besoins.
L’important est de vérifier si les numéros LSN primaire et secondaire de cette base de données sont synchronisés.

Pour résoudre ce problème, restaurez les sauvegardes de log manquantes sur le serveur secondaire à partir de Primary :
Back, puis vérifiez que les noms LSN sont synchronisés avant de joindre la base de données au groupe AlwaysOn.