Para adicionar mais sobre replicação transacional:
- ele usa um trabalho de leitor de log do SQL Agent para coletar transações confirmadas do log de transações do banco de dados de publicação. Isso significa que o log não pode ser limpo até que os registros de log tenham sido lidos. Se a periodicidade do agente de leitura de log for alterada, seu log poderá aumentar inesperadamente. O agente de leitura de log também pode causar contenção no log de transações em sistemas OLTP de alto volume, dependendo do seu subsistema de E / S, é claro. A replicação
- não garante zero perda de dados, pois há latência envolvida na leitura dos registros de log e na sua passagem pelo distribuidor para o (s) assinante (s). Para zero perda de dados, observe o espelhamento de banco de dados síncrono ou a replicação SAN síncrona A replicação ponto a ponto
- é uma boa maneira de expandir uma carga de trabalho de consulta e também pode adicionar alguma redundância aos seus dados
- você precisa fazer um design de esquema cuidadoso com peer-to-peer para evitar colisões causadas por alterações semelhantes em nós diferentes. Não use identidades particionadas para isso. Use uma chave substituta composta (por exemplo, identificador de nó + bigint)
- com peer-to-peer, pode ser difícil adicionar redundância extra aos vários nós na topologia. O editor pode ser espelhado, o assinante pode ser espelhado (razoavelmente fácil em 2008, não tão facilmente em 2005), mas o distribuidor não pode. Deve ser agrupado para adicionar redundância.
Apenas alguns pensamentos. Você também pode fazer o checkout do whitepaper sobre o espelhamento + repl que escrevi no ano passado, em link
Edit: ok - é hora do almoço e eu tenho mais alguns para adicionar:
- replicação ponto-a-ponto: em 2005, se você quiser alterar a topologia (adicionar ou remover nós), terá que desativar a topologia inteira. Em 2008 você não precisa. A replicação ponto a ponto
- não tem detecção de conflitos até 2008, mas mesmo assim a resolução de conflitos é bastante falsa - o nó com a ID mais alta (chamada de ID de origem do peer) ganha - talvez não o que você deseja.
- replicação ponto a ponto: todos os nós veem todas as alterações dos outros nós. Isso significa que, em uma topologia de três vias, por exemplo, Seattle, Londres, Tóquio - se Seattle cair, Londres e Tóquio continuarão. Se Tóquio, em seguida, desce e Seattle fica on-line, ele receberá todas as atualizações de Londres de Londres e todas as atualizações de Tóquio que Londres conhece, de Londres. Bem legal.
- não há nenhuma forma de detecção de falha ou failover automático com replicação. Talvez olhe para espelhamento em vez disso. Eu acho que você poderia usar alguma forma de NLB.
Ao escolher qualquer tipo de solução de HA (bom momento, já que estou ensinando uma classe HA para DBAs internos da Microsoft atualmente), é necessário começar com a análise de requisitos antes de avaliar as tecnologias. É um pouco difícil dar recomendações sem conhecer todas as suas necessidades.
Eu fiz um blog sobre perguntas que você deve se fazer ao criar uma estratégia de HA: veja link
Edite novamente:
- Um exemplo de seu uso: vários servidores na camada de dados com balanceamento de carga de nível médio. Ponto-a-ponto permite que todos os nós mantenham (eventualmente) em sincronia.
- Problema desagradável: se um usuário é roteado para o nó 1 e faz uma transação, quanto tempo antes que os dados sejam replicados para os outros nós, como a latência de repl pode variar? Se o usuário se conectar ao serviço novamente, para qual nó a roteará? O mesmo nó de antes ou que passou tempo suficiente para poder rotear com segurança para qualquer nó e garantir que a transação anterior que ela fez foi replicada para todos os nós?
ok - não há mais edições! : -)