Configurando um Log Shipping no SQL Server

Tempo de leitura: 7 minutos

Olá pessoal,

Espero que estejam todos bem ?

Você já ouviu falar sobre Log Shipping ? Hoje explicaremos como funciona este recurso e como configurá-lo em seu ambiente SQL Server.

Vamos lá??

O que é Log Shipping?

Em resumo, O Log Shipping é um recurso presente no SQL Server desde a versão 2000 que funciona como uma estratégia básica de DR (Disaster Recovery), ou seja, se você deseja ter uma cópia do seu banco de dados em um servidor secundário com uma perca mínima de dados, talvez este cenário possa lhe atender.

Esse recurso trabalha com o princípio de Backup / Restore de peças de backup de log e se inicia por meio de Jobs automatizados que fazem este trabalho.

O desenho abaixo ilustra essa topologia :

Veja que esta arquitetura não é nenhum bicho de 07 cabeças. Basicamente precisamos ter acesso a um diretório local ou compartilhado e durante a configuração o SQL Server já cria os Jobs de Backup, Cópia e Restore, bem legal né? ? Logo demonstraremos na prática.

Nesta tecnologia, o banco de dados de produção é mantido como uma cópia exata em um servidor apartado, e esse banco de dados secundário é alimentado continuamente a partir do banco de dados primário de tempos em tempos.

Desta forma, caso não haja acesso ao banco de dados primário ou ocorra algum tipo de desastre, o nosso banco de dados secundário pode ser utilizado como banco de dados principal.

Vamos abordar as principais Vantagens e Desvantagens desta solução :

Vantagens :

• Funciona como uma solução mais simples de recuperação em caso de desastres e também pode ser utilizada para múltiplas finalidades. Ex.: Estratégias de migração, Teste de restore do backup de log, Restore D-1, etc).
• É uma feature muito barata em termos de custo. A partir do SQL Server 2008, está disponível em todas as versões, exceto na versão Express.
• É considerada uma funcionalidade simples de instalar e fácil de manter.
• No banco de dados secundário é possível deixar a base em modo Standby, ou seja, é permitido acessar o banco em modo somente leitura sem quaisquer interferências manuais.
• Um erro de usuário (Como por exemplo, um UPDATE SEM WHERE) pode ser contornado utilizando peças de backups de log mais antigas.

Desvantagens :

• O Log Shipping não possui nenhum mecanismo de Failover Automático. Portanto, caso seja necessário subir a base no ambiente secundário, o processo deve ser realizado manualmente.
• O banco ficará indisponível até o administrador subir a base no ambiente secundário.
• É possível que haja perca de dados (condicionado ao tempo do último restore de Log ou caso a base primária esteja corrompida).
• Em modo Standby, enquanto estiver aplicando os Logs na base secundária, não é possível realizar consultas.

Para maiores informações, segue o link da documentação oficial:

https://docs.microsoft.com/pt-br/sql/database-engine/log-shipping/about-log-shipping-sql-server?view=sql-server-ver15

Pré-requisitos:

• Pelo fato de estarmos trabalhando diretamente com Backup de Log nesta solução, o modelo de recuperação da base candidata a receber o Log shipping deverá estar obrigatoriamente definido como Full ou Bulk-Logged no banco de dados primário.
• Deverá existir uma pasta compartilhada no servidor primário que o secundário possa acessar. Os backups de log serão mantidos nesta pasta compartilhada e o servidor secundário fará a cópia desses arquivos e irá restaura-los de tempos em tempos.
• O usuário do banco para realizar a configuração desta funcionalidade deverá ser membro do grupo sysadmin.

---

Laboratório :

Para essa demonstração estamos utilizando o SQL Server 2017 Developer instalado em duas máquinas (Lembrando que esta Feature está disponível em todas as edições exceto na Express):

• SQL01
• SQL02

Primeiramente, vamos realizar as configurações no servidor primário (SQL01).

• Precisamos garantir que a base que iremos configurar o Log Shipping esteja no modelo de recuperação (FULL ou Bulk-Logged) . Neste exemplo utilizaremos o modelo FULL na base AdventureWorks2016.

• Após colocar a base em modo FULL, vamos realizar um Backup FULL da base de dados desejada.

