Visão geral das soluções de alta disponibilidade

Esta seção apresenta várias soluções de alta disponibilidade do SQL Server que melhoram a disponibilidade de servidores ou bancos de dados. Uma solução de alta disponibilidade mascara os efeitos de uma falha de hardware ou software e mantém a disponibilidade dos aplicativos, de modo a minimizar o tempo de inatividade percebido pelos usuários.

O SQL Server fornece várias opções para a criação de alta disponibilidade para um servidor ou banco de dados. As opções de alta disponibilidade incluem o seguinte:

• Cluster de failover

  O cluster de failover proporciona suporte de alta disponibilidade para uma instância inteira do SQL Server. Um cluster de failover é uma combinação de um ou mais nós, ou servidores, com dois ou mais discos compartilhados. Aplicativos são instalados em um grupo de clusters do Microsoft Cluster Service (MSCS) conhecido como grupo de recursos. A qualquer momento, cada grupo de recursos pertence a apenas um nó do cluster. O serviço de aplicativo tem um nome virtual que é independente dos nomes de nó e é chamado de nome de instância do cluster de failover. Um aplicativo pode se conectar à instância do cluster de failover fazer referência ao nome dela. O aplicativo não tem precisa saber qual nó hospeda a instância do cluster de failover.

  Uma instância do cluster de failover do SQL Server aparece na rede como se fosse um único computador, mas tem funcionalidade que proporciona failover de um nó para outro se o nó atual se tornar indisponível. Por exemplo, durante uma falha de hardware que não seja o disco, uma falha do sistema operacional ou uma atualização planejada do sistema operacional, você pode configurar uma instância do SQL Server em um nó de um cluster de failover para executar failover em qualquer outro nó do grupo de discos.

  Um cluster de failover não protege contra falhas de disco. Você pode usar o cluster de failover para reduzir tempo de inatividade do sistema e oferecer maior disponibilidade de aplicativos. O cluster de failover tem suporte no SQL Server Enterprise e no SQL Server Developer e, com algumas restrições, no SQL Server Standard. Para obter mais informações sobre cluster de failover, consulte Introdução ao cluster de failover do SQL Server 2008 e Instalando um cluster de failover do SQL Server 2008.

• Espelhamento de banco de dados

  O espelhamento de banco de dados é basicamente uma solução de software para aumentar a disponibilidade do banco de dados, dando suporte a failover quase instantâneo. O espelhamento de banco de dados pode ser usado para manter um único banco de dados de espera, ou banco de dados espelho, para um banco de dados de produção correspondente, que é referido como o banco de dados principal.

  O banco de dados espelho é criado pela restauração de um backup do banco de dados principal sem recuperação. Isso torna o banco de dados espelho inacessível aos clientes. Entretanto, você pode usar isso indiretamente para relatórios, criando um instantâneo do banco de dados no banco de dados espelho. O instantâneo do banco de dados fornece aos clientes um acesso somente leitura aos dados do banco de dados como eles existiam quando o instantâneo foi criado.

  Cada configuração de espelhamento de banco de dados envolve um servidor principal que contém o banco de dados principal e um servidor espelho que contém o banco de dados espelho. O servidor espelho mantém o banco de dados espelho continuamente atualizado com o banco de dados principal.

  O espelhamento de banco de dados é executado com operação síncrona no modo da alta segurança ou operação assíncrona no modo de alto desempenho. No modo de alto desempenho, as transações são confirmadas sem esperar que o servidor espelho grave o log no disco, o que maximiza o desempenho. No modo de alta segurança, uma transação confirmada é confirmada nos dois parceiros, mas com o risco de latência de transação aumentada.

  Em sua configuração mais simples, o espelhamento de banco de dados envolve apenas os servidores principal e espelho. Nessa configuração, se o servidor principal for perdido, o servidor espelho poderá ser usado como um servidor em espera passiva, com possível perda de dados. O modo de alta segurança suporta uma configuração alternativa, o modo de alta segurança com failover automático. Essa configuração envolve uma terceira instância de servidor, conhecida como uma testemunha, que possibilita que o servidor espelho atue como um servidor em espera ativa. O failover do banco de dados principal para o banco de dados espelho normalmente demora vários segundos.

  Desde o SQL Server 2005 Service Pack 1 (SP1), os parceiros e as testemunhas de espelhamento de banco de dados são suportados pelo SQL Server Standard e pelo SQL Server Enterprise. Mas os parceiros devem usar a mesma edição, e o espelhamento de banco de dados assíncrono (modo de alto desempenho) é suportado apenas na SQL Server Edition. As testemunhas também são suportadas pelo SQL Server Workgroup e SQL Server Express.

  Para obter mais informações sobre espelhamento de banco de dados, consulte Espelhamento de banco de dados.

