Como: Hot Standby SQL Server em outro datacenter?

4

Para o nosso aplicativo SaaS, eu quero ter um sistema em vigor para uma falha ampla do datacenter.

No centro de dados principal, temos dois servidores configurados com o MSSQL Database Mirroring (sincronizado). Isso nos fornece uma solução de alta disponibilidade suficientemente boa para falhas de servidor. Se um servidor morre, ele falha automaticamente (com a ajuda de um terceiro servidor testemunha) em segundos.

Eu estava pensando em usar MSSQL Replication ou Log Shipping do banco de dados espelhado para manter um servidor warm standby em outro datacenter - observe isso será transatlântico e, portanto, altos pings ~ 100ms. Eu acho que eu poderia usar algum DNS failover serviço com um curto (5 min) TTL que irá direcionar o tráfego para o segundo datacenter no caso de uma falha do primeiro.

Perguntas:

Posso usar replicação ou remessa de log de um banco de dados espelhado (funcionando perfeitamente se houver falha na outra instância)?

Qual é o preferido - replicação ou envio de log ou outra coisa?

É possível que o banco de dados de failover aceite gravações?

Ou haveria uma possível perda de dados do failover e, portanto, seria melhor ter essa somente leitura até que voltássemos ao datacenter principal?

Obrigado!

EDITAR: alguém tem alguma ideia para uma configuração de servidor MSSQL de reserva?

    
por Marcus 27.04.2011 / 19:50

3 respostas

2

O envio de log ou replicação funcionará com o espelhamento de banco de dados - qual deles você deve usar depende dos seus requisitos, mas a replicação pode ser mais difícil de configurar e gerenciar do que o envio de log. replicação que você realmente precisa. Os links abaixo fornecem mais informações sobre como configurar cada um deles.

É possível que o banco de dados de failover aceite gravações?

Observação: suponho que você queira dizer que uma vez que o failover ocorreu, e não durante a operação normal do dia-a-dia.

Certamente, com o envio de logs, é possível que o banco de dados de failover no DC secundário aceite gravações. Se você puder obter e aplicar um backup final do banco de dados em execução no DC primário (para minimizar a perda de dados e manter a cadeia de logs intacta), você terá uma cópia atualizada do banco de dados em execução, < em> no entanto não se esqueça que você está correndo exposto nesta situação. Os backups de log regulares podem ajudar, mas se sua meta não for perder nenhuma transação, isso não pode ser garantido quando você estiver executando somente o envio de logs secundário no outro DC. Pode ser melhor apenas executar o aplicativo em um estado somente leitura até que seu HA seja configurado novamente. A partir desse estado, você pode copiar os backups de log para o datacenter principal e reinicializar o espelhamento.

Links úteis:

link - Envio de log e espelhamento de banco de dados link - Replicação e espelhamento de banco de dados

Nota: para obter acesso de gravação a um banco de dados de registro, você precisa RESTORE DATBASE dbname WITH RECOVERY Depois, pode ser escrito como o mestre, mas você não pode restaurar nenhum log adicional depois de fazer isso. Você precisa restaurar um novo backup completo para que o registro esteja funcionando novamente. Mas, pelo menos, permitiria que você fizesse failover.

    
por 02.05.2011 / 20:39
1

Estou nos estágios de planejamento de algo semelhante, em vez de em todo o mundo, nos EUA. Estamos planejando ir com o envio de log. Parece (pelo menos para mim) ser mais robusto do que a replicação (com a qual trabalhei), mais fácil de administrar e mais fácil de configurar (pelo menos para mim).

Aqui está uma lista rápida dos prós / contras . O maior problema para nós é o failover automático, como o espelhamento.

    
por 02.05.2011 / 17:55
0

Geralmente você está em um bom caminho, mas considere o seguinte:

  1. cache de DNS e
  2. certos servidores que não honram o TTL

Estas são as razões pelas quais isso fornece um aumento limitado de HA. O cache de até 24h não é incomum. Eu sugiro que essa é mais uma abordagem de recuperação de desastres, já que é algo que você só quer fazer caso seu site principal seja afetado por um período mais longo, já que o failback também leva 24 horas para se propagar para determinados clientes. / p>     

por 27.04.2011 / 20:59