Aguarde a replicação transacional em ADO.NET ou TSQL

Question

Meu aplicativo da web usa o ADO.NET contra o SQL Server 2008. O banco de dados as gravações acontecem contra um banco de dados (editor), mas as leituras são equilibradas no banco de dados primário e secundário (assinante). Usamos a replicação transacional interna do SQL Server para manter o secundário atualizado. Na maioria das vezes, o par de segundos de latência não é um problema.

No entanto, eu tenho um caso em que gostaria de bloquear até que a transação seja cometida no local secundário. Bloquear por alguns segundos está ok, mas retornar uma página obsoleta ao usuário não é. Existe alguma maneira no ADO.NET ou TSQL para especificar que eu quero esperar que a replicação seja concluída? Ou posso, no editor, verificar o status de replicação da transação sem conectar manualmente ao servidor secundário.

Editar] 99,9% das vezes, os dados do assinante são "frescos o suficiente". Mas há uma operação que a invalida. Não sei ler o editor sempre com a chance de se tornar inválido. Se eu não consigo resolver esse problema sob replicação transacional, você pode sugerir uma arquitetura alternativa?

Answer 1

Não existe essa solução para o SQL Server, mas aqui está como eu trabalhei em outros ambientes.

Use três seqüências de conexão separadas em seu aplicativo e escolha a certa com base nas necessidades de sua consulta:

• REAL em tempo real - aponta diretamente para o servidor mestre. Todas as gravações vão para esta string de conexão e apenas as leituras mais críticas da missão vão aqui.
• Quase real -horário - pontos para um conjunto de assinantes equilibrados de carga. Nenhuma gravação vá aqui, apenas lê. Usado para a grande maioria das leituras do OLTP.
• Relatórios atrasados-No seu ambiente agora, ele apontará para o mesmo pool de assinantes equilibrados de carga, mas na estrada você pode usar uma tecnologia como o envio de log para ter um pool de servidores 8-24 horas para trás. Isso escala muito bem, mas os dados estão muito atrasados. É ótimo para relatar, pesquisar, histórico de longo prazo e outras necessidades não reais.

Se você projetar seu aplicativo para usar essas 3 seqüências de conexão desde o início, a escala é muito mais fácil, especialmente no caso de estar enfrentando.

Answer 2

Você está descrevendo uma situação de espelhamento síncrono. A replicação não pode, por definição, apoiar seu requisito. Replicação devo Aguarde uma transação que se comprometa antes de lê -lo no log e entregá -lo ao distribuidor e a partir daí para o assinante, o que significa que a replicação por definição tem uma janela de oportunidade para que os dados estejam fora de sincronia.

Se você tiver um requisito uma operação para ler a cópia autoritativa dos dados, deve tomar essa decissão no cliente e garantir que você leia no editor nesse caso.

Enquanto você pode, em tridões, validar se uma determinada transação foi distribuída ao assinante ou não, você não deve basear seu design nele. A replicação transacional não garante a latência, por design, para que você não possa confiar no modo de operação do 'dia perfeito'.