Temos um cliente distribuído geograficamente em comunidades remotas, com conectividade de rede/internet um tanto incerta entre cada um dos locais físicos. Há uma única localização central e 52 localizações de satélite.
Normalmente, nosso aplicativo é implantado como uma solução central onde há apenas um único banco de dados e todos os locais se conectam a um único banco de dados. Os dados em si são particionados por uma coluna de localização na maioria das tabelas (alguns dados são centralizados) e o aplicativo opera de forma que o toque nos dados em um local físico não toque nos dados em outro local físico, incluindo os dados centralizados (pelo menos, temos certeza de que não - se acontecer, provavelmente é um bug). Nosso cliente gostaria de fazer relatórios centralizados (que normalmente oferecemos suporte) e sincronização de várias tabelas de configuração centralizadas em toda a empresa (o mesmo, porque normalmente há apenas uma cópia das tabelas).
Cada local tem seu próprio centro de dados e é licenciado para SQL Server 2008 R2 Enterprise.
O objetivo é implantar nosso aplicativo de forma que a conectividade de rede/internet interrompida não impeça as operações locais de leitura/gravação, pois nosso aplicativo é de missão crítica.
Meu primeiro pensamento foi usar uma topologia ponto a ponto gigante que replicasse todos os objetos do banco de dados. Não consegui encontrar nenhuma documentação ou referência de nenhuma instalação dimensionada tanto usando esse método, então não tenho ideia se é tecnicamente viável e, em caso afirmativo, qual hardware será necessário. Isso funcionaria com um banco de dados de distribuição centralizado (para facilitar o gerenciamento)? Isso é mesmo uma boa ideia? Como as alterações do esquema do banco de dados serão implantadas? A manutenção do índice gera uma grande sobrecarga de rede?
Há também a opção de criar uma solução roll-our-own, que imagino envolver o envio de cópias separadas do banco de dados (cada local não central conteria apenas sua parte particionada dos dados) para o local central e, em seguida, usando uma ferramenta de fusão (que já temos) para criar um banco de dados de relatórios. As alterações na tabela de configuração seriam enviadas por algum outro mecanismo, possivelmente replicação de mesclagem, possivelmente uma solução homebrew.
Considerei e testei o uso da replicação de mesclagem em todo o banco de dados, mas exigimos muitas alterações/redesenho/etc do banco de dados e do aplicativo. para fazer isso funcionar corretamente, então já descartei isso devido a restrições de tempo. (Pensamentos sobre isso?)
O que estou procurando aqui é alguma orientação de pessoas com mais experiência. Obviamente, o planejamento para isso é fundamental . Estou no caminho certo? Existem outras opções? (URLT?)
Para apenas 52 sites de clientes, a replicação funcionará bem. Considere sua cópia local como o site 'mestre' e faça com que o aplicativo funcione apenas na cópia local, sempre. Use a replicação para agregar os dados ao repositório central para relatórios agregados. As operações de manutenção de índice normalmente não geram tráfego de replicação. Gerenciar alterações de esquema por meio de migrações de implantação de aplicativos , ou seja. têm scripts de atualização para cada versão lançada.
À medida que o número de sites aumenta, o gerenciamento da replicação se torna cada vez mais difícil. Além disso, o licenciamento levaria à implantação do Express na periferia. E a atualização do SQL Server é uma dor absoluta quando a replicação está envolvida, pois a ordem de atualização dos componentes (editor, distribuidor, assinante) é crítica, mas difícil de coordenar com muitos sites. As implantações que conheço com mais de 1.500 sites usam movimentação de dados personalizada com base no Service Broker. Consulte Usando o Service Broker em vez da replicação para obter um exemplo. Já vi até designers que usam o Service Broker para enviar para a periferia novos bits (alterações de aplicativos) que, por sua vez, implantam, quando ativados, migrações e alterações de esquema, fazendo com que toda a implantação seja operada a partir do centro.
Por que existe um banco de dados? Parece que faria mais sentido cada local manter uma cópia do esquema do banco de dados localmente para suas próprias operações de leitura/gravação e sua própria fatia dos dados, e a parte de relatório dos dados poderia ser replicada centralmente. Existe algum motivo pelo qual o site A teria que disponibilizar seus dados não relacionados ao relatório para o site B ou vice-versa? Os dados do relatório podem ser distribuídos de volta para o local central usando uma variedade de técnicas, incluindo roll-your-own (tenho alguma experiência lá se você quiser mais informações). Ou, se os dados do relatório tiverem a maior parte do tamanho dos dados, você pode usar apenas envio de log ou backups copy_only, mantendo uma cópia de todo o banco de dados, com relatórios centrais usando exibições ou outras técnicas em vários bancos de dados quando eles são restaurados.
Mudanças de esquema são fáceis. Lidei bastante com isso no meu antigo emprego, onde tínhamos ~ 500 bancos de dados com esquema idêntico. A chave para implantar mudanças é garantir que as mudanças sejam compatíveis com versões anteriores. Se você pode construir um script que não interrompa um banco de dados, você pode escrever um loop que implanta essas alterações em n bancos de dados/servidores/ambientes. Usamos o Red Gate para criar nossos scripts de implantação com base em comparações entre beta e produção e, em seguida, um desenvolvimento doméstico
sp_msforeachdbem cada instância (porque você não pode confiar no integrado - veja aqui e aqui ). Com uma boa mistura de controle de origem também.Nesse caso, não tenho certeza de como a manutenção do índice causaria sobrecarga na rede. A manutenção do índice só deve ser feita na fonte e não "reproduzida" se puder ser evitada.