Automatização de snapshots application-consistent do Amazon EBS para MySQL e PostgreSQL

Por Chakrapani Ramasundaram, Arnab Saha, Vivek Singh e Tom McDonald

O MySQL e o PostgreSQL são sistemas populares de gerenciamento de banco de dados relacional que muitas organizações usam para alimentar aplicativos web, sites dinâmicos e sistemas embarcados. Para clientes que hospedam o MySQL e o PostgreSQL por conta própria com a AWS, eles podem usar as ferramentas de sua escolha para gerenciar o sistema operacional, o software de banco de dados, os patches, a replicação de dados, o backup e a restauração. À medida que os clientes fazem backup de suas cargas de trabalho do MySQL e do PostgreSQL como parte de um fluxo de trabalho personalizado para atender às necessidades de proteção de dados, eles geralmente gastam muito tempo e esforço operacional gerenciando a orquestração dos fluxos de trabalho de backup, expondo os clientes a erros humanos que podem levar à perda de snapshots e ao aumento dos custos de armazenamento.

Se você tiver instâncias do Amazon Elastic Compute Cloud (Amazon EC2) executando bancos de dados MySQL e PostgreSQL autogerenciados, talvez queira considerar a criação de snapshots do Amazon Elastic Block Store (EBS), além de qualquer backup lógico ou físico à nível de banco de dados. Ao contrário dos backups de banco de dados, os backups de snapshots são cópias pontuais de seus dados, que podem ser usadas facilmente para recuperar um banco de dados inteiro ou migrar bancos de dados entre regiões e contas da AWS. Com o Amazon Data Lifecycle Manager, uma solução de gerenciamento de ciclo de vida baseada em políticas para snapshots do EBS, você pode automatizar a criação, retenção e exclusão de snapshots do EBS para suas cargas de trabalho de banco de dados em intervalos regulares. Agora, com o suporte adicional do Amazon Data Lifecycle Manager para automação pré-script e pós-script, você obtém um método simples para otimizar as operações de backup criando scripts personalizados nas políticas do Amazon Data Lifecycle Manager para automatizar as ações de backup do banco de dados, como congelar e descongelar I/O, antes (pré-script) e depois (pós-script) do início dos snapshots do EBS. Também criamos modelos que incluem comandos pré-script e pós-script para versões padrão do MySQL e do PostgreSQL, que você pode usar com o Data Lifecycle Manager para simplificar a automação de snapshots application-consistent.

Neste post, abordaremos o uso do Amazon Data Lifecycle Manager e do AWS Systems Manager para automatizar a criação de snapshots application-consistent do EBS para bancos de dados MySQL e PostgreSQL autogerenciados. A solução permite que você crie snapshots application-consistent de seus bancos de dados com confiança. Esses snapshots servem como backups confiáveis para recuperação de desastres, migração de dados ou outras necessidades operacionais críticas.

Visão geral da solução

Anteriormente, descrevemos como criar snapshot application-consistent usando o Amazon Data Lifecycle Manager e scripts personalizados, incluindo as etapas necessárias para criar políticas do Amazon Data Lifecycle Manager que usam o AWS Systems Manager Agent (SSM Agent) para executar scripts personalizados em suas instâncias do EC2 antes e depois da inicialização dos snapshots do EBS. Neste post, vamos nos basear nessas instruções para criar snapshots application-consistent para bancos de dados MySQL e PostgreSQL. Descrevemos como automatizar os pré-scripts para pausar o I/O e liberar o buffer para o disco e os pós-scripts para descongelar o I/O, conforme mostrado na figura a seguir.

Pré-requisitos

Você deve instalar o Systems Manager Agent em todas as instâncias para as quais deseja criar snapshots application-consistent do EBS e garantir que o agente esteja em execução. Se você estiver usando uma dessas Amazon Machine Images (AMIs) fornecidas pela AWS, o Systems Manager Agent já foi pré-instalado. Você deve configurar todas as instâncias do EC2 com as permissões relevantes para que o Systems Manager possa executar o documento do Systems Manager. Você também deve garantir que a função de serviço do AWS Identity and Access Management (IAM) usada para sua política do Data Lifecycle Manager tenha as permissões apropriadas para executar os documentos do Systems Manager nas instâncias do EC2 de destino. A maneira mais fácil de fazer isso é anexar a política do IAM AWSDataLifecycleManagersSMFullAccess à função do IAM. Se você estiver usando essa função, então você deverá adicionar a tag DLMScriptsAccess:true a qualquer documento personalizado do Systems Manager que queira usar com esse recurso.

