Minha organização está implementando um aplicativo de replicação interessante para coletar dados de vários bancos de dados do SQL Server e jogá-los em um data lake do Azure. Alguns dos bancos de dados estão em clusters de grupo de disponibilidade. Nossos AGs são configurados para executar backups na réplica secundária.
Por causa disso, minha equipe foi informada de que o aplicativo precisará de metadados de backup para serem sincronizados entre os membros do AG. Em outras palavras:
- o servidor A faz um backup do log de transações do banco de dados foo a cada 15 minutos
- o servidor B faz backups do log de transações da barra do banco de dados a cada 15 minutos
- o servidor A, após a conclusão de seus backups, extrai os metadados de backup do log de transações de B e os adiciona ao msdb
- o servidor B, após a conclusão de seus backups, extrai os metadados de backup do log de transações de A e os adiciona ao msdb
Dessa forma, diz o fornecedor, qualquer que seja a réplica em que um banco de dados esteja, seu aplicativo poderá acessar backups de log de transações e preencher quaisquer lacunas que possam existir se não conseguir acompanhar a captura de dados alterados. O script fornecido por eles usa RESTORE VERIFYONLY…WITH LOADHISTORY para carregar os metadados de backup no msdb. Felizmente, é apenas o backup t-log mais recente para um banco de dados em qualquer AG. Pelo menos por agora.
Nossos clusters AG não têm armazenamento compartilhado para backups, portanto, os backups de outras réplicas apareceriam com caminhos UNC. Pela minha experiência, as pessoas raramente fazem backup usando caminhos UNC e presumo que haja uma boa razão para isso.
- Quão preocupado devo me preocupar com isso?
- Quanta contenção de recursos isso poderia criar? Fiz um teste de verificação em um backup t-log para um de nossos bancos de dados do tamanho de terabytes e ele foi concluído em alguns segundos, mas acho que devo ficar paranóico com isso.
- Se precisarmos executar uma restauração, o servidor de banco de dados realmente tentará mexer nos arquivos de backup nas outras réplicas?
- Se a resposta para o número 3 for sim, existe uma maneira de marcar o registro para que o aplicativo possa usá-lo, mas o SQL Server irá ignorá-lo? Normalmente não mantemos backups por mais de 72 horas (eles são desviados pelo NetBackup), então isso não é um problema?
- Existe uma maneira melhor do que RESTORE VERIFYONLY…WITH LOADHISTORY para carregar os metadados?
Com o backup do secundário, é altamente recomendável que todas as réplicas coloquem seus backups em um local de rede compartilhado. Portanto, caminhos UNC são o que eu normalmente esperaria usar (exceto no Azure, onde você pode usar backup para URL).
É por isso que você coloca os arquivos de backup em um compartilhamento de rede: para que as restaurações possam ser executadas sem saber qual réplica fez o backup ou se conectar diretamente às réplicas.
Quanto ao resto, é para isso que serve 'RESTORE VERIFYONLY…WITH LOADHISTORY'.