Estou projetando uma solução de expansão para uma empresa globalmente dispersa que possui data centers em todos os continentes. Mais de 10.000 servidores se reportam a um cluster do SQL Server em Los Angeles e também o consultam para executar determinadas tarefas.
A Justificativa/Razão
Para passar de clusters, os problemas com escala vertical e melhorar o desempenho devido à distância global da rede entre muitos nós para o cluster em LA, pensei em usar a replicação transacional em tabelas de núcleo específicas para assinantes (single pub multi sub) espalhado pelo mundo como meu primeiro passo.
Problema a ser resolvido
Se, por qualquer motivo, os dados tiverem mais de X minutos (digamos, 10 minutos), quero que eles acessem o editor (ou outro servidor definido) e os leiam a partir daí. Gostaria de obter dados automaticamente da instância do editor se a preferida não estiver disponível ou desatualizada.
Não tenho certeza de qual é o melhor método para fazer isso, especialmente se os dados estiverem 'obsoletos'. Sei que temos ferramentas de monitoramento de replicação, mas como eu usaria isso para saber se os dados estão obsoletos e forçar as conexões com outro servidor que não esteja?
O motivo é que estou preocupado que certos problemas demorem mais de 10 minutos para serem resolvidos. Durante esse período, os aplicativos críticos, como manutenção e provisionamento automático, obterão dados obsoletos e os negócios poderão ser bastante afetados.
Possíveis soluções e problemas com eles:
Coloque os assinantes/editor em um balanceador de carga 'somente leitura' e faça todas as consultas irem para lá.
Se os servidores de banco de dados estivessem todos no mesmo datacenter, eu provavelmente usaria um balanceador de carga e retiraria os servidores dele, mas isso exigirá intervenção manual e quero que o sistema force todas as leituras para o publicador (ou outro assinante) e ignorar o assinante ao qual eles se conectam.
No entanto, isso não resolveria o problema com dados obsoletos , como se a replicação atrasasse e levasse uma hora para ser corrigida.
Modifique o código para verificar consultas replicadas pendentes e ajuste de acordo
Isso exigiria modificações de código em muitas consultas e os desenvolvedores não teriam o ciclo para fazer isso, além de não parecer uma ideia muito plausível.
Consulte o status da replicação e altere a cadeia de conexão automaticamente se um número X de consultas não for replicado
Eu deveria ser capaz de fazer isso no Powershell, mas a maioria dos servidores é Linux, então eles precisam de um 'aplicativo' que consulte o status de replicação e modifique sua string de conexão se estiver acima de um número X de comandos não replicados.
Obrigada! Tenho 1 ambiente de 2012 e vários ambientes de 2008 nos quais gostaria de implementar isso, com a ideia de movê-los todos para 2012. Enterprise é uma opção.
Outras ponderações
Ter um balanceador de carga em LA para o qual o mundo envia uma pequena consulta muito rápida, para decidir qual servidor escolher, pode funcionar bem, na verdade, pois seria uma pequena consulta e talvez o final solicitante pudesse armazenar em cache essas informações temporariamente.
Parece que eu teria que ter o SQL ou outro mecanismo de banco de dados que é o par 'somente leitura' devolvido ao aplicativo 'esses dados estão obsoletos, vá para outro lugar, de preferência aqui'
A replicação transacional pode ser usada para algo assim, mas seria complicado. No entanto, parece que o que você está fazendo é manter vários caches frontais atualizados.
Isso é complicado, pois um mecanismo de pesquisa limita a escalabilidade. O que funciona melhor é um mecanismo push em que, se ocorrer uma alteração ou alguns dados atenderem a determinados critérios, eles serão enviados para todos os caches; em outros trabalhos, uma estrutura de mensagens.
Se isso for feito no SQL Server, o service broker pode ser mais adequado se o número de nós for alto e as transações baixas. Se as transações forem altas e o número de nós relativamente pequeno, a replicação transacional pode ser mais adequada.
Se o banco de dados for um back-end para um aplicativo que fornece serviços globais de failover, uma solução de aplicativo provavelmente será mais adequada. Por acaso, conheço um cara que implementou um mecanismo de cache semelhante para um grande site de leilões e, em seguida,