Scripts de pré-postagem aprimorados para instantâneo consistente de banco de dados

O serviço de Backup do Azure já fornece uma estrutura de script de pré-postagem para obter consistência de aplicativo em VMs Linux usando o Backup do Azure. Esse processo envolve invocar um pré-script (para desativar os aplicativos) antes de tirar o instantâneo dos discos e chamar o post-script (comandos para descongelar os aplicativos) depois que o instantâneo for concluído para retornar os aplicativos ao modo normal.

A criação, depuração e manutenção de scripts pré/pós pode ser um desafio. Para remover essa complexidade, o Backup do Azure fornece experiência pré/pós-script simplificada para bancos de dados de marca de seleção para obter instantâneo consistente do aplicativo com o mínimo de sobrecarga.

A nova estrutura aprimorada de script pré-post tem os seguintes benefícios principais:

• Esses scripts de pré-postagem são instalados diretamente nas VMs do Azure junto com a extensão de backup, o que ajuda a eliminar a criação e baixá-los de um local externo.
• Você pode visualizar a definição e o conteúdo de scripts de pré-postagem no GitHub, até mesmo enviar sugestões e alterações. Você pode até mesmo enviar sugestões e alterações via GitHub, que serão triadas e adicionadas para beneficiar a comunidade em geral.
• Você pode até adicionar novos scripts de pré-postagem para outros bancos de dados via GitHub, que serão triados e endereçados para beneficiar a comunidade em geral.
• A estrutura robusta é eficiente para lidar com cenários, como falha de execução pré-script ou falhas. Em qualquer caso, o post-script é executado automaticamente para reverter todas as alterações feitas no pré-script.
• A estrutura também fornece um canal de mensagens para ferramentas externas buscarem atualizações e prepararem seu próprio plano de ação em qualquer mensagem/evento.

Fluxo de soluções

Matriz de suporte

A seguinte lista de bases de dados é abrangida pelo quadro reforçado:

• Oracle (Geralmente disponível) - Link para matriz de suporte
• MySQL (Pré-visualização)

Pré-requisitos

Você só precisa modificar um arquivo de configuração, workload.conf em /etc/azure, para fornecer detalhes de conexão. Isso permite que o Backup do Azure se conecte ao aplicativo relevante e execute pré e pós-scripts. O arquivo de configuração tem os seguintes parâmetros.

[workload]
# valid values are mysql, oracle
workload_name =
command_path = 
linux_user =
credString = 
ipc_folder = 
timeout =

A tabela a seguir descreve os parâmetros:

A experiência geral para usar a estrutura de script pré-post aprimorada é a seguinte:

• Preparar o ambiente de banco de dados
• Editar o arquivo de configuração
• Acionar o backup da VM
• Restaure VMs ou discos/arquivos do ponto de recuperação consistente do aplicativo, conforme necessário.

Crie uma estratégia de backup de banco de dados

Usando snapshots em vez de streaming

Normalmente, os backups de streaming (como completos, diferenciais ou incrementais) e os logs são usados pelos administradores de banco de dados em sua estratégia de backup. A seguir estão alguns dos principais pivôs no design.

• Desempenho e custo: um log + completo diário seria o mais rápido durante a restauração, mas envolve um custo significativo. A inclusão do tipo de backup de streaming diferencial/incremental reduz os custos, mas pode afetar o desempenho da restauração. Mas os snapshots oferecem a melhor combinação de desempenho e custo. Como os snapshots são inerentemente incrementais, eles têm menos impacto no desempenho durante o backup, são restaurados rapidamente e também economizam custos.
• Impacto no banco de dados/infraestrutura: o desempenho de um backup de streaming depende das IOPS de armazenamento subjacentes e da largura de banda de rede disponível quando o fluxo é direcionado para um local remoto. Os snapshots não têm essa dependência e a demanda por IOPS e largura de banda de rede é significativamente reduzida.
• Reutilização: os comandos para acionar diferentes tipos de backup de streaming são diferentes para cada banco de dados. Portanto, os scripts não podem ser facilmente reutilizados. Além disso, se você estiver usando diferentes tipos de backup, certifique-se de avaliar a cadeia de dependência para manter o ciclo de vida. Para snapshots, é fácil escrever scripts, pois não há cadeia de dependência.
• Retenção a longo prazo: os backups completos são sempre benéficos para a retenção a longo prazo0, uma vez que podem ser movidos e recuperados de forma independente. Mas, para backups operacionais com retenção de curto prazo, os snapshots são favoráveis.

Portanto, um snapshot diário + logs com backup completo ocasional para retenção de longo prazo é a melhor política de backup para bancos de dados.

Estratégia de backup de log

A estrutura de script de pré-postagem aprimorada é criada no backup de VM do Azure que agenda o backup uma vez por dia. Portanto, a janela de perda de dados com RPO (Recovery Point Objetive, objetivo de ponto de recuperação) como 24 horas não é adequada para bancos de dados de produção. Essa solução é complementada com uma estratégia de backup de log onde os backups de log são transmitidos explicitamente.

NFS em blob e NFS em AFS (Preview) ajudam na fácil montagem de volumes diretamente em VMs de banco de dados e usam clientes de banco de dados para transferir backups de log. A janela de perda de dados que é RPO, cai para a frequência de backups de log. Além disso, os destinos NFS não precisam ser de alto desempenho, pois talvez você não precise acionar o streaming regular (completo e incremental) para backups operacionais depois de ter um instantâneo consistente do banco de dados.

Estratégia de recuperação

Depois que os instantâneos consistentes do banco de dados são tirados e os backups de log são transmitidos para um volume NFS, a estratégia de recuperação do banco de dados pode usar a funcionalidade de recuperação dos backups de VM do Azure. A capacidade de backups de log é adicionalmente aplicada a ele usando o cliente de banco de dados. A seguir estão algumas opções de estratégia de recuperação:

• Crie novas VMs a partir do ponto de recuperação consistente do banco de dados. A VM já deve ter o ponto de montagem de log conectado. Use clientes de banco de dados para executar comandos de recuperação para recuperação point-in-time.
• Crie discos a partir do ponto de recuperação consistente do banco de dados e anexe-os a outra VM de destino. Em seguida, monte o destino do log e use clientes de banco de dados para executar comandos de recuperação para recuperação point-in-time
• Use a opção de recuperação de arquivos e gere um script. Execute o script na VM de destino e anexe o ponto de recuperação como discos iSCSI. Em seguida, use clientes de banco de dados para executar as funções de validação específicas do banco de dados nos discos anexados e validar os dados de backup. Além disso, use clientes de banco de dados para exportar/recuperar algumas tabelas/arquivos em vez de recuperar todo o banco de dados.
• Use a funcionalidade Restauração entre regiões para executar as ações acima da região emparelhada secundária durante um desastre regional.

Resumo

Usando instantâneos consistentes de banco de dados + logs de backup usando uma solução personalizada, você pode criar uma solução de backup de banco de dados eficiente e econômica, aproveitando os benefícios do backup de VM do Azure e também reutilizando os recursos dos clientes de banco de dados.