Sammenligner Amazon RDS Point-in-Time Recovery med ClusterControl

Begge disse tilgange tager tid at oprette eller forberede databaseforekomsten, indtil den bliver tilgængelig og kan ses på listen over databaseforekomster i din AWS RDS-konsol.

AWS RDS PITR-begrænsninger

Når du bruger AWS RDS, er du bundet til dem som leverandør. Det kan være besværligt at flytte dine operationer ud af deres system. Her er nogle ting, du skal overveje:

• Niveauet af leverandørlås ved brug af AWS RDS
• Din eneste mulighed for at gendanne via PITR kræver, at du starter en ny instans, der kører på RDS
• Du kan på ingen måde gendanne ved hjælp af PITR-processen til en ekstern node, der ikke er i RDS
• Kræver, at du lærer og er fortrolig med deres værktøjer og sikkerhedsramme.

Sådan anvender du en PITR med ClusterControl

ClusterControl udfører PITR på en enkel, men ligetil måde (men kræver, at du skal aktivere eller indstille forudsætningerne, så PITR kan bruges). Som diskuteret tidligere fungerer PITR for ClusterControl anderledes end AWS RDS. Her er en liste over, hvor PITR kan anvendes ved hjælp af ClusterControl (fra version 1.7.6):

• Gælder efter den fulde backup baseret på de tilgængelige backupmetodeløsninger, som vi understøtter til PostgreSQL-, MySQL- og MariaDB-databaser.
  • For PostgreSQL er det kun pg_basebackup backup-metoden, der understøttes og er kompatibel til at arbejde med PITR
  • For MySQL eller MariaDB er kun xtrabackup/mariabackup backup-metoden understøttet og kompatibel til at arbejde med PITR
• Gælder for MySQL- eller MariaDB-databaser, PITR gælder kun, hvis kildenoden for den fulde backup er målknuden, der skal gendannes.
•  MySQL- eller MariaDB-databaser kræver, at du har aktiveret binær logning
• Gælder for PostgreSQL-databaser, PITR gælder kun for den aktive master/primære og kræver, at du skal aktivere WAL-arkivering.
• PITR kan kun anvendes ved gendannelse af en eksisterende fuld sikkerhedskopi

Backup Management for ClusterControl kan anvendes til miljøer, hvor databaser ikke er fuldt administreret og kræver SSH-adgang, som er helt anderledes end AWS RDS. Selvom de deler det samme resultat, som er at gendanne data, kan de backupløsninger, der findes i ClusterControl, ikke anvendes i AWS RDS. ClusterControl understøtter heller ikke RDS så godt til styring og overvågning.

Brug af ClusterControl til PITR i PostgreSQL

Som tidligere nævnt af forudsætningerne for at udnytte PITR, skal du aktivere WAL-arkivering. Dette kan opnås ved at klikke på tandhjulsikonet som vist nedenfor:

Da PITR kan anvendes lige efter en fuld sikkerhedskopiering, kan du kun køre find denne funktion under sikkerhedskopieringslisten, hvor du kan forsøge at gendanne en eksisterende sikkerhedskopi. For at gøre det vil sekvensen af ​​skærmbilleder vise dig, hvordan du gør det:

Gendan den derefter på den samme vært som kilden til sikkerhedskopieringen som taget ,

Så skal du blot angive dato og klokkeslæt,

Når du er indstillet og angivet dato og klokkeslæt, vil ClusterControl derefter gendanne sikkerhedskopien anvender derefter PITR, når sikkerhedskopieringen er færdig. Du kan også bekræfte dette ved at inspicere jobaktivitetsloggene ligesom nedenfor,

Brug af ClusterControl til PITR i MySQL/MariaDB

PITR for MySQL eller MariaDB adskiller sig ikke fra den tilgang, vi har ovenfor for PostgreSQL. Der er dog ingen WAL-arkiveringsækvivalens eller en knap eller mulighed, du kan indstille, som kræves for at aktivere PITR-funktionaliteten. Da MySQL og MariaDB kræver, at en PITR kan anvendes ved hjælp af binære logfiler, kan dette i ClusterControl håndteres under fanen Administrer. Se nedenfor:

Angiv derefter log_bin-variablen med den tilsvarende booleske værdi. For eksempel

Når log_bin er indstillet på noden, skal du sikre dig, at du har den fulde backup taget på den samme node, hvor du også vil anvende PITR-processen. Dette står tidligere i forudsætningerne. Alternativt kan du også bare redigere konfigurationsfilerne (/etc/my.cnf eller /etc/mysql/my.cnf) og f.eks. tilføje log_bin=ON under [mysqld] sektionen.

Når binære logfiler er aktiveret, og en fuld backup er tilgængelig, kan du derefter udføre PITR-processen på samme måde som PostgreSQL UI, men med forskellige felter, som du kan udfylde. Du kan angive dato og klokkeslæt eller specificer baseret på binlogens fil og position (eller x &y position). Se nedenfor:

ClusterControl PITR-begrænsninger

Hvis du undrer dig over, hvad du kan og ikke kan gøre for PITR i ClusterControl, her er listen nedenfor:

• Der er ikke noget aktuelt s9s CLI-værktøj, som understøtter PITR-processen, så det er ikke muligt at automatisere eller integrere til din CI/CD-pipeline.
• Ingen PITR-understøttelse for eksterne noder
• Ingen PITR-understøttelse, når kilden til sikkerhedskopieringen er forskellig fra målknuden
• Der er ingen sådan periodisk meddelelse om, hvad der er den seneste periode, du kan ansøge om PITR

Konklusion

Begge værktøjer har forskellige tilgange og forskellige løsninger til målmiljøet. Det vigtigste er, at AWS RDS har sin egen PITR, som er hurtigere, men kun gælder, hvis din database er hostet under RDS, og du er bundet til en leverandørlås. 

ClusterControl giver dig mulighed for frit at anvende PITR-processen til et hvilket som helst datacenter eller on-premise, så længe forudsætningerne tages i betragtning. Dets mål er at gendanne dataene. Uanset dens begrænsninger er det baseret på, hvordan du vil bruge løsningen i overensstemmelse med det arkitektoniske miljø, du bruger.