Pré-scripts e pós-scripts avançados para instantâneos consistentes de banco de dados

O Backup do Azure oferece uma estrutura pré-script e pós-script interna para garantir a consistência do aplicativo para VMs Linux durante o backup. Essa estrutura executa automaticamente um pré-script para silenciar aplicativos antes de um instantâneo de disco e um pós-script para restaurar os aplicativos ao funcionamento normal após o instantâneo.

O gerenciamento de pré-scripts personalizados e pós-scripts geralmente é complexo e demorado. Para simplificar esse processo, o Backup do Azure fornece pré-scripts prontos para uso e pós-scripts para bancos de dados populares para habilitar instantâneos consistentes com o aplicativo com esforço e manutenção mínimos.

O diagrama a seguir ilustra como o Backup do Azure usa pré-scripts e pós-scripts avançados para obter instantâneos consistentes com o aplicativo para bancos de dados Linux para garantir o backup e a recuperação confiáveis.

Principais benefícios de uma estrutura pré-script e pós-script avançada

A nova estrutura pré-script e pós-script avançada tem os seguintes benefícios principais:

• Esses pré-scripts e pós-scripts são instalados diretamente em 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.
• A definição e o conteúdo de pré-descritos e postscripts estão disponíveis para exibição no GitHub. Você pode enviar sugestões e alterações por meio do GitHub, que são analisadas e adicionadas para beneficiar a comunidade como um todo.
• Novos pré-scripts e pós-scripts para outros bancos de dados estão disponíveis por meio do GitHub, que são triageados e endereçados para beneficiar a comunidade mais ampla.
• A estrutura robusta é eficiente para lidar com cenários, como falha na execução de scripts ou incidentes. De qualquer forma, o postscript é executado automaticamente para reverter todas as alterações feitas no prescript.
• 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 ou evento.

Fluxo de solução de estrutura pré-script e pós-script avançada

O diagrama a seguir ilustra o fluxo de solução da estrutura pré-script e pós-script avançada para instantâneos consistentes do banco de dados.

Matriz de suporte

Os seguintes bancos de dados são abordados na estrutura aprimorada:

• Oracle (geralmente disponível): consulte a matriz de suporte para backups de VM do Azure.
• MySQL (versão prévia).

Pré-requisitos

Você precisa modificar apenas um arquivo de configuração, workload.conf in /etc/azure, para fornecer detalhes da conexão. Dessa forma, o Backup do Azure pode se conectar ao aplicativo relevante e executar pré-scripts 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.

Parâmetro	Obrigatório	Explicação
workload_name	Sim	Contém o nome do banco de dados para o qual você precisa de backup consistente com o aplicativo. Os valores com suporte atuais são oracle ou mysql.
command_path/configuration_path		Contém um caminho para o binário de carga de trabalho. Esse campo não será obrigatório se o binário da carga de trabalho for definido como uma variável de caminho.
linux_user	Sim	Contém o nome de usuário do Linux com acesso ao login do usuário do banco de dados. Se esse valor não estiver definido, root será considerado como o usuário padrão.
credString		Refere-se à cadeia de caracteres de credencial usada para conectar ao banco de dados. Contém toda a cadeia de caracteres de entrada.
ipc_folder		A carga de trabalho pode gravar apenas em determinados diretórios do sistema de arquivos. Forneça esse caminho de pasta para que o pré-script possa gravar os estados nesse caminho de pasta.
timeout	Sim	Limite máximo de tempo para o qual o banco de dados está em um estado silencioso. O valor padrão é 90 segundos. Não defina um valor inferior a 60 segundos.

Observação

A definição de JSON é um modelo que o Backup do Azure pode modificar para atender a um banco de dados específico. Para entender o arquivo de configuração de cada banco de dados, consulte o manual de cada banco de dados.

A experiência geral para usar a estrutura pré-script e pós-script avançada é:

