A alta disponibilidade para banco de dados já é uma realidade em diversas empresas. Seja ela de pequeno, médio ou grande porte, é cada vez mais comum o interesse em implantar uma redundância para o ambiente de banco de dados para que se garanta o pleno funcionamento dos mesmos em caso de necessidade.
Como um recurso padrão, grande parte das empresas precisam dos dados apenas no horário comercial, o que facilita e barateia os custos quando se pretende buscar uma redundância para o ambiente de banco de dados. Por outro lado, também nos deparamos com empresas que vivem outra realidade e precisam de seus dados 24 horas por dia, sete dias por semana, durante todo o ano.
Diante dessa variação, constatamos que cada empresa que busca a alta disponibilidade se encaixa em um determinado cenário e assim poderá optar pelas diferentes opções que o SQL Server disponibiliza para montar o cenário mais adequado às suas necessidades como, por exemplo, log shipping, espelhamento, AlwaysOn Availability Groups, failover cluster, etc.
Para que se obtenha sucesso e que tudo funcione como o esperado, é necessário um profissional habilitado para garantir a implantação e manutenção desta estrutura, o DBA. Depois de implantado, este ambiente demanda uma série de cuidados para que tudo prossiga sem problemas.
Com base nisso, vamos detalhar neste artigo recursos de alta disponibilidade do SQL Server 2012, como Log shipping, Espelhamento, AlwaysOn Availability Groups, Failover Cluster e Replicação Ponto a Ponto. Neste processo, daremos maior destaque às principais características de cada uma destas tecnologias que são fatores preponderantes no momento de definição do recurso de alta disponibilidade a ser adotado.
Log Shipping
O Log Shipping é um recurso de alta disponibilidade que está presente no SQL Server há muitos anos. Em versões anteriores do SQL Server ele já era usado, porém apenas na versão 2000 a Microsoft incluiu o utilitário de configuração para o Log Shipping.
Escolher o Log Shipping para garantir a alta disponibilidade é uma opção segura quando pensamos na proteção dos dados, pois os backups de log são enviados para um banco secundário, que tem como principal objetivo servir de backup, podendo ser colocado online em tempo razoável em caso de necessidade. A partir desta característica, uma possibilidade interessante é montar um servidor de relatórios utilizando o banco secundário em modo Stand By.
O Log Shipping funciona utilizando um mecanismo que realiza backups de logs que são restaurados no banco secundário em intervalos de tempo pré-determinados, o que o mantém sempre atualizado. A desvantagem desta tecnologia é que a cada restauração, as conexões com o banco secundário são desconectadas, pois para realizar a restauração do log de transações o banco deve estar em modo “nonrecovered”, o que impede que ele seja acessado.
Podemos imaginar uma situação onde o log de transações deve ser restaurado em um espaço de tempo muito curto, por exemplo, em um intervalo de 15 minutos. Neste caso, usar o log shipping para alimentar um servidor de relatórios não seria o ideal, visto que as sessões seriam desconectadas em um espaço de tempo também muito curto. Com isso, os usuários que estariam acessando o banco naquele momento ficariam insatisfeitos, pois teriam que se conectar novamente.
Porém, ainda assim é uma boa solução para proteção dos dados, já que garante que o banco secundário detenha dados bem próximos dos mais atuais, podendo este ser atualizado mesmo que esteja geograficamente distante do servidor onde reside o banco de dados primário. Por sua vez, quando se necessita de Failover, o Log Shipping já não é tão indicado, pois não realiza o failover do banco automaticamente.
Além disso, como o Log Shipping é configurado em cada banco individualmente, deve ser levado em consideração o trabalho administrativo em instâncias com dezenas ou centenas de bases de dados antes de se optar por realizar uma implantação de alta disponibilidade com esta tecnologia.
At ...