Em seguida, você deve ter um código que congele o banco de dados e descarregue os dados no disco (pré-script) e, em seguida, descongele o banco de dados (pós-script) depois que os snapshots forem inicializados. Fornecemos um código modelo para concluir essas etapas para as versões padrão do MySQL e do PostgreSQL, nas quais você pode criar para seu banco de dados específico. Observe que é sua responsabilidade garantir que o código possa realizar as ações necessárias em seu banco de dados. Se o código for inválido, os snapshots criados não serão application-consistent.

Passo a passo

Para ativar a automação personalizada de pré-script e pós-script, conclua as seguintes etapas:

1. Crie um documento do Systems Manager (ou use um modelo SSM existente para seu aplicativo) que congele o I/O, libera a memória para o disco e, em seguida, descongele o I/O. O documento precisa ter os campos obrigatórios para que o Data Lifecycle Manager acione ações.
2. Crie uma política do Amazon Data Lifecycle Manager. Ela é responsável por coordenar a execução do documento do Systems Manager, iniciar o snapshot, marcar os snapshots como application-consistent, bem como gerenciar sua retenção e outras ações.
3. Verifique se os snapshots criados são application-consistent.

Etapa 1: criar um documento do AWS Systems Manager

1. Navegue até o console do Systems Manager e selecione Documentos no painel de navegação.

2. Selecione a caixa suspensa Criar documento, seguida por Comando ou Sessão.

3. Preencha os detalhes do documento e verifique se o tipo de documento está definido como Comando. Neste exemplo, o nome do documento é MySQL-EBS-Snapshots. Lembre-se disso, pois você deve usar o mesmo nome de documento posteriormente ao criar a política.

4. Cole o código pré-script e pós-script do seu banco de dados na seção Conteúdo em YAML.

Ao adicionar código, você deve se certificar de que os campos obrigatórios estejam presentes. O Amazon Data Lifecycle Manager se baseia nesses campos para inicializar corretamente o pré-script e o pós-script. Sem ele, o Data Lifecycle Manager não pode criar snapshots application-consistent do EBS.

Recomendamos que você comece modificando o modelo de documento do Systems Manager Command fornecido para MySQL e PostgreSQL, em vez de criar seus próprios documentos do zero. As partes pré-script e pós-script do modelo para MySQL são descritas mais detalhadamente na seção a seguir.

Observe que é sua responsabilidade garantir que o código possa realizar as ações necessárias em seu banco de dados. Se o código não for válido, você não poderá obter snapshots application-consistent do EBS.

Se você planeja excluir o volume raiz e/ou os volumes não raiz ao criar o conjunto de snapshots application-consistent, certifique-se de que o código fornecido execute as etapas necessárias no conjunto apropriado de volumes do EBS.

Veja a seguir um exemplo de pré-script para congelar o I/O. Também incluímos o “descongelamento automático” (definido para 60 segundos no modelo) como um mecanismo à prova de falhas para descongelar o banco de dados. O script também não congela o sistema de arquivos raiz/boot. Recomendamos que você use somente volumes de dados (não raiz) para seu banco de dados.

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE

# Auto thaw is a fail safe mechanism to automatically unfreeze the application after the # duration specified in the global variable below. Choose the duration based on your # database application's tolerance to freeze. export AUTO_THAW_DURATION_SECS="60"

# Add all pre-script actions to be performed within the function below execute_pre_script() {
echo "INFO: Start execution of pre-script"
# Check if filesystem is already frozen. No error code indicates that filesystem # is not currently frozen and that the pre-script can proceed with freezing the filesystem. check_fs_freeze
# Execute the DB commands to flush the DB in preparation for snapshot snap_db
# Freeze the filesystem. No error code indicates that filesystem was succefully frozen freeze_fs

