Qual é a melhor maneira de obter o RPO de zero e menor RTO possível (menos de 15 minutos) com o SQL 2008 R2?

2

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 é:

  1. Uma solução ruim
  2. 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:

  1. Estratégia de failover do SQL Server 2008 - Envio de logs ou replicação?
  2. Como conseguir o seguinte RTO & RPO com log usando apenas o SQL Server?
  3. 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 é:

  1. Interrompa o tráfego de entrada para o site principal e permita que todas as transações em andamento sejam concluídas.
  2. Permitir que a replicação para DR seja concluída.
  3. Alterar o roteamento de rede para rotear para o site de DR.
  4. 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?

    
por Adrian Hope-Bailie 28.06.2012 / 15:34

2 respostas

3

Você está fazendo as perguntas certas e sabe lidar com o problema, mas a barra está bem alta. Você está batendo em uma parede à procura de algo que possa ser evasivo com a tecnologia que foi desenvolvida há cinco anos. E você já testou dois fornecedores em campo e eles não estão à altura do desafio.

Planeje o futuro. O que você tem agora é o que é. Você pode tentar reprojetar a tecnologia existente ou mais antiga, mas passar para a próxima versão pode ser uma opção que vale a pena investigar.

Eu suspeito que as falhas descritas com o espelhamento de 2008 sejam o motivo pelo qual a Microsoft introduziu o recurso AlwaysOn no SQL Server 2012. O espelhamento de 2008 é realmente muito bom, a menos que você tenha uma conexão de alta latência ao espelho e esteja usando o modo de alta segurança. Se você tem um alto volume de transações e está lidando com dinheiro, alta segurança ou alto desempenho não é uma decisão fácil.

Minha previsão é que os provedores chamados de "nuvem" serão, na verdade, um ajuste natural para muitos cenários de DR. Eles têm tecnologia e conhecimento que a maioria das empresas não pode pagar e estão pressionando o que é possível.

Espelhamento de banco de dados assíncrono (modo de alto desempenho)
link

Apresentando o SQL Server AlwaysOn
link

Perguntas frequentes do AlwaysOn para o SQL Server 2012
link

    
por 28.06.2012 / 16:37
0

Você também pode ir para a replicação no nível de armazenamento. Assim, você pode obter replicação no aplicativo Camada - seu banco de dados e no nível de armazenamento.

Como este aplicativo é crítico com RPO baixo e RTO, é possível procurar um espelho síncrono para que as atualizações sejam feitas assim que houver um delta no lado primário.

A nuvem é uma boa opção. Ele oferece grande agilidade, velocidade, modelo de pagamento conforme o uso, economias de escala, alcance global, etc., mas como isso é requisito de pagamento e bancário, você deve escolher nuvem privada para obter melhor segurança. Por outro lado, a nuvem privada aumentará significativamente o seu custo operacional e o custo geral.

Então, você pode considerar uma técnica de replicação no nível de software e infraestrutura.

    
por 24.12.2016 / 15:01