Perguntas sobre remessa de logs do MS SQL Server 2012

1) Se o servidor de banco de dados principal falhar, é possível permitir que os usuários se conectem ao banco de dados secundário para continuar trabalhando com acesso de leitura/gravação?

Você precisa fazer o failover manualmente para o servidor secundário, pois o logshipping não possui um mecanismo integrado para dar suporte ao failover automático.

Após o failover, seu(s) aplicativo(s) (desde que estejam usando ADO.NET ou SQL Native Client) podem aproveitar oFailover Partner=Secondary_server

Brent escreveu em um blog sobre o parceiro de failover:

você não precisa usar o espelhamento de banco de dados para usar o Failover Partner. Esteja você usando espelhamento de banco de dados, replicação, envio de log ou fita adesiva, muito parecido com o texugo de mel, seus aplicativos não se importam. Eles apenas tentarão se conectar ao nome do parceiro de failover sempre que o servidor principal estiver inoperante.

.

2) Uma vez que o servidor primário volta a ficar online, é um processo difícil voltar para o servidor de banco de dados primário?

Tradicionalmente, dependendo do tamanho e número do banco de dados envolvido no envio de logs, pode ou não ser difícil.

O tamanho do banco de dados e a largura de banda da sua rede são muito importantes. Normalmente, você só precisa redefinir o envio de logs. Significado - aponte todos os seus aplicativos para o primário e em segundo plano, faça um backup completo do primário, copie-o para o servidor secundário e restaure-o sem recuperação com backups de log subsequentes.

Para minimizar o tempo de inatividade, você pode usar o "Logshipping reverso" que será uma grande ajuda.

3) Mudar o modelo de Recovery para Full (de simples) terá algum problema?

Sim. Alterar o modelo de recuperação quebra a cadeia de log. Paul Randall fala em sua seção de mitos . Além disso, veja o gráfico abaixo :

4) Meus backups existentes (usando o Symantec Backup Exec) serão afetados ao habilitar o envio de logs e mudar para um modelo de recuperação completa?

Depois de configurar o logshipping, não há necessidade de fazer backups de log adicionais . Na verdade, qualquer backup de log ad hoc interromperá a cadeia de log. Use COPY_ONLYcópias de segurança.

Como mencionei acima, qualquer alteração no modelo de recuperação deve ser seguida por um backup COMPLETO. Esse será o seu backup básico. Quaisquer backups ad hoc (mesmo completos) devem ser feitos com uma opção COPY_ONLY , pois se você estiver contando com backups diferenciais, será um problema se alguém fizer um backup completo ad hoc.

Como observação, sempre documente totalmente, teste, teste e teste + automatize (tanto quanto possível) sua estratégia de recuperação de desastres. Veja o Pôster DR de Paul para mais detalhes .

Kin forneceu alguns bons detalhes, mas apenas para abordar as questões diretamente:

3) Bem, você só pode enviar um banco de dados no modelo de recuperação total, então não tenho certeza de como responder a essa.

1) Se o servidor de banco de dados principal falhar, é possível permitir que os usuários se conectem ao banco de dados secundário para continuar trabalhando com acesso de leitura/gravação?

Sim, você só precisa restaurar o arquivo secundário WITH RECOVERY.

2) Uma vez que o servidor primário volta a ficar online, é um processo difícil voltar para o servidor de banco de dados primário?

Não, você pode apenas reinicializar o processo do novo primário. Seu:

• um backup completo;
• iniciar backups de log (o que você deveria estar fazendo de qualquer maneira, mesmo sem envio de log);
• em seguida, encontre um servidor que sirva como o novo secundário e configure trabalhos semelhantes para executar as restaurações.

3) Mudar o modelo de Recovery para Full (de simples) terá algum problema?

Bem, você só pode enviar um banco de dados no modelo de recuperação completa, então não tenho certeza de como responder.

4) Meus backups existentes (usando o Symantec Backup Exec) serão afetados ao habilitar o envio de logs e mudar para um modelo de recuperação completa?

Difícil responder sem saber exatamente para que você está usando o Symantec. Como observou Kin, você não deseja que essa coisa tente fazer backups de log fora de seu mecanismo de envio de log.