De acordo com as informações de alta disponibilidade localizadas aqui , a única opção para a edição da Web é o envio de log. (A replicação também não é uma opção, embora eu sugira apenas que, em casos limitados, ela seja muito intrusiva em relação ao esquema de banco de dados do aplicativo.)
Dito isso, o envio de logs pode ser perfeitamente ótimo se você puder tolerar alguns minutos de perda de dados.
"Automático", no entanto, é arriscado. Algumas coisas para ter em mente: O failover de envio de log não é automático. O "Monitoring Server" apenas monitora, ele não executa nenhuma ação quando há um problema. Algo ou alguém terá que decidir que o servidor original está inativo e que os bancos de dados no servidor de failover devem ser retirados da recuperação. Você poderia escrever um programa para fazer isso, com o risco que isso traz, ou confiar em humanos se você tiver monitoramento 24x7, o que torna uma janela de tempo de inatividade de cinco minutos muito desconfortável.
Quaisquer trabalhos que você tenha (sejam eles 'admin', como backups e reindexação ou algo específico do seu aplicativo) devem existir em ambos os servidores, mas eles não devem ser executados no failover até que você precise deles. Se você tiver um grande número de tarefas, você precisará de algum tipo de maneira automatizada para ativá-las / desativá-las. Houve um artigo sobre isso recentemente, não consigo encontrá-lo agora, mas você deve ser capaz de encontrar algo para lhe dar algumas ideias de googling.
Idem para pacotes, servidores vinculados e qualquer outro material no nível do servidor. Esses objetos devem estar sempre em ambos os servidores e você não pode fazer "log ship" alterações desses objetos do servidor primário para o servidor failvoer. Com configurações de servidor complicadas, manter as coisas idênticas em dois servidores pode ser uma tarefa que requer tempo significativo ou algum software.
Você desejará ter certeza de que os nomes de login, senhas e SIDs correspondam aos dois servidores. Caso contrário, seu aplicativo da Web talvez não consiga acessar o banco de dados no servidor de failover quando for ativado. Isso é mais fácil se você estiver usando segurança de domínio para o login do seu aplicativo, porque não precisa se preocupar com SIDs. Se você estiver usando a segurança do SQL Server, precisa ser mais cuidadoso.
O servidor principal e o servidor de failover terão nomes de host diferentes. Você precisará de uma maneira de alterar a (s) fonte (s) de dados de seu aplicativo da Web do SQLServer A para o SQLServer B. Usamos nomes DNS C, para que possamos atualizar uma entrada no DNS em vez de atualizar arquivos no (s) servidor (es) .
Naturalmente, você quer testar isso antes de realmente precisar.
Se você tiver uma interrupção agendada para os patches do Windows uma vez ao mês, deverá integrar um failover manual no processo para corrigir os servidores. Isso minimizará o tempo de inatividade do aplicativo, testará o processo de failover e fornecerá uma simulação realista para quem faz o trabalho.
Provavelmente, você irá falhar mais vezes para corrigir janelas e outras coisas similares do que o failover devido a uma emergência real.
O failover manual testa seu processo, para que você saiba se funcionará durante uma emergência real. Isso também força você a configurar o log shipping de volta na outra direção, o que pode levar uma quantidade significativa de tempo se você tiver um banco de dados grande.