Amazon Relational Database Service (AWS RDS) är en helt hanterad databastjänst som kan stödja flera databasmotorer. Bland de som stöds är PostgreSQL, MySQL och MariaDB. ClusterControl, å andra sidan, är en databashanterings- och automatiseringsprogramvara som också stöder säkerhetskopieringshantering för PostgreSQL, MySQL och MariaDB open source-databaser.
Medan RDS har anammats brett av många företag, kanske vissa inte är bekanta med hur deras Point-in-time Recovery (PITR) fungerar och hur det kan användas.
Flera av de databasmotorer som används av Amazon RDS har särskilda överväganden vid återställning från en specifik tidpunkt, och i den här bloggen kommer vi att täcka hur det fungerar för PostgreSQL, MySQL och MariaDB. Vi kommer också att jämföra hur det skiljer sig med PITR-funktionen i ClusterControl.
Vad är Point-in-Time Recovery (PITR)
Om du ännu inte är bekant med Disaster Recovery Planning (DRP) eller Business Continuity Planning (BCP), bör du veta att PITR är en av de viktiga standardrutinerna för databashantering. Som nämnts i vår tidigare blogg, innebär Point In Time Recovery (PITR) återställning av databasen när som helst i det förflutna. För att kunna göra detta kommer vi att behöva återställa en fullständig säkerhetskopia och sedan sker PITR genom att tillämpa alla ändringar som hände vid en specifik tidpunkt du vill återställa.
Point-in-time Recovery (PITR) med AWS RDS
AWS RDS hanterar PITR annorlunda än det traditionella sättet som är vanligt för en lokal databas. Slutresultatet delar samma koncept, men med AWS RDS är den fullständiga säkerhetskopian en ögonblicksbild, den tillämpar sedan PITR (som lagras i S3), och startar sedan en ny (annan) databasinstans.
Det vanliga sättet kräver att du antingen använder en logisk (med pg_dump, mysqldump, mydumper) eller en fysisk (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) för din fullständiga säkerhetskopia innan du använder PITR.
AWS RDS kommer att kräva att du startar en ny DB-instans, medan den traditionella metoden tillåter dig att flexibelt lagra PITR på samma databasnod där säkerhetskopieringen togs eller rikta in sig på en annan (befintlig) DB-instans som behöver återställning eller till en ny DB-instans.
När din AWS RDS-instans skapas kommer automatiska säkerhetskopieringar att aktiveras. Amazon RDS utför automatiskt en fullständig daglig ögonblicksbild av din data. Schema för ögonblicksbilder kan ställas in under skapandet i ditt föredragna backupfönster. Medan automatiska säkerhetskopieringar är aktiverade, fångar AWS också transaktionsloggar till Amazon S3 var 5:e minut och registrerar alla dina DB-uppdateringar. När du initierar en punkt-i-tidsåterställning tillämpas transaktionsloggar på den mest lämpliga dagliga säkerhetskopian för att återställa din DB-instans till den specifika begärda tiden.
Hur man applicerar en PITR med AWS RDS
Att tillämpa PITR kan göras på tre olika sätt. Du kan använda AWS Management Console, AWS CLI eller Amazon RDS API när DB-instansen är tillgänglig. Du måste också ta hänsyn till att transaktionsloggarna registreras var femte minut som sedan lagras i AWS S3.
När du återställer en DB-instans, tillämpas standard DB-säkerhetsgruppen (SG) på den nya DB-instansen. Om du behöver den anpassade db SG kan du uttryckligen definiera detta med AWS Management Console, AWS CLI modify-db-instance-kommandot eller Amazon RDS API ModifyDBInstance-operationen efter att DB-instansen är tillgänglig.
PITR kräver att du måste identifiera den senaste återställningstiden för en DB-instans. För att göra detta kan du använda kommandot AWS CLI describe-db-instances och titta på värdet som returneras i fältet LatestRestorableTime för DB-instansen. Till exempel,
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Tillämpa PITR med AWS-konsolen
För att tillämpa PITR i AWS-konsolen, logga in på AWS-konsolen → gå till Amazon RDS → Databaser → Välj (eller klicka) din önskade DB-instans och klicka sedan på Åtgärder. Se nedan,
När du försöker återställa via PITR kommer konsolens gränssnitt att meddela dig vad som är den senaste återställningstiden du kan ställa in. Du kan använda den senaste återställningsbara tiden eller ange önskat måldatum och tid. Se nedan:
Det är ganska lätt att följa men det kräver att du är uppmärksam och fyller i önskade specifikationer du behöver för att den nya instansen ska lanseras.
Tillämpa PITR med AWS CLI
Att använda AWS CLI kan vara ganska praktiskt, särskilt om du behöver integrera detta med dina automationsverktyg för din CI/CD-pipeline. För att göra detta kan du enkelt börja med,
[[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": []
}
}Båda dessa tillvägagångssätt tar tid att skapa eller förbereda databasinstansen tills den blir tillgänglig och kan visas i listan över databasinstanser i din AWS RDS-konsol.
AWS RDS PITR-begränsningar
När du använder AWS RDS är du bunden till dem som leverantör. Att flytta ut din verksamhet från deras system kan vara besvärligt. Här är några saker du måste tänka på:
- Nivån på leverantörslåsning vid användning av AWS RDS
- Ditt enda alternativ att återställa via PITR kräver att du startar en ny instans som körs på RDS
- Du kan inte återställa med PITR-processen till en extern nod som inte finns i RDS
- Kräver att du lär dig och är bekant med deras verktyg och säkerhetsramverk.
Hur man tillämpar en PITR med ClusterControl
ClusterControl utför PITR på ett enkelt men okomplicerat sätt (men kräver att du måste aktivera eller ställa in förutsättningarna så att PITR kan användas). Som diskuterats tidigare fungerar PITR för ClusterControl annorlunda än AWS RDS. Här en lista över var PITR kan tillämpas med ClusterControl (från och med version 1.7.6):
- Gäller efter den fullständiga säkerhetskopieringen baserat på de tillgängliga säkerhetskopieringsmetodlösningarna som vi stöder för databaser PostgreSQL, MySQL och MariaDB.
- För PostgreSQL stöds endast säkerhetskopieringsmetoden pg_basebackup och är kompatibel för att arbeta med PITR
- För MySQL eller MariaDB, endast xtrabackup/mariabackup backup-metoden stöds och är kompatibel för att arbeta med PITR
- Gäller för MySQL- eller MariaDB-databaser, PITR gäller endast om källnoden för den fullständiga säkerhetskopian är målnoden som ska återställas.
- MySQL- eller MariaDB-databaser kräver att du har aktiverat binär loggning
- Gäller för PostgreSQL-databaser, PITR gäller endast den aktiva master/primären och kräver att du måste aktivera WAL-arkivering.
- PITR kan endast tillämpas vid återställning av en befintlig fullständig säkerhetskopia
Säkerhetskopieringshantering för ClusterControl är tillämplig för miljöer där databaser inte är helt hanterade och kräver SSH-åtkomst som är helt annorlunda än AWS RDS. Även om de delar samma resultat som är att återställa data, kan säkerhetskopieringslösningarna som finns i ClusterControl inte vara tillämpliga i AWS RDS. ClusterControl stöder inte heller RDS för hantering och övervakning.
Använda ClusterControl för PITR i PostgreSQL
Som tidigare nämnts av förutsättningarna för att utnyttja PITR, måste du aktivera WAL-arkivering. Detta kan uppnås genom att klicka på kugghjulsikonen som visas nedan:
Eftersom PITR kan tillämpas direkt efter en fullständig säkerhetskopiering kan du bara köra hitta den här funktionen under listan Säkerhetskopiering där du kan försöka återställa en befintlig säkerhetskopia. För att göra det kommer sekvensen av skärmdumpar att visa dig hur du gör det:
Återställ den sedan på samma värd som källan till säkerhetskopian som den togs ,
Ange sedan bara datum och tid,
När du är inställd och angett datum och tid återställs ClusterControl sedan säkerhetskopieringen tillämpar sedan PITR när säkerhetskopieringen är klar. Du kan också verifiera detta genom att inspektera jobbaktivitetsloggarna precis som nedan,
Använda ClusterControl för PITR i MySQL/MariaDB
PITR för MySQL eller MariaDB skiljer sig inte från metoden vi har ovan för PostgreSQL. Det finns dock ingen WAL-arkiveringsekvivalens eller en knapp eller ett alternativ du kan ställa in som krävs för att aktivera PITR-funktionaliteten. Eftersom MySQL och MariaDB kräver att en PITR kan tillämpas med binära loggar, i ClusterControl, kan detta hanteras under Manage-fliken. Se nedan:
Ange sedan log_bin-variabeln med motsvarande booleska värde. Till exempel,
När log_bin är inställd på noden, se till att du har hela säkerhetskopiering tagen på samma nod där du också kommer att tillämpa processen för PITR. Detta står tidigare i förutsättningarna. Alternativt kan du också bara redigera konfigurationsfilerna (/etc/my.cnf eller /etc/mysql/my.cnf) och till exempel lägga till log_bin=ON under [mysqld]-sektionen.
När binära loggar är aktiverade och en fullständig säkerhetskopia är tillgänglig kan du sedan göra PITR-processen på samma sätt som PostgreSQL UI men med olika fält som du kan fylla i. Du kan ange datum och tid eller specificera baserat på binloggens fil och position (eller x &y-position). Se nedan:
ClusterControl PITR-begränsningar
Om du undrar vad du kan och inte kan göra för PITR i ClusterControl, här är listan nedan:
- Det finns inget aktuellt s9s CLI-verktyg som stöder PITR-processen, så det är inte möjligt att automatisera eller integrera med din CI/CD-pipeline.
- Inget PITR-stöd för externa noder
- Inget PITR-stöd när källan till säkerhetskopian skiljer sig från målnoden
- Det finns inget sådant regelbundet meddelande om vad som är den senaste tidsperioden du kan ansöka om PITR
Slutsats
Båda verktygen har olika tillvägagångssätt och olika lösningar för målmiljön. Det viktigaste är att AWS RDS har sin egen PITR som är snabbare, men som bara är tillämplig om din databas är värd under RDS och du är bunden till en leverantörslåsning.
ClusterControl låter dig fritt tillämpa PITR-processen på vilket datacenter eller lokalt som helst så länge som förutsättningarna tas i beaktande. Målet är att återställa data. Oavsett dess begränsningar är den baserad på hur du kommer att använda lösningen i enlighet med den arkitektoniska miljö du använder.