Estamos executando um aplicativo de pagamentos (processamento de transações por EFT) que processa grandes volumes de transações 24 horas por dia, 7 dias por semana e está atualmente investigando uma maneira melhor de realizar a replicação de banco de dados em nosso site de recuperação de desastre.
Nossas estratégias atuais e anteriores incluíram o uso do DoubleTake e do Redgate para replicar os dados para um modo de espera quente.
O DoubleTake é a solução suportada pelo fornecedor de software de pagamentos, mas o suporte (DoubleTake's) na África do Sul é muito fraco. Tivemos alguns problemas e simplesmente não conseguimos resolvê-los, então tivemos que desistir do DoubleTake.
Estamos usando o Redgate para ler manualmente os dados do site primário (por meio de consultas) e gravar no site de DR, mas isso é:
- Uma solução ruim
- Acostumando e incomodando o fornecedor do software sempre que tivermos problemas de suporte, pois ele tem uma tendência a interferir no aplicativo de pagamento, que é muito intensivo em termos de banco de dados.
Recentemente, atualizamos todo o sistema para ser executado no SQL 2008 R2 Enterprise, o que significa que provavelmente deveríamos estar usando alguns dos recursos de replicação integrados.
O servidor possui 2 bancos de dados razoavelmente grandes, com uma mistura de tabelas contendo dados transacionais altamente voláteis e dados de configuração bastante estáticos.
A replicação seria feita através de um link WAN para um site físico separado e precisa atingir os seguintes objetivos.
RPO: perda zero - são dados transacionais com impacto financeiro, por isso não podemos perder nada.
RTO: tendendo a zero - o negócio depende da nossa capacidade de processar transações a cada minuto que estamos para baixo estamos perdendo dinheiro
Eu observei algumas das outras perguntas / respostas, mas nenhuma atende exatamente ao nosso caso:
- Estratégia de failover do SQL Server 2008 - Envio de logs ou replicação?
- Como conseguir o seguinte RTO & RPO com log usando apenas o SQL Server?
- Qual é a melhor das duas abordagens conseguir a replicação de banco de dados?
Meu pensamento atual é que devemos usar o espelhamento, mas estou preocupado que para o RPO: 0 precisaremos fazer commits atrasados e isso pode afetar o desempenho do DB principal, o que não é uma opção.
Nosso processo atual de DR é:
- Interrompa o tráfego de entrada para o site principal e permita que todas as transações em andamento sejam concluídas.
- Permitir que a replicação para DR seja concluída.
- Alterar o roteamento de rede para rotear para o site de DR.
- Inicie todos os aplicativos e serviços no site secundário (Idealmente, podemos mudar isso para um stand-by mais quente, em que os aplicativos já estão em execução, mas não estão processando nenhuma transação).
Em outras palavras, o banco de dados de DR precisa, o mais rápido possível, alcançar o primário e estar pronto para ser processado como o novo primário. Então precisaríamos ser capazes de reverter isso quando estivermos prontos para voltar atrás.
Existe uma opção melhor do que o espelhamento (deveríamos estar fazendo log-shipping também) e alguém pode sugerir outras considerações que devemos ter em mente?