• Envio de logs

  Como o espelhamento de banco de dados, o envio de logs opera no nível do banco de dados. Você pode usar o envio de logs para manter um ou mais bancos de dados de espera passiva para um banco de dados de produção correspondente, que é referido como o banco de dados primário. Os bancos de dados de espera também são referidos como bancos de dados secundários. Cada banco de dados secundário é criado pela restauração de um backup do banco de dados principal sem recuperação ou com espera. A restauração com espera permite usar o banco de dados secundário resultante para relatório limitado.

  Uma configuração de envio de logs inclui um único servidor primário que contém o banco de dados primário, um ou mais servidores secundários que por sua vez têm um banco de dados secundário cada um, e um servidor monitor. Cada servidor secundário atualiza seu banco de dados secundário em intervalos definidos a partir de backups de log do banco de dados primário. O envio de logs envolve um atraso modificável pelo usuário entre o momento em que o servidor primário cria um backup de log do banco de dados primário e quando o servidor secundário restaura o backup do log. Antes que um failover possa ocorrer, um banco de dados deve ser atualizado completamente pela aplicação manual de quaisquer backups de log não restaurados.

  O envio de logs fornece a flexibilidade de suportar vários bancos de dados de espera. Se você precisar de vários bancos de dados de espera, poderá usar o envio de logs independentemente ou como um suplemento para o espelhamento de banco de dados. Quando essas soluções forem usadas conjuntamente, o banco de dados principal atual da configuração de espelhamento de banco de dados também será o banco de dados primário atual da configuração de envio de logs.

  O envio de logs tem suporte nas edições SQL Server Enterprise, Standard e Workgroup. Para obter mais informações sobre envio de logs, consulte Visão geral do envio de log e Administração de envio de logs.

• Replicação

  A replicação usa um modelo de publicação/assinatura. Isso permite que um servidor primário, conhecido como Publicador, distribua os dados para um ou mais servidores secundários, ou Assinantes. A replicação possibilita disponibilidade em tempo real e escalabilidade entre esses servidores. Suporta filtragem para fornecer um subconjunto de dados nos Assinantes e também permite atualizações particionadas. Os assinantes ficam online e disponíveis para relatórios e outras funções, sem recuperação de consultas. O SQL Server oferece três tipos de replicação: instantâneo, transacional e mesclagem. A replicação transacional tem a latência mais baixa e normalmente é usada para alta disponibilidade. Para obter mais informações, consulte Melhorando a escalabilidade e a disponibilidade.

  A replicação é suportada em todas as edições do SQL Server. A publicação da replicação não está disponível com o SQL Server Express ou o SQL Server Compact 3.5 SP1.

  Importante
  Uma estratégia de backup e restauração bem projetada e implementada é importante para qualquer solução de alta disponibilidade. Para obter mais informações, consulte Fazendo backup e restaurando bancos de dados no SQL Server e Fazendo backup e restaurando bancos de dados replicados.

• Bancos de dados compartilhados evolutivos

  O recurso de banco de dados compartilhado evolutivo permite expandir um banco de dados somente leitura criado exclusivamente para relatórios. O banco de dados de relatório deve residir em um conjunto de volumes dedicados somente leitura cuja finalidade principal é hospedar o banco de dados. Usando o hardware de mercadoria para servidores e volumes, você pode expandir um banco de dados de relatório que fornece a mesma exibição de dados de relatório em vários servidores de relatório. Esse recurso também permite um caminho de atualização simples para o banco de dados de relatório. Para obter mais informações, consulte Visão geral de bancos de dados compartilhados evolutivos.