echo "INFO: Schedule Auto Thaw to execute in ${AUTO_THAW_DURATION_SECS} seconds."
$(nohup bash -c execute_schedule_auto_thaw >/dev/null 2>&1 &)
}

# Iterate over all the mountpoints and freeze the filesystem. freeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous. Hence, skip filesystem freeze # operations for root and boot mountpoints. if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Freezing $target"
error_message=$(sudo fsfreeze -f $target 2>&1)
if [ $? -ne 0 ];then
# If the filesystem is already in frozen, return error code 204 if [[ "$error_message" == *"$FS_ALREADY_FROZEN_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} already frozen. Return Error Code: 204"
sudo mysql -e 'UNLOCK TABLES;'
exit 204
fi
# If the filesystem freeze failed due to any reason other than the filesystem already frozen, return 201 echo "ERROR: Failed to freeze mountpoint $targetdue due to error - $errormessage"
thaw_db
exit 201
fi
echo "INFO: Freezing complete on $target"
done
}

Veja a seguir um exemplo de pós-script para descongelar o I/O e desativar o descongelamento automático:

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# Permission is hereby granted, free of charge, to any person obtaining a copy of this
# software and associated documentation files (the "Software"), to deal in the Software
# without restriction, including without limitation the rights to use, copy, modify,
# merge, publish, distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
# INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
# PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
# SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

# Add all post-script actions to be performed within the function below execute_post_script() {
echo "INFO: Start execution of post-script"
# Unfreeze the filesystem. No error code indicates that filesystem was successfully unfrozen. unfreeze_fs
thaw_db
} 

# Iterate over all the mountpoints and unfreeze the filesystem. unfreeze_fs() {
for target in $(lsblk -nlo MOUNTPOINTS)
do
# Freeze of the root and boot filesystems is dangerous and pre-script does not freeze these filesystems. # Hence, will skip the root and boot mountpoints during unfreeze as well. if [ $target == '/' ]; then continue; fi
if [[ "$target" == *"/boot"* ]]; then continue; fi
echo "INFO: Thawing $target"
error_message=$(sudo fsfreeze -u $target 2>&1)
# Check if filesystem is already unfrozen (thawed). Return error code 204 if filesystem is already unfrozen. if [ $? -ne 0 ]; then
if [[ "$error_message" == *"$FS_ALREADY_THAWED_ERROR"* ]]; then
echo "ERROR: Filesystem ${target} is already in thaw state. Return Error Code: 205"
exit 205
fi
# If the filesystem unfreeze failed due to any reason other than the filesystem already unfrozen, return 202 echo "ERROR: Failed to unfreeze mountpoint $targetdue due to error - $errormessage"
exit 202
fi
echo "INFO: Thaw complete on $target"
done 
}

5. Em seguida, adicione a tag (Key = DLMScriptsAccess, Value = true) a este documento para que a política possa executá-la por meio do Systems Manager Agent (usando a função padrão do IAM). Adicione outras tags ao documento do Systems Manager conforme necessário e selecione Criar documento.

Etapa 2: criar uma política do Amazon Data Lifecycle Manager

Agora, criamos políticas do Amazon Data Lifecycle Manager para automatizar a criação e o gerenciamento de snapshots do EBS que são iniciados entre os pré-scripts e os pós-scripts. As etapas descritas a seguir são necessárias ao criar a política por meio do console do Amazon EC2. No entanto, você também pode criar a política usando a API/CLI e o AWS CloudFormation.

Se você já tem políticas que criam snapshots crash-consistent, você pode modificar essas políticas e ativar o recurso de script anterior e posterior. Desde que todos os outros pré-requisitos tenham sido atendidos, suas políticas começarão a criar snapshots application-consistent do EBS na próxima vez em que forem executados.

1. Para começar, inicie o console do EC2 e selecione Lifecycle Manager em Elastic Block Store no painel de navegação do lado esquerdo. Em Política baseada em agendamento, selecione Política de snapshot do EBS.
2. Em Tipos de recursos de destino, selecione Instância e, em seguida, forneça tags para todas as instâncias que você deseja segmentar. Neste exemplo, vamos segmentar todas as instâncias com a tag (mysql:true). Adicione uma descrição para a política.