• Em sequência, vamos fazer um Backup de LOG,

• Após realizar os passos iniciais, vamos conectar na instância do nosso servidor secundário (SQL02). Chegando lá, vamos restaurar as bases que acabamos de fazer o Backup, no entanto, utilizaremos o parâmetro NORECOVERY.

• Vamos repetir agora o mesmo processo de restore na instância (SQL02), no entanto, desta vez restaurando o Backup de LOG.

• Agora voltaremos para a instância (SQL01), clique com o botão direito no Object Explorer sobre a base AdventureWorks2016 e selecione a opção propriedades.

• Selecione a opção Transaction Log Shipping, marque a opção “Enable this as a primary database in log shipping configuration.” e depois clique em “Backup Settings”.

• Ao clicar no botão Backup Settings, temos algumas configurações importantes para realizar no nosso Log Shipping.

Na primeira opção: Network Path to Backup Folder, iremos informar uma pasta compartilhada para salvar as peças de LOG. Neste exemplo informamos o caminho: \\SQL01\Backup. Na segunda opção: if the backup folder is located on the primary server. type a local path to the folder, informaremos o caminho local da nossa pasta de backup, neste exemplo utilizamos o caminho: D:\Backup.

Em sequência, temos as configurações de retenção do nosso Backup de LOG, por padrão a opção Delete files older than vem definida para apagar os arquivos a cada 72 horas. A opção : Alert if no backup occurs within vem previamente configurada com o Threshold de alertar se o Backup dos Logs transacionais falharem a cada 01 hora.

Essas configurações são personalizáveis de acordo com a preferência de cada usuário.

Ainda nesta tela, outra forte recomendação é marcar em Set Compress Backup para comprimir o Backup. Essas definições ajudam a diminuir o tamanho das peças de LOG no disco.

Após marcar e configurar todas as definições de Backup, clique em OK.

• Agora vamos realizar as configurações de restore do nosso Log Shipping, Em Secondary server instances and databases, clique em Add.

• Antes de começar clique em Connect.

• Informe a instância secundária o usuário e senha e clique em Connect.

• Feita a conexão, deixe marcado a última opção No, the secondary database is initialized. As outras opções vão muito de acordo com a preferência do usuário, mas em resumo elas permitem que seja iniciado o processo de Backup/Restore das bases do Log Shipping automaticamente ou a partir de um Backup já pré-existente no servidor secundário.

• Continuando, na aba Copy Files, Informe um diretório Local do servidor Secundário (SQL02) na qual o Log Shipping copiará as peças de Backup de Log para restaurar. Neste exemplo, definimos o caminho : D:\Backup. A seta vermelha na imagem indica que o SQL irá configurar o Job a cada 15 minutos para copiar os arquivos para o servidor Secundário.

Na próxima aba Restore TransactionLog faremos a definição do estado de recuperação da nossa base no nosso ambiente de destino (SQL02). A seta vermelha na imagem indica que o SQL irá configurar o Job a cada 15 minutos para restaurar os arquivos no servidor Secundário.

Obs.: Se desejar deixar a base somente leitura do outro lado, é neste passo do processo que é feita essa configuração.

• Clique em OK. As definições deverão ficar semelhantes a imagem abaixo.

Ao aplicar as configurações, o SQL começará o processo de configuração dos Jobs em ambos os servidores e emitirá uma mensagem de sucesso.

Volte para a tela do Management Studio e faça um refresh no SQL Server Agent no servidor primário e veja que agora temos alguns Jobs criados.

O SQL Server também criou alguns Jobs no servidor Secundário.

• Faça um Start  manual dos Jobs LSBackup (SQL01), LSCopy e LSRestore (SQL02).

            

 

• Pronto ! Existe uma dashboard tanto do servidor primário, quanto do secundário que é possível consultar rapidamente o status do nosso Log Shipping. para exibir a dashboard clique com o botão direto na instância. Depois clique em Reports > Standard Reports > Transaction Log Shipping Status.

Se tudo estiver certo e parametrizado de acordo com as suas preferências o status ficará como Good!

É isso ai pessoal, espero que tenham gostado!!

Se gostou ou teve alguma dúvida deixem nos comentários

Um grande abraço a todos!!!

Gustavo Larocca

Consultor SQL Server