Olá PessoALL!

Neste artigo vamos mostrar como configurar o log shipping no SQL Server. Apenas relembrando, o log shipping é uma solução de disaster recovery que possibilita o envio de backups transacionais de uma instância para outra (possivelmente localizada em outro server). Esses backups são feitos pelo SQL Server Agent e são enviados para uma pasta compartilhada. Na instância secundária, o SQL Server Agent terá dois jobs: um fará a cópia dos arquivos de backup para uma outra pasta e o outro job será responsável pelo restore. Feito o restore, será possível escolher entre deixar o banco acessível (read-only) ou inacessível (restoring). Mais informações sobre o log shipping em: http://<https://docs.microsoft.com/en-us/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-ver15

Para habilitar o log shipping, inicialmente devemos configurar o banco que desejamos aplicar o procedimento como recovery model full ou bulk-logged e criar um compartilhamento para os backups. Feito isso, habilitaremos a configuração de log shipping no próprio banco de dados:

Após habilitarmos a feature, devemos fazer as configurações de backup, ou seja, configurar qual é a pasta que receberá os backups (deve ser uma pasta compartilhada com permissão de leitura e escrita para o usuário de serviço). Aqui, configuramos uma pasta local.

Também, devemos configurar uma retenção para os backups transacionais, que dependerá da sua regra de retenção e deverá configurar um alerta para notificar, caso não ocorra backup dentro do tempo definido. Para configuração do job, você poderá escolher um nome para o mesmo e deverá configurar a frequência dos backups. Configurei os backups transacionais a cada 30 min.

Pronto! As configurações de backup estão finalizadas. Nosso próximo passo é configurar o servidor secundário. Para isso, basta adicioná-lo na tela de configuração do log shipping e fazer as configurações.

Na primeira aba Initialize Secondary Database, precisará definir se irá fazer um restore a partir de um novo backup full, se irá utilizar um já existente ou se o banco secundário já foi inicializado.

Neste exemplo, escolhemos a opção de gerar um novo backup e iniciar o log shipping a partir dele. No botão restore options, você poderá escolher o diretório para seu(s) arquivo(s) .mdf e .ldf. Caso não escolha os diretórios, ele irá pegar o valor default de diretório configurado na instância.

Na aba Copy Files, você deverá escolher o diretório destino para os backups copiados. O job de restore irá utilizar esse diretório para restaurar os arquivos na instância secundária.

Também deverá configurar a retenção desses backups copiados e configurar a frequência dos jobs de cópia. Neste exemplo, iremos ler os dados frequentemente na instância secundária para evitar gargalos no servidor primário e vamos configurar a cópia dois minutos após a realização do backup, para ter tempo de terminar o backup e em seguida o mesmo ser copiado.

Na última aba Restore Transaction Log você poderá definir o status do seu banco secundário, sendo no recovery mode, o banco ficará em restoring e no standby mode, o banco ficará disponível para somente leitura. Deixaremos configurado como Standby.

Também configure se você deseja um delay no restore e um alerta caso não ocorra nenhum restore dentro do período configurado.

Por último, configure a frequência do job de restore. Aqui configuramos dois minutos após o job de cópia, ou seja, a cada 34 min, para ter tempo do job de cópia conseguir copiar o arquivo de backup transacional. Claro que, esses tempos serão relativos para cada ambiente e para cada necessidade. Cada caso é um caso!

Realizadas essas configurações, você poderá configurar uma terceira instância que funcionará como um monitor do log shipping. Neste exemplo não configuraremos essa opção.

Feita a confirmação, você verá o status da configuração, se ocorreu algum erro ou se tudo funcionou corretamente.

Na instância secundária, você poderá controlar se o job de restore está funcionando ou não através da seguinte query:

select last_copied_file,last_restored_file,last_restored_date
from msdb.dbo.log_shipping_monitor_secondary

Essa query retornará qual foi o último restore aplicado no banco secundário.

Esperamos que esse post seja útil para você.
Ficou com dúvida? Entre em contato com a gente. Abraço!

 

Por Oberdan Schaider