Transferir arquivos de um Banco de Dados no AlwaysOn
Neste post quero documentar a transferência de arquivos de um Banco de Dados entre discos, quando esse BD está numa instância com AlwaysOn - Availability Groups (AG). O objeto deste passo a passo é ajudar você a mover os arquivos dos BDs, com o menor tempo de indisponibilidade dos Bancos de Dados.
Fiz esta reorganização de arquivos usando Windows 2012 R2 cluster com instâncias de SQL Server 2014 Enterprise. O processo também funciona para as versões posteriores do SQL Server. Os nomes dos servidores neste exemplo são:
Servidor principal: SQLSERVER01
Servidor secundário: SQLSERVER02
Banco de Dados: AdventureWorks2014
Availability Group: AGMELLO
Vamos começar localizando os arquivos do BD nos servidores principal e secundário.
No principal, SQLSERVER01:
No secundário, SQLSERVER02:
Nesta demonstração, vamos mover o arquivo MDF para F:\SQLData, e o arquivo LDF para G:\SQLLog, sem deixar o BD indisponível para os usuários. Todo o trabalho vai acontecer na instância secundária, usando a opção "Remove secondary database from the Availability Group" para mover os arquivos para as novas pastas, e depois vamos reincluir o BD manualmente de volta para o AG.
PASSO 1 - Parar os backups de LOG
Este passo é crítico, e garante que o arquivo de log não seja truncado.
O job de backup de log deve ser desativado em todas as instâncias.
Como estamos usando a opção de remover o BD secundário do AG, o arquivo de log precisa ficar intacto quando reincluirmos o BD no AG. Se os backups de log continuarem acontecendo, os arquivos de log de transações serão marcados para reutilização e truncados, e a reinclusão do BD no AG falharia. Então, a única opção disponível seria aplicar manualmente os backups de log ou executar nova inicialização com backup completo, o que pode ser demorado.
Como o arquivo de log não será truncado porque os backups de log estão desabilitados, garanta que existe espaço em disco suficiente no servidor principal para que os arquivos de log possam crescer, se necessário, enquanto trabalhamos na instância secundária.
PASSO 2 - Retirar o BD do AG
A movimentação dos arquivos ocorrerá nas instância secundária do AG. Conecte-se na instância secundária e suspenda a movimentação de dados no AG, como na imagem:
Quando a movimentação de dados é suspensa, o status do banco de dados no AG muda para "Not-Synchronizing".
Agora vamos remover o banco de dados do AG, usando a opção "Remove Secondary database":
Depois de remover o BD do AG, um sinal de alerta aparece ao lado do BD na lista do AG. E o BD muda para o estado "Restoring":
PASSO 3 - Mover os arquivos para as novas pastas
Agora que o banco de dados está fora do AG, podemos movê-los para as novas pastas.
Primeiro, vamos configurar o novo caminho dos arquivos:
Como o banco de dados está em modo Restoring na instância secundária, não podemos colocar o BD offline para mover os arquivos. Neste caso, vamos parar a instância do SQL Server no servidor secundário.
Calma!!!!
Como paramos o serviço do SQL Server na instância secundária, não há nenhum impacto para a aplicação, já que ela continua a usar o banco de dados na instância principal, usando o listener do AG.
Agora que o SQL Server não está mais "usando" os arquivos do banco de dados, podemos copiá-lo para as novas pastas. Particularmente, eu prefiro sempre copiar os arquivos os invés de movê-los.
PASSO 4 - Retornar o Banco de Dados para o AG
Depois de copiar todos os arquivos para as novas pastas, reinicialize o SQL Server e conecte-se na instância secundária. O BD AdventureWorks ainda está em modo Restoring.
Execute a view sysaltfiles para validar a nova localização dos arquivos. É possível que sys.databse_files ainda exiba os caminhos antigos do BD, até que um Failover seja executado. Por isso, sysaltfiles é uma opção mais segura neste ponto.
Agora vamos reincluir o BD AdventureWorks2014 no AG, usando a opção "Join to Availability Group".
O arquivo de log está intacto na instância principal. O AlwaysON envia todos os blocos de log desde o último LSN registrado na instância secundária. O log de transação é repetido na réplica secundária, e o banco de dados é incluído no AG.
Aguarde o BD chegar ao modo Synchronized. Pode demorar alguns minutos, então tenha paciência e aguarde o AG Dashboard ficar verdinho...
PASSO 5 - Fazer tudo de novo na instância principal
Quando o banco de dados estiver sincronizado, é hora de repetir todo o processo na instância principal.
Execute o Failover para a réplica secundária que tem os arquivos nas novas pastas.
Agora a instância SQLSERVER01 é a secundária. Basta repetir os passos acima para transferir os arquivos para as novas pastas.
Ao final do processo, execute novamente o Failover, para retornar a instância à situação principal
PASSO 6 - Reativar os jobs de backup de log
Com todos os arquivos nas pastas corretas, e a instância principal novamente nesse papel, é hora de reativar os jobs de backup de log, e comemorar um trabalho bem feito.
Último lembrete - Desative os jobs de backup de log no início do processo
Como mencionado no início deste post, desativar os jobs de backup de log é crucial para que este processo funcione sem problemas. Se você esquecer de desligar o job, pode receber o erro abaixo ao tentar reincluir o BD no AG:
Se essa mensagem aparecer, restaure os backups de log gerados durante o processo e tente incluir novamente o BD no AG.