3. Para a função do IAM, a maioria dos clientes deve selecionar a função padrão, pois ela terá todas as permissões necessárias para as ações da política. Ao criar/modificar políticas por meio do console, a política do IAM AWSDataLifecycleManagersSMFullAccess (que tem todas as permissões para esse recurso) será automaticamente anexada à função padrão. Se você estiver usando API/CLI para criar/modificar políticas para esse recurso, precisará anexar manualmente a política do IAM à função padrão. Se você optar por usar uma função personalizada do IAM, precisará garantir que a função do IAM tenha todas as permissões necessárias para executar documentos SSM em instâncias específicas.

4. Na próxima página, configure seu cronograma de criação de políticas. Neste exemplo, estamos criando instantâneos a cada 24 horas às 11:00 UTC e os retendo por 7 dias.

5. Em Configurações avançadas, certifique-se de marcar a caixa Habilitar scripts de pré e pós-venda para essa programação. Em seguida, selecione o quadro denominado Documento SSM personalizado e o botão de opção para scripts anteriores e posteriores na opção Automação.

6. Em Documento do Systems Manager, digite o nome do documento de comando do Systems Manager que você criou na Etapa 1 (“MySQL-EBS-Snapshots”). Você também pode definir parâmetros adicionais aqui, como o tempo limite do script, e ativar o Repetir Script se ele falhar.

O tempo limite do script é a quantidade de tempo que o Amazon Data Lifecycle Manager espera pela conclusão bem-sucedida do script. Se o tempo for excedido e o Data Lifecycle Manager não tiver recebido a confirmação da conclusão bem-sucedida, sua política considerará o script como tendo falhado.

Você pode definir o script de repetição se ele falhar na tentativa automática de iniciar o script com falha. Você deve considerar isso se quiser uma maior probabilidade de seu script ser concluído com êxito e se seu banco de dados aguentar ser desativado repetidamente em um curto intervalo de tempo.

Recomendamos que você também ative como padrão o snapshot crash-consistent caso o script falhar. Se ativado, o Amazon Data Lifecycle Manager tentará criar snapshots crash-consistent caso não consiga executar seu pré-script com sucesso. Você pode usar as tags aplicadas aos snapshots, bem como o Amazon EventBridge, para determinar posteriormente se os snapshots do EBS foram criados como parte de execuções bem-sucedidas do pré-script e do pós-script em seu documento do Systems Manager.

7. Em Configurações avançadas, você também pode definir a política para automatizar outras ações, como cópia entre regiões e compartilhamento entre contas. Neste exemplo, estamos definindo a política para garantir que o conjunto mais recente de snapshots application-consistent do EBS para cada instância do EC2 tenha o Fast Snapshot Restore ativado em us-east-1a. Portanto, os volumes criados a partir desses snapshots oferecem instantaneamente todo o desempenho provisionado.

Etapa 3: validar se os snapshots criados são application-consistent

Depois que sua política do Amazon Data Lifecycle Manager tiver criado um snapshot do EBS, você poderá verificar se ele é application-consistent.

1. Navegue até o console do Amazon EC2 e selecione Snapshots.

2. Selecione o snapshot e selecione Tags no painel inferior. Se você ver uma tag para ‘aws:dlm:pre-script: SUCCESS’, o snapshot foi criado após a execução bem-sucedida do pré-script. Se você ver uma tag para ‘aws:dlm:post-script: SUCCESS’, o pós-script também foi concluído com êxito. Se você ver SUCESSO em ambas as tags e seu documento do Systems Manager tiver as instruções corretas para desativar o disco, liberar os dados na memória e descongelar o disco, os snapshots que você criou são application-consistent.

Limpando

Limpe os snapshots criados durante as etapas anteriores para garantir que você não incorra em cobranças de armazenamento. Você pode fazer isso navegando até a tela Snapshots, pesquisando todos os snapshots criados pela política, selecionando todos os snapshots e, em seguida, selecionando Ações seguidas de Excluir snapshots.

