Melhorando a disponibilidade
A replicação pode ser usada para replicar dados para um servidor de espera, o qual fornece disponibilidade aumentada no caso de falta de energia planejada ou não planejada. A replicação deve ser usada para fornecer uma espera passiva se os dados requeridos na espera forem um subconjunto dos dados requeridos no servidor primário. Considere também o seguinte.
Se seu aplicativo requerer dados em diversos sites para aumentar a escalabilidade e a disponibilidade, consulte Melhorando a escalabilidade e a disponibilidade.
Se o seu aplicativo precisa de um banco de dados inteiro para ficar disponível em um servidor de espera, use o espelhamento de banco de dados em vez da replicação. O espelhamento de banco de dados é mais eficiente se todo o banco de dados precisar ser sincronizado, e não houver necessidade de usar o servidor secundário para consultas. Para obter mais informações, consulte Administração de espelhamento de banco de dados.
O diagrama a seguir exibe um servidor primário e um único servidor de espera, com um subconjunto dos dados no servidor primário disponível no servidor secundário.
.gif "Replicando dados para um servidor em espera")
.gif "Observação") Observação |
|---|
A replicação não fornece um mecanismo para fazer failover de um servidor para outro servidor de espera. Qualquer aplicativo que acessar um determinado servidor deve ser programado para usar outro servidor no caso do primeiro servidor não estar disponível. |
Exemplo Adventure Works Cycles
A Adventure Works Cycles é uma empresa de fabricação fictícia utilizada para demonstrar conceitos e cenários de banco de dados. Para obter mais informações, consulte Bancos de dados de exemplo AdventureWorks.
O Adventure Works Cycles tem diversos servidores em todas as suas instalações industriais que coletam dados sobre defeitos nas linhas de produção. Eles usam a replicação para proporcionar disponibilidade para estes servidores. Eles têm código gravado código para redirecionar consultas a um servidor de espera passiva durante interrupções planejadas e não planejadas.
Requisitos comuns deste cenário
Aplicativos que usam replicação para disponibilidade normalmente têm os requisitos a seguir, os quais uma solução de replicação apropriada deve encaminhar:
O sistema deve manter a consistência transacional.
O sistema deveria ter baixa latência: as atualizações em um servidor devem alcançar os outros servidores rapidamente.
O sistema deve ter alta taxa de transferência: deve controlar a replicação de um grande número de transações.
O processamento de replicação deve requerer sobrecarga mínima.
Os dados exigidos em um servidor secundário podem ser um subconjunto de dados disponíveis no servidor primário (consulte o primeiro diagrama acima).
O tipo de replicação a ser usado nesse cenário
O MicrosoftSQL Server usa uma metáfora da indústria de publicação para descrever os componentes do sistema de replicação. Os componentes incluem o Publicador, Assinantes, publicações e artigos, além de assinaturas.
No diagrama acima, o servidor primário é o Publicador. Alguns ou todos os dados do servidor primário estão incluídos na publicação, com cada tabela de dados sendo um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). O servidor de espera é um Assinante para a publicação, recebendo o esquema e os dados como uma assinatura. Para obter mais informações sobre os componentes do sistema, consulte Visão geral do modelo de publicação de replicação.
O SQL Server oferece diferentes tipos de replicação para diferentes requisitos de aplicativo: replicação de instantâneo, replicação transacional e replicação de mesclagem. O cenário é implementado da melhor forma com a replicação transacional, a qual fica bem ajustada para controlar os requisitos descritos na seção anterior. Para obter mais informações sobre a replicação transacional, consulte Visão geral da replicação transacionaleComo a replicação transacional funciona.
Pelo design, a replicação transacional aborda os requisitos principais deste cenário:
Consistência transacional
Baixa latência
Alta taxa de transferência
Sobrecarga mínima
A opção primária a ser considerada para este cenário é a filtragem. A replicação transacional permite que você filtre as colunas e linhas, de modo que as tabelas dos Assinantes contenham somente os dados requeridos por seu aplicativo. Para obter mais informações, consulte Filtrando dados publicados.
Etapas para implementar este cenário
Para implementar este cenário, você deve primeiro criar uma publicação e assinaturas para depois inicializar cada assinatura. Clique nos links abaixo para obter mais informações sobre cada etapa:
Após a inicialização da assinatura, e com os dados fluindo entre o Publicador e os Assinantes, talvez seja necessário consultar os seguintes tópicos para obter informações sobre as tarefas comuns de administração e monitoramento: