Melhorando a escalabilidade e a disponibilidade
Em muitos aplicativos, é essencial fornecer maior disponibilidade e maior escalabilidade de leitura; a replicação pode ser usada como uma peça chave de uma solução para o fornecimento desses dois recursos. Para alguns aplicativos, a meta poderia ser melhorar a disponibilidade ou a escalabilidade por meio da replicação. Se você precisar somente encaminhar uma destas áreas, considere um dos seguintes cenários:
Os diagramas a seguir ilustram dois aplicativos que se beneficiam do uso da replicação para aumentar a disponibilidade e a escalabilidade. Nos dois casos, os três bancos de dados dos diagramas formam pares: contêm esquema e dados idênticos. A atividade de gravação destes bancos de dados deve ser particionada: se o banco de dados contiver um catálogo de produtos, você poderia por exemplo, direcionar as atualizações para o primeiro banco de dados para os nomes de produtos que iniciam com A-I, o segundo banco de dados para J-R, e o terceiro banco de dados para S-Z. As atualizações são replicadas em seguida para os outros bancos de dados.
O primeiro diagrama ilustra uma configuração na qual cada aplicativo e servidor de Web usa os dados de um determinado servidor em cache. As leituras e atualizações de um determinado usuário, fluem para um servidor de aplicativo específico e em seguida para um servidor em cache específico. Como o servidor de aplicativo atualiza o cache diretamente, não é necessário um servidor de origem central. As atualizações em cada cache são propagadas para os outros caches.
.gif "Usando a replicação para dimensionar a atividade de leitura")
O segundo diagrama exibe três servidores dispersos geograficamente com os dados fluindo entre todos os três, permitindo que cada um dos servidores dê suporte as solicitações de leitura e melhorem a disponibilidade.
.gif "Replicação ponto-a-ponto para locais dispersos")
Exemplo de 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 AdventureWorks2008R2.
OCiclos da Adventure Works tem um muitos escritórios em todo o mundo, inclusive locais em Los Angeles, Londres e Taipei. As informações sobre pedidos de clientes são reunidas em cada local e em seguida replicadas para outros locais.
As informações sobre pedidos podem ser lidas em qualquer um dos locais; por isso, se o escritório de Londres estiver com atividades intensas de leitura , os aplicativos internos podem distribuir um pouco dessa atividade para os outros dois escritórios.
Se um servidor estiver desativado para manutenção no escritório de Londres, por exemplo, os pedidos ainda podem ser recuperados em outro local e os funcionários do escritório de Londres podem continuar a ler e inserir dados. Após o servidor de Londres voltar on-line, as alterações recebidas enquanto ele estava desativado serão propagadas para o servidor de Londres, de modo que ele seja atualizado.
Requisitos comuns deste cenário
Os aplicativos que usam replicação para escalabilidade e disponibilidade normalmente têm os requisitos a seguir, os quais devem ser encaminhados por uma solução de replicação apropriada:
O sistema deve permitir que as alterações sejam feitas em qualquer servidor e replicadas para todos os outros servidores.
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.
O tipo de replicação a ser usado nesse cenário
O Microsoft SQL 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.
Nos diagramas anteriores, todos os servidores de cache são os Publicadores e Assinantes. Todos os dados do banco de dados replicado em cada servidor estão incluídos na publicação, com cada tabela de dados como um artigo (os artigos também podem ser outros objetos de banco de dados, como os procedimentos armazenados). Cada servidor assina as publicações de outros servidores, recebendo o esquema e 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. Este cenário é implementado da melhor forma com a replicação transacional ponto a ponto, a qual fica bem ajustada para controlar os requisitos descritos na seção anterior. Para obter mais informações sobre a replicação ponto a ponto, consulte Replicação de transacional ponto a ponto.
.gif "Observação") Observação |
|---|
Se o aplicativo exigir que as modificações em uma determinada linha sejam feitas em mais de um nó ao mesmo tempo, poderão ocorrer conflitos de dados. Neste caso, use a replicação de mesclagem que é mais viável para controlar conflitos. Para obter mais informações sobre replicação de mesclagem, consulte Visão geral da replicação de mesclagem.. |
Pelo design, a replicação transacional aborda os requisitos principais deste cenário:
As alterações podem ser feitas em qualquer servidor
Consistência transacional
Baixa latência
Alta taxa de transferência
Sobrecarga mínima
A opção ponto a ponto para replicação transacional permite que os servidores publiquem e inscrevam os mesmos dados. Todos os nós em uma topologia ponto a ponto são do mesmo nível: cada nó publica e inscreve o mesmo esquema e dados. As alterações feitas (inserções, atualizações, e exclui) podem ser em todos os nós e em seguida replicadas para todos os outros nós.
Etapas para implementar este cenário
Para implementar este cenário, você deve primeiro criar publicações e assinaturas e depois inicializar cada assinatura. Para obter mais informações, consulte:
SQL Server Management Studio: Como configurar replicação transacional ponto a ponto (SQL Server Management Studio)
Programação de Transact-SQL replicação: Como configurar a replicação transacional ponto a ponto (Programação Transact-SQL de replicação)
Após a inicialização da assinatura, e com os dados fluindo entre os pares, pode ser necessário consultar os tópicos que seguem para obter informações sobre as tarefas comuns de administração e monitoramento: