De Amazon Relational Database Service (AWS RDS) is een volledig beheerde databaseservice die meerdere database-engines kan ondersteunen. Onder de ondersteunde zijn PostgreSQL, MySQL en MariaDB. ClusterControl, aan de andere kant, is databasebeheer- en automatiseringssoftware die ook back-upverwerking ondersteunt voor PostgreSQL-, MySQL- en MariaDB open source-databases.
Hoewel RDS door veel bedrijven algemeen is omarmd, zijn sommigen misschien niet bekend met hoe hun Point-in-time Recovery (PITR) werkt en hoe het kan worden gebruikt.
Verscheidene database-engines die door Amazon RDS worden gebruikt, hebben speciale overwegingen bij het herstellen vanaf een specifiek tijdstip, en in deze blog bespreken we hoe het werkt voor PostgreSQL, MySQL en MariaDB. We zullen ook vergelijken hoe het verschilt met de PITR-functie in ClusterControl.
Wat is Point-in-Time Recovery (PITR)
Als u nog niet bekend bent met Disaster Recovery Planning (DRP) of Business Continuity Planning (BCP), moet u weten dat PITR een van de belangrijke standaardpraktijken is voor databasebeheer. Zoals vermeld in onze vorige blog, houdt Point In Time Recovery (PITR) in dat de database op elk willekeurig moment in het verleden wordt hersteld. Om dit te kunnen doen, moeten we een volledige back-up terugzetten en vervolgens vindt PITR plaats door alle wijzigingen toe te passen die zijn gebeurd op een specifiek tijdstip dat u wilt herstellen.
Point-in-time Recovery (PITR) met AWS RDS
AWS RDS verwerkt PITR anders dan de traditionele manier die gebruikelijk is voor een on-prem database. Het eindresultaat deelt hetzelfde concept, maar met AWS RDS is de volledige back-up een momentopname, het past vervolgens de PITR toe (die is opgeslagen in S3) en start vervolgens een nieuwe (andere) database-instantie.
De gebruikelijke manier vereist dat u een logische (met pg_dump, mysqldump, mydumper) of een fysieke (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) gebruikt voor uw volledige back-up voordat u de PITR toepast.
AWS RDS vereist dat u een nieuwe DB-instantie start, terwijl u met de traditionele benadering de PITR flexibel kunt opslaan op hetzelfde databaseknooppunt waar de back-up is gemaakt of een andere (bestaande) DB-instantie kunt targeten die moet worden hersteld of naar een nieuwe DB-instantie.
Bij het maken van uw AWS RDS-instantie worden automatische back-ups ingeschakeld. Amazon RDS maakt automatisch een volledige dagelijkse momentopname van uw gegevens. Snapshot-schema's kunnen tijdens het maken worden ingesteld in het back-upvenster van uw voorkeur. Hoewel automatische back-ups zijn ingeschakeld, legt AWS ook elke 5 minuten transactielogboeken vast op Amazon S3 en worden al uw database-updates geregistreerd. Zodra u een herstel op een bepaald tijdstip start, worden transactielogboeken toegepast op de meest geschikte dagelijkse back-up om uw DB-instantie te herstellen naar de specifiek gevraagde tijd.
Een PITR toepassen met AWS RDS
PITR toepassen kan op drie verschillende manieren. U kunt de AWS Management Console, de AWS CLI of de Amazon RDS API gebruiken zodra de DB-instantie beschikbaar is. U moet er ook rekening mee houden dat de transactielogboeken elke vijf minuten worden vastgelegd en vervolgens worden opgeslagen in AWS S3.
Zodra u een DB-instantie herstelt, wordt de standaard DB-beveiligingsgroep (SG) toegepast op de nieuwe DB-instantie. Als u de aangepaste db SG nodig heeft, kunt u dit expliciet definiëren met behulp van de AWS Management Console, de AWS CLI-opdracht modify-db-instance of de Amazon RDS API ModifyDBInstance-bewerking nadat de DB-instantie beschikbaar is.
PITR vereist dat u de meest recente herstelbare tijd voor een DB-instantie moet identificeren. Om dit te doen, kunt u de opdracht AWS CLI description-db-instances gebruiken en kijken naar de waarde die wordt geretourneerd in het veld LatestRestorableTime voor het DB-exemplaar. Bijvoorbeeld,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",PITR toepassen met AWS Console
Om PITR in AWS Console toe te passen, logt u in op AWS Console → ga naar Amazon RDS → Databases → Selecteer (of klik) uw gewenste DB-instantie en klik vervolgens op Acties. Zie hieronder,
Zodra u probeert te herstellen via PITR, zal de gebruikersinterface van de console u laten weten wat de meest recente herstelbare tijd die u kunt instellen. U kunt de laatste herstelbare tijd gebruiken of uw gewenste streefdatum en -tijd specificeren. Zie hieronder:
Het is vrij eenvoudig te volgen, maar het vereist dat je oplet en invult de gewenste specificaties die u nodig heeft om de nieuwe instantie te lanceren.
PITR toepassen met AWS CLI
Het gebruik van de AWS CLI kan best handig zijn, vooral als je dit moet opnemen in je automatiseringstools voor je CI/CD-pijplijn. Om dit te doen, kunt u eenvoudig beginnen met,
[[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": []
}
}Beide benaderingen nemen tijd in beslag om de database-instantie te maken of voor te bereiden totdat deze beschikbaar en zichtbaar is in de lijst met database-instanties in uw AWS RDS-console.
AWS RDS PITR-beperkingen
Als u AWS RDS gebruikt, bent u als leverancier aan hen gebonden. Het verplaatsen van uw activiteiten uit hun systeem kan lastig zijn. Hier zijn enkele dingen waarmee u rekening moet houden:
- Het niveau van vendor-lock-in bij gebruik van AWS RDS
- Uw enige optie om te herstellen via PITR vereist dat u een nieuwe instantie start die draait op RDS
- U kunt op geen enkele manier herstellen met het PITR-proces naar een extern knooppunt dat niet in RDS zit
- Vereist dat je hun tools en beveiligingsframework leert kennen en ermee bekend bent.
Een PITR toepassen met ClusterControl
ClusterControl voert PITR uit op een eenvoudige, maar duidelijke manier (maar vereist dat u de vereisten inschakelt of instelt zodat PITR kan worden gebruikt). Zoals eerder besproken, werkt PITR voor ClusterControl anders dan AWS RDS. Hier een lijst van waar PITR kan worden toegepast met ClusterControl (vanaf versie 1.7.6):
- Van toepassing na de volledige back-up op basis van de beschikbare back-upmethodeoplossingen die we ondersteunen voor PostgreSQL-, MySQL- en MariaDB-databases.
- Voor PostgreSQL wordt alleen de pg_basebackup back-upmethode ondersteund en compatibel om met PITR te werken
- Voor MySQL of MariaDB wordt alleen de xtrabackup/mariabackup-back-upmethode ondersteund en compatibel om met PITR te werken
- Van toepassing op MySQL- of MariaDB-databases, is PITR alleen van toepassing als het bronknooppunt van de volledige back-up het doelknooppunt is dat moet worden hersteld.
- Voor MySQL- of MariaDB-databases moet binaire logboekregistratie zijn ingeschakeld
- Van toepassing op PostgreSQL-databases, is PITR alleen van toepassing op de actieve master/primary en moet u WAL-archivering inschakelen.
- PITR kan alleen worden toegepast bij het herstellen van een bestaande volledige back-up
Back-upbeheer voor ClusterControl is van toepassing op omgevingen waar databases niet volledig worden beheerd en vereist SSH-toegang die totaal verschilt van AWS RDS. Hoewel ze hetzelfde resultaat hebben, namelijk het herstellen van gegevens, kunnen de back-upoplossingen die aanwezig zijn in ClusterControl niet worden toegepast in AWS RDS. ClusterControl ondersteunt ook niet RDS voor beheer en monitoring.
ClusterControl gebruiken voor PITR in PostgreSQL
Zoals eerder vermeld bij de vereisten om gebruik te maken van de PITR, moet u WAL-archivering inschakelen. Dit kan worden bereikt door op het tandwielpictogram te klikken, zoals hieronder weergegeven:
Aangezien PITR direct na een volledige back-up kan worden toegepast, kunt u alleen uitvoeren vind deze functie onder de lijst Back-up waar u kunt proberen een bestaande back-up te herstellen. Om dat te doen, zal de reeks schermafbeeldingen u laten zien hoe u dit moet doen:
Herstel het vervolgens op dezelfde host als de bron van de gemaakte back-up ,
Geef vervolgens de datum en tijd op,
Zodra u de datum en tijd hebt ingesteld en de datum en tijd hebt opgegeven, herstelt ClusterControl de de back-up en pas vervolgens de PITR toe zodra de back-up is voltooid. U kunt dit ook controleren door de taakactiviteitenlogboeken te bekijken, zoals hieronder,
ClusterControl gebruiken voor PITR in MySQL/MariaDB
PITR voor MySQL of MariaDB verschilt niet van de benadering die we hierboven hebben voor PostgreSQL. Er is echter geen WAL-archiveringequivalentie, noch een knop of optie die u kunt instellen die nodig is om de PITR-functionaliteit in te schakelen. Aangezien MySQL en MariaDB vereisen dat een PITR kan worden toegepast met behulp van binaire logboeken, kan dit in ClusterControl worden afgehandeld op het tabblad Beheren. Zie hieronder:
Geef vervolgens de log_bin-variabele op met de bijbehorende booleaanse waarde. Bijvoorbeeld,
Zodra de log_bin op het knooppunt is ingesteld, moet u ervoor zorgen dat u de volledige back-up genomen op hetzelfde knooppunt waar u ook het proces van PITR gaat toepassen. Dit staat eerder in de voorwaarden vermeld. Als alternatief kunt u ook gewoon de configuratiebestanden bewerken (/etc/my.cnf of /etc/mysql/my.cnf) en bijvoorbeeld log_bin=ON toevoegen onder de sectie [mysqld].
Als binaire logboeken zijn ingeschakeld en er een volledige back-up beschikbaar is, kunt u het PITR-proces op dezelfde manier uitvoeren als de PostgreSQL-gebruikersinterface, maar met verschillende velden die u kunt invullen. U kunt de datum en tijd of specificeer op basis van het bestand en de positie van de binlog (of de x &y-positie). Zie hieronder:
ClusterControl PITR-beperkingen
In het geval u zich afvraagt wat u wel en niet kunt doen voor PITR in ClusterControl, hier is de onderstaande lijst:
- Er is geen huidige s9s CLI-tool die het PITR-proces ondersteunt, dus het is niet mogelijk om te automatiseren of te integreren in uw CI/CD-pipeline.
- Geen PITR-ondersteuning voor externe knooppunten
- Geen PITR-ondersteuning wanneer de bron van de back-up verschilt van het doelknooppunt
- Er is niet zo'n periodieke melding van wat de meest recente periode is dat u PITR kunt aanvragen
Conclusie
Beide tools hebben verschillende benaderingen en verschillende oplossingen voor de doelomgeving. Het belangrijkste is dat AWS RDS zijn eigen PITR heeft, die sneller is, maar alleen van toepassing is als uw database onder RDS wordt gehost en u bent gebonden aan een vendor lock-in.
ClusterControl stelt u in staat om het PITR-proces vrijelijk toe te passen op elk datacenter of on-premise, zolang rekening wordt gehouden met de vereisten. Het doel is om de gegevens te herstellen. Ongeacht de beperkingen, het is gebaseerd op hoe u de oplossing gaat gebruiken in overeenstemming met de architecturale omgeving die u gebruikt.