Configurando um Log Shipping no SQL Server

DBA e Consultor de Banco de Dados

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

 

 

 

 

2 coment√°rios

  1. Muito bom o post Guuuu, tem o passo a passo mastigadinho ūüėČ Obrigada por compartilhar

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de coment√°rios s√£o processados.