• Prepare o ambiente do banco de dados.
• Edite o arquivo de configuração.
• Inicie o backup da VM.
• Restaure VMs, discos ou arquivos do ponto de recuperação consistente com o aplicativo, conforme necessário.

Criar uma estratégia de backup de banco de dados

Usar instantâneos em vez de streaming

Normalmente, os backups de streaming (como completo, diferencial ou incremental) e os logs são usados por administradores de banco de dados em sua estratégia de backup. Os principais pontos no design são:

• Desempenho e custo: um backup completo diário mais logs é o mais rápido durante a restauração, mas envolve um custo significativo. Incluir o tipo de backup de streaming diferencial ou incremental reduz o custo, mas pode afetar o desempenho da restauração. No entanto, os instantâneos fornecem a melhor combinação de desempenho e custo. Como os instantâneos são inerentemente incrementais, eles têm o menor efeito sobre o desempenho durante o backup, são restaurados rapidamente e também economizam custos.
• Impacto no banco de dados ou na infraestrutura: o desempenho de um backup de streaming depende do IOPS de armazenamento subjacente e da largura de banda de rede que está disponível quando o fluxo é direcionado para um local remoto. Os instantâneos não têm essa dependência e a demanda por IOPS e largura de banda de rede é reduzida.
• Reutilização: os comandos para disparar diferentes tipos de backup de streaming são diferentes para cada banco de dados, portanto, os scripts não podem ser reutilizados facilmente. Além disso, se você estiver usando diferentes tipos de backup, avalie a cadeia de dependências para manter o ciclo de vida. Para instantâneos, é fácil gravar scripts, porque não há nenhuma cadeia de dependências.
• Retenção de longo prazo: os backups completos são sempre benéficos para a retenção de longo prazo, pois você pode movê-los e recuperá-los de forma independente. Para backups operacionais com retenção de curto prazo, os instantâneos são favoráveis.

A política de backup ideal para bancos de dados é um snapshot diário acompanhado de logs, com backups completos ocasionais para retenção de longo prazo.

Estratégia de backup de log

A estrutura script e pós-script avançada é criada no backup de VM do Azure que agenda o backup uma vez por dia. Por esse motivo, a janela de perda de dados com o RPO (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 em que os backups de log são transmitidos explicitamente.

O NFS (Sistema de Arquivos de Rede) no Armazenamento de Blobs do Azure e o NFS no AFS (versão prévia) 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, enquadra-se na frequência de backups de log. Além disso, os alvos NFS não precisam ter alto desempenho. Talvez você não precise disparar streaming regular (completo e incremental) para backups operacionais depois de ter instantâneos consistentes com o banco de dados.

Observação

O pré-script aprimorado geralmente tem o cuidado de liberar todas as transações de log em trânsito para o destino de backup de log, antes de acalmar o banco de dados para novas sessões para tirar um instantâneo. Como resultado, os instantâneos são consistentes com o banco de dados e confiáveis durante a recuperação.

Estratégia de recuperação

Depois que os instantâneos consistentes com o 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 de backups de VM do Azure. A capacidade de backups de log também é aplicada a ele usando o cliente de banco de dados. As seguintes opções para a estratégia de recuperação são:

• Crie novas máquinas virtuais a partir de um ponto de recuperação consistente com o 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 pontual.
• Crie discos de um ponto de recuperação consistente com o 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 pontual.
• Use uma opção de recuperação de arquivo 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 ou recuperar algumas tabelas ou arquivos em vez de recuperar todo o banco de dados.
• Use a funcionalidade Restauração entre regiões para executar as ações anteriores de regiões emparelhadas secundárias durante um desastre regional.

Resumo

Com instantâneos consistentes com a base de dados, além de logs com backup utilizando uma solução personalizada, é possível criar uma solução de backup de banco de dados que seja tanto eficiente em desempenho quanto econômico. Essa solução usa os benefícios do backup de VM do Azure e também reutiliza os recursos dos clientes de banco de dados.