Scripts pré-post melhorados para instantâneos consistentes com bases de dados
Azure Backup serviço já fornece uma arquitetura de script pré-post para alcançar a consistência da aplicação em VMs do Linux com Azure Backup. Isto envolve invocar um pré-script (para questionar as aplicações) antes de tirar instantâneos de discos e chamar pós-script (comandos para descongelar as aplicações) depois de o instantâneo ser concluído para devolver as aplicações ao modo normal.
A criação, a depuração e a manutenção de scripts e pré/post podem ser desafiantes. Para remover esta complexidade, Azure Backup fornece uma experiência pré/pós-script simplificada para que as bases de dados marquee obtenham um instantâneo consistente com a aplicação com menos sobrecarga.
A nova arquitetura de script pré-pós-publicação melhorada tem os seguintes principais benefícios:
- Estes scripts pré-post são instalados diretamente em VMs do Azure, juntamente com a extensão de cópia de segurança. Isto ajuda a eliminar a criação e a transferi-las a partir de uma localização externa.
- Pode ver a definição e o conteúdo dos scripts pré-post no GitHub e até submeter sugestões e alterações. Pode até submeter sugestões e alterações através do GitHub, que serão triagemdas e adicionadas para beneficiar a comunidade em geral.
- Pode até adicionar novos scripts pré-post para outras bases de dados através do GitHub, que serão triagemdas e endereçadas para beneficiar a comunidade mais ampla.
- A arquitetura robusta é eficiente para lidar com cenários, como falhas ou falhas de execução do pré-script. Em qualquer caso, o pós-script é executado automaticamente para reverter todas as alterações efetuadas no pré-script.
- A arquitetura também fornece um canal de mensagens para ferramentas externas para obter atualizações e preparar o seu próprio plano de ação em qualquer mensagem/evento.
Fluxo de solução
Matriz de suporte
A seguinte lista de bases de dados é abrangida pela arquitetura melhorada:
- Oracle (Geralmente Disponível) - Ligar à matriz de suporte
- MySQL (Pré-visualização)
Pré-requisitos
Só precisa de modificar um ficheiro de configuração, workload.conf no /etc/azure, para fornecer detalhes de ligação. Isto permite que Azure Backup se liguem à aplicação relevante e executem pré e pós-scripts. O ficheiro 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 seguinte descreve os parâmetros:
| Parâmetro | Obrigatório | Explicação |
|---|---|---|
| workload_name | Yes | Isto irá conter o nome da base de dados para a qual precisa de uma cópia de segurança consistente da aplicação. Os valores suportados atuais são oracle ou mysql. |
| command_path/configuration_path | Isto irá conter o caminho para o binário da carga de trabalho. Este não é um campo obrigatório se o binário da carga de trabalho estiver definido como variável de caminho. | |
| linux_user | Yes | Isto irá conter o nome de utilizador do utilizador do Linux com acesso ao início de sessão do utilizador da base de dados. Se este valor não estiver definido, a raiz é considerada como o utilizador predefinido. |
| credString | Isto significa cadeia de credenciais para ligar à base de dados. Isto conterá toda a cadeia de início de sessão. | |
| ipc_folder | A carga de trabalho só pode escrever em determinados caminhos do sistema de ficheiros. Tem de fornecer este caminho de pasta para que o pré-script possa escrever os estados neste caminho de pasta. | |
| tempo limite | Yes | Este é o limite de tempo máximo para o qual a base de dados estará no estado quiesce. O valor predefinido é 90 segundos. Não é recomendado definir um valor inferior a 60 segundos. |
Nota
A definição JSON é um modelo que o serviço Azure Backup pode modificar para se adequar a uma base de dados específica. Para compreender o ficheiro de configuração de cada base de dados, veja o manual de cada base de dados.
A experiência geral para utilizar a arquitetura de script pré-pós-post melhorada é a seguinte:
- Preparar o ambiente da base de dados
- Editar o ficheiro de configuração
- Acionar a cópia de segurança da VM
- Restaure VMs ou discos/ficheiros a partir do ponto de recuperação consistente da aplicação, conforme necessário.
Criar uma estratégia de cópia de segurança da base de dados
Utilizar instantâneos em vez de transmissão em fluxo
Normalmente, as cópias de segurança de transmissão em fluxo (como, por exemplo, completas, diferenciais ou incrementais) e os registos são utilizados pelos administradores da base de dados na respetiva estratégia de cópia de segurança. Seguem-se alguns dos principais pivôs na estrutura.
- Desempenho e custo: um total diário + registos seria o mais rápido durante o restauro, mas envolve custos significativos. Incluir o tipo de cópia de segurança de transmissão em fluxo diferencial/incremental reduz o custo, mas pode afetar o desempenho do restauro. Mas os instantâneos fornecem a melhor combinação de desempenho e custo. Como os instantâneos são inerentemente incrementais, têm menos impacto no desempenho durante a cópia de segurança, são restaurados rapidamente e também poupam custos.
- Impacto na base de dados/infraestrutura: o desempenho de uma cópia de segurança de transmissão em fluxo depende da IOPS de armazenamento subjacente e da largura de banda de rede disponível quando o fluxo é direcionado para uma localização remota. Os instantâneos não têm esta dependência e a procura por IOPS e largura de banda de rede é significativamente reduzida.
- Reutilização: os comandos para acionar diferentes tipos de cópia de segurança de transmissão em fluxo são diferentes para cada base de dados. Assim, os scripts não podem ser facilmente reutilizados. Além disso, se estiver a utilizar diferentes tipos de cópia de segurança, certifique-se de que avalia a cadeia de dependências para manter o ciclo de vida. Para instantâneos, é fácil escrever script, uma vez que não existe nenhuma cadeia de dependências.
- Retenção de longo prazo: as cópias de segurança completas são sempre benéficas para a retenção de longo prazo0, uma vez que podem ser movidas e recuperadas de forma independente. Mas, para cópias de segurança operacionais com retenção de curto prazo, os instantâneos são favoráveis.
Por conseguinte, um instantâneo diário + registos com cópias de segurança completas ocasionais para retenção de longo prazo é a melhor política de cópia de segurança para bases de dados.
Estratégia de cópia de segurança de registos
A arquitetura de script pré-pós-publicação melhorada baseia-se na cópia de segurança da VM do Azure que agenda a cópia de segurança uma vez por dia. Assim, a janela de perda de dados com o RPO como 24 horas não é adequada para bases de dados de produção. Esta solução é complementada com uma estratégia de cópia de segurança de registos em que as cópias de segurança de registo são transmitidas explicitamente.
O NFS no blob e no NFS no AFS (Pré-visualização) ajuda na montagem fácil de volumes diretamente em VMs de base de dados e utiliza clientes de base de dados para transferir cópias de segurança de registo. A janela de perda de dados, ou seja, RPO, enquadra-se na frequência das cópias de segurança de registo. Além disso, os destinos NFS não precisam de ter um elevado desempenho, uma vez que poderá não precisar de acionar a transmissão em fluxo regular (completa e incremental) para cópias de segurança operacionais depois de ter instantâneos consistentes com a base de dados.
Nota
Normalmente, o script pré-avançado tem o cuidado de remover todas as transações de registo em trânsito para o destino da cópia de segurança de registo, antes de processar a base de dados para tirar um instantâneo. Por conseguinte, os instantâneos são consistentes e fiáveis durante a recuperação.
Estratégia de recuperação
Assim que os instantâneos consistentes da base de dados forem tirados e as cópias de segurança de registo forem transmitidas para um volume NFS, a estratégia de recuperação da base de dados poderá utilizar a funcionalidade de recuperação das cópias de segurança da VM do Azure. A capacidade das cópias de segurança de registo é aplicada adicionalmente ao mesmo com o cliente da base de dados. Seguem-se poucas opções de estratégia de recuperação:
- Crie novas VMs a partir do ponto de recuperação consistente da base de dados. A VM já deve ter o ponto de montagem de registo ligado. Utilize clientes de base de dados para executar comandos de recuperação para recuperação para um ponto anterior no tempo.
- Crie discos a partir do ponto de recuperação consistente da base de dados e anexe-os a outra VM de destino. Em seguida, monte o destino do registo e utilize clientes de base de dados para executar comandos de recuperação para recuperação para um ponto anterior no tempo
- Utilize a opção de recuperação de ficheiros e gere um script. Execute o script na VM de destino e anexe o ponto de recuperação como discos iSCSI. Em seguida, utilize clientes de base de dados para executar as funções de validação específicas da base de dados nos discos anexados e validar os dados de cópia de segurança. Além disso, utilize clientes de base de dados para exportar/recuperar algumas tabelas/ficheiros em vez de recuperar toda a base de dados.
- Utilize a funcionalidade Restauro entre Regiões para executar as ações acima da região emparelhada secundária durante o desastre regional.
Resumo
Ao utilizar instantâneos consistentes da base de dados + registos com uma solução personalizada, pode criar uma solução de cópia de segurança de bases de dados eficaz e eficaz em termos de desempenho, tirando partido dos benefícios da cópia de segurança da VM do Azure e reutilizando também as capacidades dos clientes da base de dados.