CONFIGURAR
- 2 servidores Amazon EC2 SQL 2014 em diferentes regiões de disponibilidade.
- Espelhamento síncrono
- S3 para arquivar backups e logs completos à noite
- Agora, para simplificar, backups compactados completos todas as noites
- Tran Logs a cada 15 minutos (faria mais se pudesse reduzir o tempo de execução)
- Backups de Ola Hallengren em execução nos servidores principal e espelho
SLA
Meus termos de SLA a cumprir não têm restrições pesadas neste momento, então (estranho, eu sei!):
- As restaurações "Opps Deleted Something" seriam boas de se ter, mas não tenho uma exigência de entrega rígida sobre isso agora. Eu faço backups de log a cada 15 minutos agora.
- Alta disponibilidade: não é totalmente necessário, o tempo de inatividade de uma hora seria aceitável, se necessário
- Recuperação pontual: posso fornecer, devido aos backups do log de transações, a cada 15 minutos, no entanto, 2 horas seriam aceitáveis por enquanto.
Gargalo de rede
Parece que um dos maiores gargalos é o tubo de rede de aproximadamente 300 mb que parece ficar sobrecarregado pela necessidade de espelhar de forma síncrona para outra instância do EC2. Eu poderia manter muito mais bancos de dados na mesma instância, provavelmente reduzindo os custos se removesse o espelhamento.
Espelhamento ou Abordagem Alternativa Para desempenho com disponibilidade razoável
Estou procurando o melhor valor enquanto ainda ofereço um tempo de atividade razoável. Como estou no padrão SQL, isso significa que o espelhamento assíncrono não é uma opção (estamos executando o sql 2014).
Como avaliei as opções, gostaria de outra perspectiva sobre a recuperação básica de desastres. A sobrecarga de espelhamento parece ser um grande gargalo, mas se eu removê-lo, estou preocupado em como fornecer melhor disponibilidade. Idealmente, eu executaria o espelhamento de forma assíncrona, mas precisaríamos retroceder nas edições do SQL Server e não tenho certeza se essa seria a melhor abordagem
sempre em grupos de alta disponibilidade
Não prosseguir com isso devido ao aumento da complexidade e do custo de licenciamento no momento. Aberto a explorar no futuro, mas neste momento procurando evitar o custo de licenciamento empresarial.
Parece que você pode se beneficiar de um cluster de failover se tudo o que procura é disponibilidade. Você pode executá-los na edição padrão e, se seguir uma rota N+1, poderá ter dois nós para HA e ter um em um site de DR pronto para assumir. Você precisará trabalhar em sua disponibilidade de armazenamento para o lado DR, mas isso é uma outra lata de worms.
Outra opção pode ser o Log Shipping, pois você já está fazendo backups de log a cada minuto. Você pode enviar os logs para seu servidor HA/DR.
Você pode obter mais informações sobre como fazer isso e as implicações para a AWS aqui:
Implementação de Clustering de Failover do Microsoft Windows Server e Grupos de Disponibilidade AlwaysOn do SQL Server na Nuvem AWS
Opção 1
Eu discordo dessa caracterização do AG (a complexidade é um motivo duvidoso para não buscar o que se tornou um recurso razoavelmente padrão no MSSQL) e da alegação de que os custos de licenciamento são um obstáculo.
O fato é que você está em 2014, que encerrou o suporte convencional anos atrás e usando um recurso (espelhamento) que foi obsoleto por mais anos do que isso (embora sabendo que a Microsoft permanecerá por mais uma década).
Se você atualizar para qualquer versão mais recente, obterá Grupos de Disponibilidade Básicos, que acredito honestamente que se encaixam no seu caso de uso. Aqui está o porquê:
Que legal, os Grupos de Disponibilidade Básicos estão disponíveis nas edições padrão após a atualização. Você deve verificar com a Microsoft, mas é provável que também não pague o licenciamento na réplica secundária . Você poderia economizar dinheiro.
Você tem gargalos - AG tem compactação .
Você quer assíncrono? AGs básicos têm.
opção 2
Tudo isso dito, se você estiver em 2014, na AWS, e quiser simplicidade, basta jogar os bancos de dados no RDS com Multi-AZ para alta disponibilidade e encerrar o dia.
Portanto, alcançar a melhor solução com o mínimo de dinheiro passa a ser minha especialidade.
Eu recomendaria usar a ferramenta SQL Compare do software Redgate e executar sincronizações de banco de dados (normalmente concluídas em menos tempo do que o tlog shipping.
Eu faço isso em intervalos de 3 minutos, tenho meu servidor de leitura de banco de dados separado do meu servidor de gravação de banco de dados.
Enfoque o relatório e a recuperação do banco de dados dos servidores de leitura do banco de dados e concentre-se apenas nas gravações no servidor de gravação do banco de dados. (A prática é mais difícil do que a teoria, mas seus clientes vão agradecer).
Use licenças SQL padrão em seu servidor, mas lembre-se da parte mais importante da configuração de sua rede SEMPRE CRIE UMA NIC DEDICADA PARA BACKUPS e sincronizações de banco de dados e diga aos dados que não são de produção para se afastarem. (Lembre-se de que pode ser necessário adicionar uma regra de rota para o NIC de backup)
Sempre valide se o tráfego está fluindo como você pretende. Agora, dependendo do tamanho do seu banco de dados, eu poderia fazer algumas recomendações sobre algumas configurações que acelerariam todas as operações de segundos para MS, mas esperarei que alguém faça essa pergunta