Bom, hoje, irei postar aqui como criar um processo de alta disponibilidade utilizando o log shipping.
O QUE É O LOG SHIPPING?
O Log Shipping é um recurso para proporcionar alta disponibilidade de databases. Esse recurso acompanha o SQL Server desde a versão 2000. O conceito por trás do Log Shipping é bastente simples, consiste apenas nos backups dos logs de transações e restores desses backups de log no servidor de destino, este por sua vez, ficará em STANDBY aguardando o momento para ser utilizado, em caso de falha do servidor principal.
– Pode ser configurado em todas as verções do SQL a partir do SQL 2000.
– Permiter disponibilizar um ambiente de alta disponibilidade com baixo custo.
– Fácil de configurar e manter.
– Se bem implementado, fornecerá boa confiança dos serviço de redundância
DESVANTAGENS
– O Log Shipping não realiza um failover automático, ou seja, em caso de falha do servidor principal, existirá a intervenção do DBA para tornar o servidor STANDBY em Online.
– Existirá perda de informações dos usuários das aplicações, a perda dependerá da periodicidade em que são replicados os logs de transações.
PASSOS PARA CONFIGURAR O LOG SHIPPING:
– Garanta um Hardware compatível com a carga que será aplicada em caso de o servidor STANDBY ser ativado como online.
– Crie ou replique os logins existentes no servidor principal para o STANDBY.
– Configure o database com o recovery model como FULL.(alter database [database_name] set recovery full)
– Crie uma rotina de backup FULL + LOGS ou FULL + DIFERENCIAL + LOGS no servidor principal.
– Copie esses backups em um local compartilhado existente no servidor STANDBY.
– Crie uma rotina de restores dos backups criados.
Para os backups e restores estou disponibilizando 2 scripts criados para a realização customizada desses procedimentos.
Como boa prática de política de backup e restore, irei sugerir a realização de backups na seguinte ordem.
1 – Realização de um backup full diário em horário definido na sua política de backup.
2 – Realização de backups diferenciais intercalados durante o dia.
3 – Realização de backups de logs em intervá-los curtos, exemplo: 5 minutos.
Os scripts de backup e restore são:
Backup
Restore
Como recomendação, segue sugestão de comandos de backup e restore utilizando os scripts postados, após a criação das procedures existentes nos scripts, basta criar jobs para os tipo de backups utilizando os parâmetros abaixo:
BACKUP FULL
exec pr_backup @database=’teste’, — Nome do databsae
@localbackup =’\SERVIDORCOMPARTILHAMENTO’, — Local do backup, ex: c:backups’
@tipoBackup=1
— Tipo de backup: 1 para FULL, 2 para DIFF, 3 para LOG
BACKUP DIFERENCIAL
exec pr_backup @database=’teste’, — Nome do databsae
@localbackup =’\SERVIDORCOMPARTILHAMENTO’, — Local do backup, ex: c:backups’
@tipoBackup=2
— Tipo de backup: 1 para FULL, 2 para DIFF, 3 para LOG
BACKUP DE LOG
exec pr_backup @database=’teste’, — Nome do databsae
@localbackup =’\SERVIDORCOMPARTILHAMENTO’, — Local do backup, ex: c:backups’
@tipoBackup=3 — Tipo de backup: 1 para FULL, 2 para DIFF, 3 para LOG
Comandos para a criação dos jobs de restore no servidor standby
RESTORE FULL
exec pr_restore @database=’teste’, — Nome do database a ser restaurado.
@localrestore =’\SERVIDORCOMPARTILHAMENTO’, — Local dos arquivos de backup a serem restaurados, ex: c:backups’
@tiporestore=1 — Tipo de restore: 1 para FULL, 2 para DIFF, 3 para LOG
RESTORE DIFERENCIAL
exec pr_restore @database=’teste’, — Nome do database a ser restaurado.
@localrestore =’\SERVIDORCOMPARTILHAMENTO’, — Local dos arquivos de backup a serem restaurados, ex: c:backups’
@tiporestore=2
RESTORE DE LOG
exec pr_restore @database=’teste’, — Nome do database a ser restaurado.
@localrestore =’\SERVIDORCOMPARTILHAMENTO’, — Local dos arquivos de backup a serem restaurados, ex: c:backups’
@tiporestore=3
NOTA IMPORTANTE:
A rotina de restore realiza o restore do último backup full, do último diferencial e restaura os backups de logs na sequência, ou seja, do primeiro ao último.
Em resumo, se no restore for usado o parâmetro @tiporestore=1 ou @tiporestore=2 , serão restaurados os últimos full e diferencial,
respectivamente.
Caso o parâmetro seja @tiporestore=3 , a cada execução será verificada a existência de novos backups de logs no local especificado no parâmetro @localrestore, então, para esse job basta deixar ele executando de tempos em tempos, se o backup de log existir será restaurado.
Como mencionado anteriormente, basta criar os jobs de backups e apontar os jobs para serem armazenados em um compartilhamento existente no servidor STANDBY e depois criar os jobs de restore no servidor STANDBY.
A rotina de restore é inteligente o suficiente para restaurar os backups na ordem correta, bastando que, primeiramente, seja realizado um restore full, depois um difirencial se existir, e os de log durante toda a existência do servidor STANDBY.
Basta rodar a procedure de restore com o parâmetro @tiporestore=3 (Log), e pronto, se os arquivos de backups estiverem disponíveis, os restores serão executados automaticamente sem reaplicar os que já foram restaurados.
Espero que essa rotina seja útil para alguém.
Qualquer dúvida ou sugestão, estou à disposição.
Até a próxima…
Abr, Emanuel Peixoto.