Da mesma forma, exclua a política do Data Lifecycle Manager para garantir que nenhum snapshot futuro seja criado pela política. Você pode fazer isso navegando até a tela do Lifecycle Manager, selecionando a política e, em seguida, selecionando Ações seguidas de Excluir política de ciclo de vida.

Conclusão

Neste post, analisamos como automatizar a criação e a retenção de snapshots application-consistent do EBS. Esperamos que isso reduza a quantidade de tempo e esforço necessários para aprimorar a proteção de dados de seus bancos de dados autogerenciados em execução em instâncias do EC2.

Com o Amazon Data Lifecycle Manager, você pode excluir o volume raiz/boot ao criar um conjunto de snapshots application-consistent. Você também pode excluir volumes (de dados) que não sejam de inicialização, o que é útil se você quiser economizar custos ao não criar backups de volumes que são usados apenas para armazenar dados temporários ou de log. Você também pode definir sua política para gerenciar o Fast Snapshot Restore no conjunto mais recente de snapshots para que você possa criar novos volumes do EBS que ofereçam o máximo desempenho sem precisar ser inicializados. Além disso, você pode compartilhar automaticamente os snapshots com diferentes contas e copiar snapshots para diferentes regiões da AWS. Além disso, a criação de políticas do Amazon Data Lifecycle Manager é gratuita, o que evita que você precise usar ferramentas de terceiros ou desenvolver e manter scripts personalizados complexos.

Como conclusão final, recomendamos que você experimente isso em seu próprio ambiente. Você também pode aprender mais sobre esse recurso lendo nossa documentação técnica e explorando diferentes casos de uso de scripts anteriores e posteriores com o Amazon Data Lifecycle Manager.

Seus comentários são bem-vindos. Se você tiver dúvidas ou sugestões, deixe-as na seção de comentários.

Este blog é uma tradução do contéudo original em inglês (link aqui).

Biografia do Autores

	Chakrapani Ramasundaram é engenheira de desenvolvimento de software da Amazon Elastic Block Store (Amazon EBS). Ele é um solucionador de problemas de coração e adora identificar e resolver os pontos problemáticos dos clientes. Chakrapani tem mais de 10 anos de experiência projetando e construindo sistemas de grande escala, desde a concepção até a comercialização.
	Arnab Saha é arquiteto sênior de soluções especialista em banco de dados na Amazon Web Services. A Arnab é especializada em Amazon RDS, Amazon Aurora, AWS DMS e Amazon Elastic Block Store. Ele fornece orientação e assistência técnica aos clientes para criar soluções escaláveis, altamente disponíveis e seguras na nuvem da AWS.
	Vivek Singh é o principal gerente técnico de contas especializado em banco de dados na AWS, com foco em mecanismos RDS/Aurora PostgreSQL. Ele trabalha com clientes corporativos fornecendo assistência técnica sobre desempenho operacional do PostgreSQL e compartilhando as melhores práticas de banco de dados. Ele tem mais de 17 anos de experiência em soluções de banco de dados de código aberto e gosta de trabalhar com clientes para ajudar a projetar, implantar e otimizar cargas de trabalho de bancos de dados relacionais na AWS.
	Tom McDonald é especialista sênior em armazenamento de carga de trabalho na AWS. Começando com um Atari 400 e reprogramando fitas, Tom começou um longo interesse em aumentar o desempenho em qualquer serviço de armazenamento. Com 20 anos de experiência no domínio Upstream Energy, sistemas de arquivos e computação de alto desempenho, Tom é apaixonado por capacitar outras pessoas por meio de comunidade e orientação.

Biografia tradutor e revisor

	Gustavo Lima é Arquiteto de Soluções na AWS no segmento de Partner First SP High Biller. Ele possui mais de 13 anos de experiência na área de soluções de armazenamento e proteção de dados. Juntou-se ao time da AWS em 2022. https://www.linkedin.com/in/gustavo-lima-21940212/
	Rubens Karklin é arquiteto de soluções da AWS que atua no Setor Público. Ele com quase 18 anos de experiência e 9 anos no setor público vem ajudando clientes a prosperarem seus negócios com expertise nas áreas de Redes, Segurança, Armazenamento de Dados, Computação e sempre ávido a aprender novas tecnologias. https://www.linkedin.com/in/rubenskarklin