Amazon Relational Database Service (AWS RDS) est un service de base de données entièrement géré qui peut prendre en charge plusieurs moteurs de base de données. Parmi ceux pris en charge figurent PostgreSQL, MySQL et MariaDB. ClusterControl, d'autre part, est un logiciel de gestion et d'automatisation de bases de données qui prend également en charge la gestion des sauvegardes pour les bases de données open source PostgreSQL, MySQL et MariaDB.
Bien que RDS ait été largement adopté par de nombreuses entreprises, certaines ne connaissent peut-être pas le fonctionnement de leur récupération ponctuelle (PITR) ni la manière dont elle peut être utilisée.
Plusieurs des moteurs de base de données utilisés par Amazon RDS ont des considérations particulières lors de la restauration à partir d'un moment précis, et dans ce blog, nous expliquerons comment cela fonctionne pour PostgreSQL, MySQL et MariaDB. Nous comparerons également ses différences avec la fonction PITR dans ClusterControl.
Qu'est-ce que la récupération ponctuelle (PITR) ?
Si vous n'êtes pas encore familiarisé avec la planification de la reprise après sinistre (DRP) ou la planification de la continuité des activités (BCP), vous devez savoir que le PITR est l'une des pratiques standard importantes pour la gestion des bases de données. Comme mentionné dans notre blog précédent, Point In Time Recovery (PITR) consiste à restaurer la base de données à tout moment dans le passé. Pour pouvoir le faire, nous devrons restaurer une sauvegarde complète, puis PITR a lieu en appliquant toutes les modifications qui se sont produites à un moment précis que vous souhaitez récupérer.
Récupération ponctuelle (PITR) avec AWS RDS
AWS RDS gère le PITR différemment de la manière traditionnelle commune à une base de données sur site. Le résultat final partage le même concept, mais avec AWS RDS, la sauvegarde complète est un instantané, il applique ensuite le PITR (qui est stocké dans S3), puis lance une nouvelle instance de base de données (différente).
La méthode courante vous oblige à utiliser une logique (en utilisant pg_dump, mysqldump, mydumper) ou une physique (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) pour votre sauvegarde complète avant d'appliquer le PITR.
AWS RDS vous demandera de lancer une nouvelle instance de base de données, alors que l'approche traditionnelle vous permet de stocker de manière flexible le PITR sur le même nœud de base de données où la sauvegarde a été effectuée ou de cibler une autre instance de base de données (existante) qui doit être récupéré ou sur une nouvelle instance de base de données.
Lors de la création de votre instance AWS RDS, les sauvegardes automatisées seront activées. Amazon RDS effectue automatiquement un instantané quotidien complet de vos données. Les planifications d'instantanés peuvent être définies lors de la création dans votre fenêtre de sauvegarde préférée. Lorsque les sauvegardes automatisées sont activées, AWS capture également les journaux de transactions vers Amazon S3 toutes les 5 minutes en enregistrant toutes vos mises à jour de base de données. Une fois que vous lancez une récupération ponctuelle, les journaux de transactions sont appliqués à la sauvegarde quotidienne la plus appropriée afin de restaurer votre instance de base de données à l'heure spécifique demandée.
Comment appliquer un PITR avec AWS RDS
L'application du PITR peut se faire de trois manières différentes. Vous pouvez utiliser AWS Management Console, l'AWS CLI ou l'API Amazon RDS une fois l'instance de base de données disponible. Vous devez également tenir compte du fait que les journaux de transactions sont capturés toutes les cinq minutes, puis stockés dans AWS S3.
Une fois que vous avez restauré une instance de base de données, le groupe de sécurité DB (SG) par défaut est appliqué à la nouvelle instance de base de données. Si vous avez besoin de la base de données personnalisée SG, vous pouvez la définir explicitement à l'aide d'AWS Management Console, de la commande AWS CLI modify-db-instance ou de l'opération ModifyDBInstance de l'API Amazon RDS une fois l'instance de base de données disponible.
PITR exige que vous identifiiez la dernière heure de restauration pour une instance de base de données. Pour ce faire, vous pouvez utiliser la commande describe-db-instances de l'AWS CLI et examiner la valeur renvoyée dans le champ LatestRestorableTime pour l'instance de base de données. Par exemple,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Application du PITR avec la console AWS
Pour appliquer le PITR dans la console AWS, connectez-vous à la console AWS → accédez à Amazon RDS → Bases de données → Sélectionnez (ou cliquez) l'instance de base de données souhaitée, puis cliquez sur Actions. Voir ci-dessous,
Une fois que vous essayez de restaurer via PITR, l'interface utilisateur de la console vous informe de ce qui est la dernière heure de restauration que vous pouvez définir. Vous pouvez utiliser la dernière heure de restauration ou spécifier la date et l'heure cibles souhaitées. Voir ci-dessous :
C'est assez facile à suivre mais cela vous oblige à faire attention et à remplir les spécifications souhaitées dont vous avez besoin pour lancer la nouvelle instance.
Application du PITR avec AWS CLI
L'utilisation de l'AWS CLI peut être très pratique, surtout si vous devez l'intégrer à vos outils d'automatisation pour votre pipeline CI/CD. Pour ce faire, vous pouvez commencer simplement par,
[[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": []
}
}Ces deux approches prennent du temps pour créer ou préparer l'instance de base de données jusqu'à ce qu'elle soit disponible et visible dans la liste des instances de base de données de votre console AWS RDS.
Limitations AWS RDS PITR
Lorsque vous utilisez AWS RDS, vous êtes lié à eux en tant que fournisseur. Déplacer vos opérations hors de leur système peut être gênant. Voici quelques éléments à prendre en compte :
- Le niveau de verrouillage du fournisseur lors de l'utilisation d'AWS RDS
- Votre seule option pour récupérer via PITR nécessite que vous lanciez une nouvelle instance s'exécutant sur RDS
- Aucun moyen de récupérer à l'aide du processus PITR vers un nœud externe qui n'est pas dans RDS
- Vous devez apprendre et vous familiariser avec leurs outils et leur cadre de sécurité.
Comment appliquer un PITR avec ClusterControl
ClusterControl exécute le PITR de manière simple, mais directe (mais vous devez activer ou définir les prérequis pour que le PITR puisse être utilisé). Comme indiqué précédemment, PITR pour ClusterControl fonctionne différemment d'AWS RDS. Voici une liste des endroits où le PITR peut être appliqué à l'aide de ClusterControl (à partir de la version 1.7.6) :
- S'applique après la sauvegarde complète en fonction des solutions de méthode de sauvegarde disponibles que nous prenons en charge pour les bases de données PostgreSQL, MySQL et MariaDB.
- Pour PostgreSQL, seule la méthode de sauvegarde pg_basebackup est prise en charge et compatible pour fonctionner avec PITR
- Pour MySQL ou MariaDB, seule la méthode de sauvegarde xtrabackup/mariabackup est prise en charge et compatible pour fonctionner avec PITR
- Applicable aux bases de données MySQL ou MariaDB, le PITR s'applique uniquement si le nœud source de la sauvegarde complète est le nœud cible à restaurer.
- les bases de données MySQL ou MariaDB nécessitent que la journalisation binaire soit activée
- Applicable aux bases de données PostgreSQL, PITR s'applique uniquement au maître/primaire actif et nécessite que vous deviez activer l'archivage WAL.
- Le PITR ne peut être appliqué que lors de la restauration d'une sauvegarde complète existante
Backup Management for ClusterControl s'applique aux environnements où les bases de données ne sont pas entièrement gérées et nécessitent un accès SSH totalement différent d'AWS RDS. Bien qu'elles partagent le même résultat qui est de récupérer des données, les solutions de sauvegarde présentes dans ClusterControl ne peuvent pas être applicables dans AWS RDS. ClusterControl ne prend pas non plus en charge RDS pour la gestion et la surveillance.
Utilisation de ClusterControl pour PITR dans PostgreSQL
Comme mentionné précédemment parmi les prérequis pour tirer parti du PITR, vous devez activer l'archivage WAL. Ceci peut être réalisé en cliquant sur l'icône d'engrenage comme indiqué ci-dessous :
Étant donné que PITR peut être appliqué juste après une sauvegarde complète, vous ne pouvez exécuter trouvez cette fonctionnalité dans la liste de sauvegarde où vous pouvez tenter de restaurer une sauvegarde existante. Pour ce faire, la séquence de captures d'écran vous montrera comment procéder :
Puis restaurez-le sur le même hôte que la source de la sauvegarde prise ,
Ensuite, spécifiez simplement la date et l'heure,
Une fois que vous avez défini et spécifié la date et l'heure, ClusterControl restaurera la sauvegarde applique ensuite le PITR une fois la sauvegarde effectuée. Vous pouvez également vérifier cela en inspectant les journaux d'activité des tâches comme ci-dessous,
Utilisation de ClusterControl pour PITR dans MySQL/MariaDB
PITR pour MySQL ou MariaDB ne diffère pas de l'approche que nous avons ci-dessus pour PostgreSQL. Cependant, il n'y a pas d'équivalence d'archivage WAL ni de bouton ou d'option que vous pouvez définir qui soit nécessaire pour activer la fonctionnalité PITR. Étant donné que MySQL et MariaDB exigent qu'un PITR puisse être appliqué à l'aide de journaux binaires, dans ClusterControl, cela peut être géré sous l'onglet Gérer. Voir ci-dessous :
Ensuite, spécifiez la variable log_bin avec la valeur booléenne correspondante. Par exemple,
Une fois que le log_bin est défini sur le nœud, assurez-vous que vous disposez du sauvegarde effectuée sur le même nœud où vous appliquerez également le processus de PITR. Ceci est indiqué plus haut dans les prérequis. Alternativement, vous pouvez également simplement modifier les fichiers de configuration (/etc/my.cnf ou /etc/mysql/my.cnf) et ajouter le log_bin=ON sous la section [mysqld], par exemple.
Lorsque les journaux binaires sont activés et qu'une sauvegarde complète est disponible, vous pouvez alors effectuer le processus PITR de la même manière que l'interface utilisateur PostgreSQL, mais avec différents champs que vous pouvez remplir. Vous pouvez spécifier la date et l'heure ou spécifier en fonction du fichier et de la position du binlog (ou de la position x &y). Voir ci-dessous :
Limitations PITR de ClusterControl
Au cas où vous vous demanderiez ce que vous pouvez et ne pouvez pas faire pour PITR dans ClusterControl, voici la liste ci-dessous :
- Aucun outil CLI s9s actuel ne prend en charge le processus PITR, il n'est donc pas possible de l'automatiser ou de l'intégrer à votre pipeline CI/CD.
- Aucune prise en charge PITR pour les nœuds externes
- Aucune prise en charge PITR lorsque la source de la sauvegarde est différente du nœud cible
- Il n'y a pas une telle notification périodique de la dernière période pendant laquelle vous pouvez postuler pour PITR
Conclusion
Les deux outils ont des approches différentes et des solutions différentes pour l'environnement cible. Les principaux points à retenir sont qu'AWS RDS a son propre PITR qui est plus rapide, mais qui n'est applicable que si votre base de données est hébergée sous RDS et que vous êtes lié à un fournisseur verrouillé.
ClusterControl vous permet d'appliquer librement le processus PITR à n'importe quel centre de données ou sur site tant que les prérequis sont pris en considération. Son but est de récupérer les données. Indépendamment de ses limites, cela dépend de la manière dont vous utiliserez la solution en fonction de l'environnement architectural que vous utilisez.
