Avamar: Como restaurar com sucesso bancos de dados SQL na réplica secundária em configurações de cluster AlwaysOn
Summary: Avamar 19.4.100-124 com cluster de 2 nós do SQL 2016 AlwaysOn O cliente está fazendo a restauração de redirecionamento dos bancos de dados SQL na réplica secundária e, embora a restauração do Avamar seja concluída, os bancos de dados falham ao ingressar no cluster com o erro: Falha ao associar o banco de dados "ABC" ao grupo de disponibilidade "AG" na réplica de disponibilidade "secondary\AG_Sec" ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
- Uma restauração redirecionada de um banco de dados SQL com backup do Avamar é executada na réplica secundária.
- A restauração é concluída.
- O banco de dados na secundária está em "Restoring state".
- Ao tentar ingressar no grupo de disponibilidade, um erro é exibido:
Falha ao associar o banco de dados "ABC" ao grupo de disponibilidade "AG" na réplica de disponibilidade "secondary\AG_Sec".
Esse procedimento está documentado no Guia Avamar SQL, na seção "Restaurar para o grupo de disponibilidade original". Lê-se:
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.
Espera-se que o secundário esteja em um estado de restauração. O problema é que o banco de dados "ABC" na réplica secundária "secondary\AG_Sec" não está em sincronia com a réplica primária. Isso ocorre porque alguns registros de log estão ausentes.
SQL Server AlwaysOn não é capaz de aplicar os logs restantes para mantê-los ambos sincronizados.
Nessa situação, a primeira etapa é verificar a sequência LSN para o banco de dados "ABC" de ambos os nós de réplica.
Execute a seguinte consulta para verificar isso:
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
Isso fornece um detalhe completo do histórico de backup para ('ABC') para o ano de 2022.
Você pode personalizar o intervalo de datas para atender às suas necessidades.
O ponto importante é verificar se os números LSN primário e secundário para este banco de dados estão sincronizados.
Para resolver, restaure os backups de registros ausentes no secundário em Primary:
Back up e, em seguida, verifique se os nunbers LSN estão sincronizados antes de associar o banco de dados ao grupo AlwaysOn.
Article Properties
Article Number: 000206971
Article Type: How To
Last Modified: 05 Sep 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.