sync de banco de dados entre servidores no SQL 2008R2

Question

como estamos no processo de expansão dos negócios, agora estamos avançando para adicionar mais datacenters, agora temos um requisito em que precisamos sincronizar o banco de dados de produção com outros servidores de datacenter, com poucos requisitos. Aqui está a configuração atual do servidor da seguinte forma (2 servidores)

• Servidor: Microsoft Windows Server 2008 R2.
• .net Framework: Microsoft .net framework 3.5
• IIS 7.5

Cenários

• Como sincronizamos o banco de dados de produção com outro servidor. Existe alguma automação, método de replicação para executar a ação, ou seja, sempre que um registro ou alguma transação acontecer, ele deve ser sincronizado com outro servidor. Eu estou querendo saber como as pessoas conseguem eficientemente.
• Podemos replicar ou sincronizar apenas tabelas que mencionamos, ou seja, em nosso Esquema de BD, há uma tabela, que podemos ignorar a operação de sincronização.

• Existe alguma sugestão para melhorar a operação de sincronização ou como outras pessoas lidam com esse cenário? Existe algum trabalho em torno? Eu ouvi falar de espelhamento, mas não sei como implementar neste cenário.

  eu apperciate qualquer um nos guia para construir uma história de sucesso ..

Answer 1

você pode fazer a replicação por assinatura, espelhamento ou envio de logs (ou, em muitos casos, vários tipos de replicação - por exemplo, espelhamento e assinaturas para disponibilidade e particionamento). A questão é qual é o objetivo por trás da replicação. Além disso, por que você não está migrando coisas desse tipo para amazon, azure ou qualquer número de soluções baseadas em nuvem em que todos esses tipos de problemas sejam resolvidos, bem como problemas que talvez você não tenha pensado (backup, balanceamento de carga geográfica - apenas fora do topo da minha cabeça)

Para meu dinheiro, a nuvem é onde você começa a procurar respostas para soluções de distribuição geográfica.

    

Answer 2

Como lidamos com esse cenário é que usamos a replicação ponto a ponto (PTP). Isso nos permite não apenas sincronizar bancos de dados em dois datacenters separados, mas também temos a flexibilidade de sincronizar apenas as tabelas com as quais nos importamos, ou seja, dados do usuário e não o registro de dados.

A sincronização PTP de desempenho sábio é relativamente instantânea para nós, o que obviamente dependerá do vínculo entre o data center e a quantidade de tráfego existente entre os sites. O PTP também nos dá a capacidade de fazer com que o nosso servidor atue independentemente um do outro, se necessário.

Uma das maiores dicas da experiência é configurar as chaves primárias apropriadamente. Se você usar o guid como sua chave primária, não haverá problema, mas incrementar as colunas de identidade se torna complicado, pois cada banco de dados age independentemente um do outro. Portanto, é necessário garantir que uma chave gerada pela coluna de identidade no servidor 1 não seja gerada no servidor 2. Caso contrário, a replicação encontrará um erro porque você não poderá inserir esse novo registro devido à violação da chave primária.

Isso pode ser resolvido definindo a semente de identidade de cada tabela como um valor diferente. Por exemplo, o servidor 1 terá a origem de identidade iniciada em 1 e o servidor 2 terá a origem de identidade iniciada em 1.000.000. A outra opção seria reduzir ligeiramente a semente de identidade e incrementar pelo número de servidores em seu esquema de replicação de PTP. Portanto, no exemplo de 2 servidores, o servidor 1 começará na semente 1 e o servidor 2 começará na semente 2 com ambos incrementados por um valor de 2.

    

Answer 3

Como pano de fundo, o Google usa o "Teorema do CAP de Brewer" - basicamente, diz que você não pode ter seu bolo replicável altamente disponível e consistente com a transação e comê-lo.

Existem muitas maneiras de fazer isso, e eu não acho que você tenha nos contado o suficiente para dar conselhos prescritivos, mas basicamente você pode fazer isso no aplicativo, no banco de dados ou no nível da VM.

Adicionar replicação ao aplicativo costuma ser difícil, por isso evite isso, se possível.

Se você optar por fazer isso no banco de dados:

A replicação transacional é ótima para a comprovação de cópias somente leitura em tempo real de seu banco de dados ativo. Ele permite que você selecione tabelas individuais, subconjuntos de todas as colunas e até mesmo filtragem de linha na publicação, resiliência a problemas de conectividade, vários assinantes e uma boa interface de gerenciamento. Existem alguns truques que você pode usar para habilitar o recurso de gravação limitada nos inscritos, mas eles são complicados.

A replicação de mesclagem fornece réplicas de vários mestres, mas possui requisitos de esquema onerosos, tem conflitos como parte de seu design e tem problemas de escalabilidade e confiabilidade em minha experiência. Evite.

Replicação ponto a ponto. Isso eu nunca usei, mas é construído sobre replicação transacional, por isso deve ser OK, mas a recomendação strong é permitir apenas atualizações em um único nó para evitar

O espelhamento de banco de dados é aplicável apenas em situações bem conectadas, ou seja, no mesmo data center. Na implementação padrão, se um membro do espelho falhar, as transações param para ambos. O espelhamento de transações síncronas também atrasa seu servidor de produção. Evite.

Sua pergunta não diz por que você deseja replicação - seja para desempenho ou tolerância a falhas ou o quê, mas eu recomendo que você considere se, por exemplo, uma instância do SQL Azure atenderá às suas necessidades.

Boa sorte.

    

Answer 4

A replicação de banco de dados não melhora muito o desempenho, pois os dois servidores ainda precisam processar e armazenar todas as alterações.

Pode valer a pena olhar para o particionamento federado em servidores geograficamente separados, mas esse não é um assunto para iniciantes.

Um espelho de banco de dados não é gravável.

    

Answer 5

Você pode querer consultar o SQL Data Compare da Red Gate - que permitiria sincronizar os dados entre os bancos de dados.

Eles também têm um produto SQL Compare que apenas sincroniza as alterações do esquema.