QUANDO colocar o plano de contingência em ação em caso de falha do servidor principal?

Question

Temos um servidor de banco de dados de produção do SQL Server que envia backups de log transacionais para dois servidores em espera. O plano de recuperação de desastres já foi concluído: temos um procedimento bem documentado e pessoas treinadas para colocar o servidor em espera em produção e iniciar a replicação, habilitando os trabalhos, etc., com o mínimo de tempo de inatividade.

O problema que está ganhando discussão não é o plano de contingência em si, mas o DECISION para colocar o servidor em espera em produção e perder, no pior dos casos, 12 minutos de informação (o backup do log de transações é executado a cada 10 minutos e é muito rápido para ser copiado para os outros servidores).

A decisão pode ser difícil porque podemos perder tempo tentando identificar o problema. Por outro lado, o problema poderia ser simples de resolver e poderíamos colocar o servidor de volta em produção sem usar os outros servidores.

Entendemos que a situação se tornará muito estressante no caso de uma falha do sistema, e achamos que, nessas situações, é melhor ter um procedimento padrão e um mínimo de decisões.

Então, nós temos um dilema. É melhor apenas mudar de servidor quando algo está errado com o servidor principal, ou melhor tentar identificar e resolver o problema no servidor principal? O que vocês acham disso?

    

Answer 1

Um framework que você pode querer usar é duas janelas de tempo para decidir isso no momento do problema. O final da primeira janela de tempo será um limite suave e o segundo será um limite rígido de quando mudar.

O limite suave será o primeiro ponto de corte. Se você estiver tentando resolver o problema, mas não estiver mais perto de resolvê-lo do que quando começou, mudaria no limite suave. Se você acha que está chegando perto de resolver o problema no limite suave, você continuará até o limite máximo. Assim, o limite flexível seria 5 minutos, por exemplo, e o limite rígido seria 8 minutos, a partir do início da tentativa de corrigir o problema. No limite rígido, você troca de nada.

O comprimento das janelas que você usa vai ter que decidir por si mesmo. Você também precisa descobrir se deseja incluir o tempo necessário antes de começar a analisar o problema.

Você também pode, é claro, improvisar e fazer o que achar melhor na época - é bem provável que não planeje cada pequeno detalhe.

    

Answer 2

Tudo depende de custos. Quanto custa tentar corrigir o problema por X minutos / horas? É menor que o custo de mudar para um servidor de backup, perder alguma data e, eventualmente, voltar para o servidor de produção principal?

Quando o custo de tentar consertar exceder o custo de troca, a decisão é tomada, mudar. Até que você tenha um controle sobre os custos, como você pode definir um "desastre"?