Alta disponibilidade com Log Shipping - Revista SQL Magazine 100

A importância de se prevenir quedas em ambientes de produção, evitando paradas e descontentamentos dos mais variados tipos faz com que, cada vez mais, se invista em recursos de alta disponibilidade visando contingência e continuidade do negócio. Se tratando de banco de dados, cabe ao administrador propor alternativas eficazes para que exista transparência no acesso aos dados por parte dos sistemas existentes na empresa em caso de problemas no servidor, permitindo que o trabalho prossiga regularmente.

Com este propósito, falaremos sobre um recurso de alta disponibilidade existente no Microsoft SQL Server, chamado Log Shipping, passando por conceitos e terminologias, analisando sua aplicabilidade e, através de exemplos, mostrar seu funcionamento na prática.

O Log Shipping faz parte de uma das quatro tecnologias de alta disponibilidade existentes no SQL Server, que inclui também Database Mirroring, Failover Clustering e Peer-to-peer replication. Através dele, uma base de dados se mantém atualizada no servidor secundário e servirá de contingência caso haja problemas no servidor principal. Diferente do Mirroring, para o Log Shipping não existe failover automático. Em caso de problemas no servidor primário, somente será possível a realização de um failover manual para que a base replicada se torne a instância principal.

Outro aspecto que podemos citar que diferencia o Log Shipping do Database Mirroring, é que os logs de transação gerados a partir do servidor principal não são enviados continuamente ao servidor secundário, pois estas remessas de log são configuradas através de Jobs do SQL Server Agent, permitindo que se definam agendamentos tanto para o backup dos logs, quanto para o restore na base secundária.

No momento em que são gerados os backups de log, se estiver sendo usada a edição Enterprise do SQL Server 2008 ou a Standard do SQL Server 2008 R2, é possível habilitar a compactação dos arquivos, pensando na redução de seu tamanho físico, para que haja diminuição do tráfego na rede no momento em que estes forem enviados ao servidor secundário. Neste caso, aumentará a utilização de CPU no servidor principal durante o processo de compactação dos arquivos. Com relação a essa questão, qualquer versão do SQL Server poderá descompactar esses arquivos, porém, se o secundário se tornar principal, não será possível compactar os logs de transação se a edição utilizada não for a Enterprise do 2008 ou a Standard do 2008 R2, sendo possivelmente necessário o acréscimo de espaço em disco para os novos backups (tendo em vista que estes não estarão mais compactados).

A proposta de adoção da tecnologia de Log Shipping pode ainda ser associada à existência de uma base para geração de consultas para relatórios, por exemplo, isolando estes processamentos do ambiente de produção, com o objetivo de evitar possíveis problemas de desempenho. Além disso, ainda sobre sua finalidade, é comum combinar a utilização de Log Shipping com outras opções de alta disponibilidade, tais como Clustering e Database Mirroring, de modo que exista mais de uma base atualizada, garantindo contingência em um ambiente de produção."