Amazon Relational Database Service (AWS RDS) es un servicio de base de datos totalmente administrado que puede admitir varios motores de base de datos. Entre los compatibles se encuentran PostgreSQL, MySQL y MariaDB. ClusterControl, por otro lado, es un software de gestión y automatización de bases de datos que también admite el manejo de copias de seguridad para bases de datos de código abierto PostgreSQL, MySQL y MariaDB.
Si bien RDS ha sido ampliamente adoptado por muchas empresas, es posible que algunas no estén familiarizadas con el funcionamiento de su recuperación puntual (PITR) y cómo se puede utilizar.
Varios de los motores de base de datos utilizados por Amazon RDS tienen consideraciones especiales al restaurar desde un punto específico en el tiempo, y en este blog cubriremos cómo funciona para PostgreSQL, MySQL y MariaDB. También compararemos cómo difiere con la función PITR en ClusterControl.
¿Qué es la recuperación de un punto en el tiempo (PITR)
Si aún no está familiarizado con la planificación de recuperación ante desastres (DRP) o la planificación de continuidad empresarial (BCP), debe saber que PITR es una de las prácticas estándar importantes para la gestión de bases de datos. Como se mencionó en nuestro blog anterior, Point In Time Recovery (PITR) implica restaurar la base de datos en cualquier momento del pasado. Para poder hacer esto, necesitaremos restaurar una copia de seguridad completa y luego PITR se lleva a cabo aplicando todos los cambios que ocurrieron en un momento específico que desea recuperar.
Recuperación en un punto en el tiempo (PITR) con AWS RDS
AWS RDS maneja PITR de manera diferente a la forma tradicional común a una base de datos local. El resultado final comparte el mismo concepto, pero con AWS RDS, la copia de seguridad completa es una instantánea, luego aplica el PITR (que se almacena en S3) y luego lanza una nueva instancia de base de datos (diferente).
La forma común requiere que use una lógica (usando pg_dump, mysqldump, mydumper) o física (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) para su copia de seguridad completa antes de aplicar el PITR.
AWS RDS requerirá que inicie una nueva instancia de base de datos, mientras que el enfoque tradicional le permite almacenar de manera flexible el PITR en el mismo nodo de la base de datos donde se realizó la copia de seguridad o apuntar a una instancia de base de datos diferente (existente) que necesita recuperación o a una nueva instancia de base de datos.
Después de la creación de su instancia de AWS RDS, se activarán las copias de seguridad automáticas. Amazon RDS realiza automáticamente una instantánea diaria completa de sus datos. Los cronogramas de instantáneas se pueden configurar durante la creación en su ventana de copia de seguridad preferida. Si bien las copias de seguridad automáticas están activadas, AWS también captura los registros de transacciones en Amazon S3 cada 5 minutos y registra todas las actualizaciones de su base de datos. Una vez que inicia una recuperación de un punto en el tiempo, los registros de transacciones se aplican a la copia de seguridad diaria más adecuada para restaurar su instancia de base de datos a la hora específica solicitada.
Cómo aplicar un PITR con AWS RDS
La aplicación de PITR se puede realizar de tres maneras diferentes. Puede utilizar la consola de administración de AWS, la CLI de AWS o la API de Amazon RDS una vez que la instancia de base de datos esté disponible. También debe tener en cuenta que los registros de transacciones se capturan cada cinco minutos y luego se almacenan en AWS S3.
Una vez que restaura una instancia de base de datos, el grupo de seguridad (SG) de base de datos predeterminado se aplica a la nueva instancia de base de datos. Si necesita el SG de base de datos personalizado, puede definirlo explícitamente mediante la consola de administración de AWS, el comando modify-db-instance de la AWS CLI o la operación ModifyDBInstance de la API de Amazon RDS una vez que la instancia de base de datos esté disponible.
PITR requiere que identifique el tiempo de restauración más reciente para una instancia de base de datos. Para ello, puede utilizar el comando describe-db-instances de la AWS CLI y ver el valor devuelto en el campo LatestRestorableTime para la instancia de base de datos. Por ejemplo,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Aplicación de PITR con la consola de AWS
Para aplicar PITR en la consola de AWS, inicie sesión en la consola de AWS → vaya a Amazon RDS → Bases de datos → Seleccione (o haga clic en) la instancia de base de datos deseada y luego haga clic en Acciones. Véase más abajo,
Una vez que intente restaurar a través de PITR, la interfaz de usuario de la consola le notificará qué el tiempo restaurable más reciente que puede configurar. Puede usar la última hora restaurable o especificar la fecha y la hora deseadas. Ver a continuación:
Es bastante fácil de seguir pero requiere que preste atención y complete las especificaciones deseadas que necesita para que se lance la nueva instancia.
Aplicación de PITR con AWS CLI
Usar la AWS CLI puede ser bastante útil, especialmente si necesita incorporar esto con sus herramientas de automatización para su canalización de CI/CD. Para hacer esto, puede comenzar simplemente con,
[[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": []
}
}Ambos enfoques requieren tiempo para crear o preparar la instancia de la base de datos hasta que esté disponible y visible en la lista de instancias de la base de datos en su consola de AWS RDS.
Limitaciones de PITR de AWS RDS
Cuando utiliza AWS RDS, está vinculado a ellos como proveedor. Mover sus operaciones fuera de su sistema puede ser problemático. Aquí hay algunas cosas que debe considerar:
- El nivel de bloqueo del proveedor cuando se usa AWS RDS
- Su única opción para recuperarse a través de PITR requiere que inicie una nueva instancia que se ejecute en RDS
- No hay manera de recuperar usando el proceso PITR en un nodo externo que no esté en RDS
- Requiere que aprenda y esté familiarizado con sus herramientas y marco de seguridad.
Cómo aplicar un PITR con ClusterControl
ClusterControl realiza PITR de una manera simple pero directa (pero requiere que habilite o configure los requisitos previos para que se pueda usar PITR). Como se mencionó anteriormente, PITR para ClusterControl funciona de manera diferente a AWS RDS. Aquí hay una lista de dónde se puede aplicar PITR usando ClusterControl (a partir de la versión 1.7.6):
- Se aplica después de la copia de seguridad completa según las soluciones de método de copia de seguridad disponibles que admitimos para las bases de datos PostgreSQL, MySQL y MariaDB.
- Para PostgreSQL, solo se admite el método de respaldo pg_basebackup y es compatible para trabajar con PITR
- Para MySQL o MariaDB, solo se admite el método de copia de seguridad xtrabackup/mariabackup y es compatible para trabajar con PITR
- Aplicable a bases de datos MySQL o MariaDB, PITR solo se aplica si el nodo de origen de la copia de seguridad completa es el nodo de destino que se va a recuperar.
- Las bases de datos MySQL o MariaDB requieren que tenga habilitado el registro binario
- Aplicable a las bases de datos PostgreSQL, PITR se aplica solo al maestro/principal activo y requiere que tenga que habilitar el archivado WAL.
- PITR solo se puede aplicar al restaurar una copia de seguridad completa existente
Backup Management for ClusterControl se aplica a entornos donde las bases de datos no están completamente administradas y requieren acceso SSH, que es totalmente diferente de AWS RDS. Aunque comparten el mismo resultado que es recuperar datos, las soluciones de respaldo que están presentes en ClusterControl no pueden ser aplicables en AWS RDS. ClusterControl tampoco admite RDS para administración y monitoreo.
Uso de ClusterControl para PITR en PostgreSQL
Como se mencionó anteriormente de los requisitos previos para aprovechar el PITR, debe habilitar el archivado WAL. Esto se puede lograr haciendo clic en el ícono de ajustes como se muestra a continuación:
Dado que PITR se puede aplicar inmediatamente después de una copia de seguridad completa, solo puede ejecutar encuentre esta función en la lista de Copia de seguridad donde puede intentar restaurar una copia de seguridad existente. Para hacerlo, la secuencia de capturas de pantalla le mostrará cómo hacerlo:
Luego, restáurelo en el mismo host que el origen de la copia de seguridad tal como se tomó ,
Luego solo especifique la fecha y la hora,
Una vez que haya configurado y especificado la fecha y la hora, ClusterControl restaurará la copia de seguridad luego aplica el PITR una vez que se realiza la copia de seguridad. También puede verificar esto inspeccionando los registros de actividad del trabajo como se muestra a continuación,
Uso de ClusterControl para PITR en MySQL/MariaDB
PITR para MySQL o MariaDB no difiere del enfoque que tenemos arriba para PostgreSQL. Sin embargo, no existe una equivalencia de archivo WAL ni un botón u opción que pueda configurar y que sea necesario para habilitar la funcionalidad PITR. Dado que MySQL y MariaDB requieren que se pueda aplicar un PITR mediante registros binarios, en ClusterControl, esto se puede manejar en la pestaña Administrar. Ver a continuación:
Luego especifique la variable log_bin con el valor booleano correspondiente. Por ejemplo,
Una vez que el log_bin esté configurado en el nodo, asegúrese de tener el copia de seguridad realizada en el mismo nodo donde también aplicará el proceso de PITR. Esto se indica anteriormente en los requisitos previos. Alternativamente, también puede simplemente editar los archivos de configuración (/etc/my.cnf o /etc/mysql/my.cnf) y agregar log_bin=ON en la sección [mysqld], por ejemplo.
Cuando los registros binarios están habilitados y hay una copia de seguridad completa disponible, puede realizar el proceso PITR de la misma manera que la interfaz de usuario de PostgreSQL, pero con diferentes campos que puede completar. Puede especificar la fecha y la hora o especifique según el archivo y la posición del binlog (o la posición x e y). Ver a continuación:
Limitaciones de PITR de ClusterControl
En caso de que se esté preguntando qué puede y qué no puede hacer para PITR en ClusterControl, aquí está la lista a continuación:
- No existe una herramienta CLI s9s actual que admita el proceso PITR, por lo que no es posible automatizar o integrar su canalización de CI/CD.
- Sin compatibilidad con PITR para nodos externos
- No hay compatibilidad con PITR cuando el origen de la copia de seguridad es diferente del nodo de destino
- No hay tal notificación periódica de cuál es el período de tiempo más reciente en el que puede solicitar PITR
Conclusión
Ambas herramientas tienen diferentes enfoques y diferentes soluciones para el entorno de destino. La conclusión clave es que AWS RDS tiene su propio PITR, que es más rápido, pero solo se aplica si su base de datos está alojada en RDS y está vinculado a un bloqueo de proveedor.
ClusterControl le permite aplicar libremente el proceso PITR a cualquier centro de datos o local, siempre que se tengan en cuenta los requisitos previos. Su objetivo es recuperar los datos. Independientemente de sus limitaciones, se basa en cómo utilizará la solución de acuerdo con el entorno arquitectónico que esté utilizando.
