O Amazon Relational Database Service (AWS RDS) é um serviço de banco de dados totalmente gerenciado que pode oferecer suporte a vários mecanismos de banco de dados. Entre os suportados estão PostgreSQL, MySQL e MariaDB. O ClusterControl, por outro lado, é um software de gerenciamento e automação de banco de dados que também suporta o gerenciamento de backup para bancos de dados de código aberto PostgreSQL, MySQL e MariaDB.
Embora o RDS tenha sido amplamente adotado por muitas empresas, algumas podem não estar familiarizadas com o funcionamento do Point-in-time Recovery (PITR) e como ele pode ser usado.
Vários dos mecanismos de banco de dados usados pelo Amazon RDS têm considerações especiais ao restaurar a partir de um momento específico e, neste blog, abordaremos como funciona para PostgreSQL, MySQL e MariaDB. Também compararemos como ela difere com a função PITR no ClusterControl.
O que é recuperação pontual (PITR)
Se você ainda não estiver familiarizado com o planejamento de recuperação de desastres (DRP) ou o planejamento de continuidade de negócios (BCP), saiba que o PITR é uma das práticas padrão importantes para o gerenciamento de banco de dados. Conforme mencionado em nosso blog anterior, o Point In Time Recovery (PITR) envolve a restauração do banco de dados em um determinado momento no passado. Para poder fazer isso, precisaremos restaurar um backup completo e, em seguida, o PITR ocorre aplicando todas as alterações que ocorreram em um momento específico que você deseja recuperar.
Recuperação pontual (PITR) com AWS RDS
O AWS RDS lida com PITR de maneira diferente da maneira tradicional comum a um banco de dados local. O resultado final compartilha o mesmo conceito, mas com o AWS RDS o backup completo é um snapshot, ele aplica o PITR (que é armazenado no S3) e inicia uma nova instância de banco de dados (diferente).
A forma mais comum requer que você use um backup lógico (usando pg_dump, mysqldump, mydumper) ou físico (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) antes de aplicar o PITR.
O AWS RDS exigirá que você execute uma nova instância de banco de dados, enquanto a abordagem tradicional permite que você armazene com flexibilidade o PITR no mesmo nó de banco de dados em que o backup foi feito ou direcione uma instância de banco de dados diferente (existente) que precisa de recuperação ou para uma nova instância de banco de dados.
Após a criação de sua instância do AWS RDS, os backups automatizados serão ativados. O Amazon RDS executa automaticamente um snapshot diário completo de seus dados. Os agendamentos de instantâneos podem ser definidos durante a criação em sua janela de backup preferida. Enquanto os backups automatizados estão ativados, a AWS também captura logs de transações para o Amazon S3 a cada 5 minutos, registrando todas as suas atualizações de banco de dados. Depois de iniciar uma recuperação pontual, os logs de transações são aplicados ao backup diário mais apropriado para restaurar sua instância de banco de dados para o horário específico solicitado.
Como aplicar um PITR com AWS RDS
A aplicação do PITR pode ser feita de três maneiras diferentes. Você pode usar o Console de gerenciamento da AWS, a AWS CLI ou a API do Amazon RDS assim que a instância de banco de dados estiver disponível. Você também deve levar em consideração que os logs de transações são capturados a cada cinco minutos, que são armazenados no AWS S3.
Depois de restaurar uma instância de banco de dados, o grupo de segurança de banco de dados (SG) padrão é aplicado à nova instância de banco de dados. Se você precisar do db SG personalizado, poderá defini-lo explicitamente usando o Console de gerenciamento da AWS, o comando modify-db-instance da AWS CLI ou a operação ModifyDBInstance da API do Amazon RDS depois que a instância de banco de dados estiver disponível.
PITR exige que você identifique o tempo de restauração mais recente para uma instância de banco de dados. Para fazer isso, você pode usar o comando describe-db-instances da AWS CLI e examinar o valor retornado no campo LatestRestorableTime para a instância de banco de dados. Por exemplo,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Aplicando PITR com o Console AWS
Para aplicar o PITR no Console AWS, faça login no Console AWS → vá para Amazon RDS → Bancos de dados → Selecione (ou clique) na instância de banco de dados desejada e clique em Ações. Ver abaixo,
Depois de tentar restaurar via PITR, a interface do usuário do console irá notificá-lo do que está acontecendo o tempo restaurável mais recente que você pode definir. Você pode usar a última hora restaurável ou especificar a data e hora desejadas. Ver abaixo:
É muito fácil de seguir, mas exige que você preste atenção e preencha as especificações desejadas necessárias para que a nova instância seja executada.
Aplicando PITR com AWS CLI
O uso da AWS CLI pode ser bastante útil, especialmente se você precisar incorporá-la às suas ferramentas de automação para o pipeline de CI/CD. Para fazer isso, você pode começar simplesmente com,
[[email protected] ~]# aws rds restore-db-instance-to-point-in-time \
> --source-db-instance-identifier database-s9s-mysql \
> --target-db-instance-identifier database-s9s-mysql-pitr \
> --restore-time 2020-05-08T07:30:00+00:00
{
"DBInstance": {
"DBInstanceIdentifier": "database-s9s-mysql-pitr",
"DBInstanceClass": "db.t2.micro",
"Engine": "mysql",
"DBInstanceStatus": "creating",
"MasterUsername": "admin",
"DBName": "s9s",
"AllocatedStorage": 18,
"PreferredBackupWindow": "00:00-00:30",
"BackupRetentionPeriod": 7,
"DBSecurityGroups": [],
"VpcSecurityGroups": [
{
"VpcSecurityGroupId": "sg-xxxxx",
"Status": "active"
}
],
"DBParameterGroups": [
{
"DBParameterGroupName": "default.mysql5.7",
"ParameterApplyStatus": "in-sync"
}
],
"DBSubnetGroup": {
"DBSubnetGroupName": "default",
"DBSubnetGroupDescription": "default",
"VpcId": "vpc-f91bdf90",
"SubnetGroupStatus": "Complete",
"Subnets": [
{
"SubnetIdentifier": "subnet-exxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2a"
},
"SubnetStatus": "Active"
},
{
"SubnetIdentifier": "subnet-xxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2c"
},
"SubnetStatus": "Active"
},
{
"SubnetIdentifier": "subnet-xxxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2b"
},
"SubnetStatus": "Active"
}
]
},
"PreferredMaintenanceWindow": "fri:06:01-fri:06:31",
"PendingModifiedValues": {},
"MultiAZ": false,
"EngineVersion": "5.7.22",
"AutoMinorVersionUpgrade": true,
"ReadReplicaDBInstanceIdentifiers": [],
"LicenseModel": "general-public-license",
"OptionGroupMemberships": [
{
"OptionGroupName": "default:mysql-5-7",
"Status": "pending-apply"
}
],
"PubliclyAccessible": true,
"StorageType": "gp2",
"DbInstancePort": 0,
"StorageEncrypted": false,
"DbiResourceId": "db-XXXXXXXXXXXXXXXXX",
"CACertificateIdentifier": "rds-ca-2019",
"DomainMemberships": [],
"CopyTagsToSnapshot": false,
"MonitoringInterval": 0,
"DBInstanceArn": "arn:aws:rds:us-east-2:042171833148:db:database-s9s-mysql-pitr",
"IAMDatabaseAuthenticationEnabled": false,
"PerformanceInsightsEnabled": false,
"DeletionProtection": false,
"AssociatedRoles": []
}
}Ambas as abordagens levam tempo para criar ou preparar a instância de banco de dados até que ela esteja disponível e visível na lista de instâncias de banco de dados no console do AWS RDS.
Limitações do AWS RDS PITR
Ao usar o AWS RDS, você está vinculado a eles como fornecedor. Mover suas operações para fora do sistema pode ser problemático. Aqui estão algumas coisas que você deve considerar:
- O nível de bloqueio do fornecedor ao usar o AWS RDS
- Sua única opção de recuperação via PITR exige que você execute uma nova instância em execução no RDS
- Não há como recuperar usando o processo PITR para um nó externo que não esteja no RDS
- Requer que você aprenda e esteja familiarizado com suas ferramentas e estrutura de segurança.
Como aplicar um PITR com ClusterControl
ClusterControl executa o PITR de maneira simples, porém direta (mas requer que você habilite ou defina os pré-requisitos para que o PITR possa ser usado). Conforme discutido anteriormente, o PITR para ClusterControl funciona de maneira diferente do AWS RDS. Aqui uma lista de onde o PITR pode ser aplicado usando o ClusterControl (a partir da versão 1.7.6):
- Aplica-se após o backup completo com base nas soluções de método de backup disponíveis que oferecemos suporte para bancos de dados PostgreSQL, MySQL e MariaDB.
- Para PostgreSQL, apenas o método de backup pg_basebackup é suportado e compatível para trabalhar com PITR
- Para MySQL ou MariaDB, apenas o método de backup xtrabackup/mariabackup é suportado e compatível para trabalhar com PITR
- Aplicável a bancos de dados MySQL ou MariaDB, o PITR se aplica somente se o nó de origem do backup completo for o nó de destino a ser recuperado.
- Bancos de dados MySQL ou MariaDB exigem que você tenha o registro binário ativado
- Aplicável a bancos de dados PostgreSQL, o PITR se aplica apenas ao mestre/primário ativo e exige que você habilite o arquivamento WAL.
- PITR só pode ser aplicado ao restaurar um backup completo existente
O gerenciamento de backup para ClusterControl é aplicável a ambientes em que os bancos de dados não são totalmente gerenciados e exigem acesso SSH totalmente diferente do AWS RDS. Embora compartilhem o mesmo resultado que é recuperar dados, as soluções de backup que estão presentes no ClusterControl não podem ser aplicáveis no AWS RDS. O ClusterControl também não suporta RDS para gerenciamento e monitoramento.
Usando ClusterControl para PITR no PostgreSQL
Como mencionado anteriormente sobre os pré-requisitos para aproveitar o PITR, você deve habilitar o arquivamento WAL. Isso pode ser feito clicando no ícone de engrenagem, conforme mostrado abaixo:
Como o PITR pode ser aplicado logo após um backup completo, você só pode executar encontre esse recurso na lista Backup, onde você pode tentar restaurar um backup existente. Para fazer isso, a sequência de capturas de tela mostrará como fazer isso:
Em seguida, restaure-o no mesmo host que a origem do backup feito ,
Depois é só especificar a data e hora,
Depois de definir e especificar a data e hora, ClusterControl irá restaurar o backup, em seguida, aplique o PITR assim que o backup for feito. Você também pode verificar isso inspecionando os logs de atividades do trabalho, como abaixo,
Usando ClusterControl para PITR no MySQL/MariaDB
PITR para MySQL ou MariaDB não difere da abordagem que temos acima para PostgreSQL. No entanto, não há equivalência de arquivamento WAL nem um botão ou opção que você possa definir que seja necessário para habilitar a funcionalidade PITR. Como o MySQL e o MariaDB exigem que um PITR possa ser aplicado usando logs binários, no ClusterControl, isso pode ser tratado na guia Gerenciar. Ver abaixo:
Em seguida, especifique a variável log_bin com o valor booleano correspondente. Por exemplo,
Depois que log_bin estiver definido no nó, certifique-se de ter o backup feito no mesmo nó onde também será aplicado o processo de PITR. Isso é indicado anteriormente nos pré-requisitos. Alternativamente, você também pode editar os arquivos de configuração (/etc/my.cnf ou /etc/mysql/my.cnf) e adicionar o log_bin=ON na seção [mysqld], por exemplo.
Quando os logs binários estão habilitados e um backup completo está disponível, você pode fazer o processo PITR da mesma forma que o PostgreSQL UI, mas com campos diferentes que você pode preencher. Você pode especificar a data e hora ou especificar com base no arquivo e posição do log binário (ou posição x &y). Ver abaixo:
Limitações do PITR do ClusterControl
Caso você esteja se perguntando o que pode e o que não pode fazer pelo PITR no ClusterControl, aqui está a lista abaixo:
- Não há nenhuma ferramenta CLI do s9s atual que suporte o processo PITR, portanto, não é possível automatizar ou integrar ao seu pipeline de CI/CD.
- Sem suporte PITR para nós externos
- Não há suporte para PITR quando a origem do backup é diferente do nó de destino
- Não há essa notificação periódica de qual é o período mais recente em que você pode solicitar o PITR
Conclusão
Ambas as ferramentas têm abordagens e soluções diferentes para o ambiente de destino. A principal conclusão é que o AWS RDS tem seu próprio PITR, que é mais rápido, mas é aplicável apenas se seu banco de dados estiver hospedado no RDS e você estiver vinculado a um fornecedor bloqueado.
O ClusterControl permite que você aplique livremente o processo PITR em qualquer data center ou local, desde que os pré-requisitos sejam levados em consideração. Seu objetivo é recuperar os dados. Independentemente de suas limitações, é baseado em como você usará a solução de acordo com o ambiente de arquitetura que está usando.
