Início / dba / Perguntas / 14056
Accepted
Daniel James Bryars
Asked: 2012-02-29 06:57:56 +0800 CST

Este procedimento para Failover para Logshipped secundário e Failback novamente está correto?

  • 772

Tenho um banco de dados primário em Amsterdã (AMDB) e um secundário em Londres (LNDB). Quero fazer o failover de AMDB para LNDB e vice-versa, sem precisar fazer outro backup completo (porque o banco de dados é muito grande).

De acordo com Alteração de funções entre servidores primários e secundários e Failover para um secundário de envio de logs, tudo isso parece possível. Eu nunca fiz isso antes e vou fazê-lo na produção neste fim de semana. (Farei alguns testes em bancos de dados não prod antes.)

Minha pergunta: devo fazer mais alguma coisa além da documentação da Microsoft para garantir o sucesso? (Gostaria de saber se mais alguém tem alguns truques ou etapas extras que eles executam.) Espero uma resposta tranquilizadora, como "Sim, isso funciona sempre que fazemos isso na produção e é legal", mas também ficarei muito feliz com "Não, não faça isso, certifique-se de fazer x/y/ e z."

Editar: não recomendo que eu use o espelhamento como resposta a esta pergunta - sim, é uma ótima ideia, mas não funciona para nós devido aos custos de licenciamento. Usamos a edição padrão (e isso suporta apenas espelhamento no modo síncrono ). Gostaria de saber se alguém seguiu as etapas da documentação do MS em prod ou se existe uma alternativa melhor que um dba "experiente" usaria.

sql-server-2008-r2 transaction-log

2 respostas

  1. Para a funcionalidade integrada de failover/failback, escolha Espelhamento de banco de dados em vez de envio de logs:

    http://technet.microsoft.com/library/bb934127.aspx

    Você pode seguir um processo para fazer isso com o envio de logs, mas são necessárias etapas manuais. O espelhamento é a melhor escolha.

    • 2
  2. Best Answer

    Para responder à minha própria pergunta - Sim: o processo descrito nos links acima funcionou bem.

    Descobri que fazer um log final precisava de acesso exclusivo ao banco de dados e não poderia fazer backup do log final se o banco de dados estivesse no modo de usuário único. Isso foi um problema na produção porque "todo tipo" de coisas estava se conectando ao banco de dados. O script que adotei abaixo funcionou para mim - ele faz um embaralhamento rápido entre o modo de usuário único e multiusuário antes do backup (observe o uso de "Com Standby" para tornar o banco de dados consultável e pronto para mais logs no failback.)

    --BACKUP TAIL    
ALTER DATABASE [MyDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE [MyDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE [MyDatabase] SET MULTI_USER
BACKUP LOG [MyDatabase] TO DISK = 'C:\TransactionLogShare\TailLog2.trn' WITH STANDBY = 'C:\Standby\myDatabase.bak'

    Em seguida, colocá-lo online do outro lado foi bastante direto:

    --RESTORE TAILLOG
ALTER DATABASE [Liquid] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
RESTORE LOG [Liquid_Logshipped] FROM DISK = 'C:\TransactionLogs\taillog.trn' 
ALTER DATABASE [Liquid_Logshipped] SET MULTI_USER
    • 1

relate perguntas