Hoppa till innehållet
Stackship-dokumentation English

PostgreSQLAdministratörerMaskinöversatt

Vad PostgreSQL-säkerhetskopior kräver

Hur hanterade PostgreSQL-kluster arkiverar till plattformens mål för säkerhetskopiering — beroendena, objekten operatorn projicerar in i varje namnrymd, sökvägarna och lagringstiden — och vad som händer utan ett mål.

Användarnas reglage Aktivera säkerhetskopieringar fungerar bara när plattformen kan skriva till ett mål för säkerhetskopiering. Den här sidan beskriver vad det kräver; användarsidan finns i Säkerhetskopior och återställning till tidpunkt.

Beroendena

PostgreSQL-säkerhetskopior använder CloudNativePG:s Barman Cloud-plugin, som skriver till samma bucket i objektlagringen som Velero säkerhetskopierar plattformen till. Installationsprogrammet installerar båda som plattformsberoenden: velero, och cnpg-barman-plugin, som är beroende av cert-manager, cnpg-operator och velero och inte är valfritt.

Själva målet är Veleros: hemligheten velero med inloggningsuppgifter (nyckeln cloud, med aws_access_key_id och aws_secret_access_key) och BackupStorageLocation default, båda i namnrymden velero. Från lagringsplatsen tar operatorn bucketen, regionen (us-east-1 när ingen är angiven), slutpunktens URL och, när den finns, slutpunktens CA-certifikat. Ändra målet via plattformens inställningar för säkerhetskopiering — se Livscykelhantering — i stället för att redigera Veleros objekt.

Vad operatorn projicerar

Varannan minut skriver Stackship-operatorn en hemlighet med inloggningsuppgifter och en Barman ObjectStore, båda med namnet stackship-backup-target, till:

  • plattformens namnrymd, stackship-system, alltid;
  • varje namnrymd som innehåller ett CloudNativePG-kluster som arkiverar till stackship-backup-target — det vill säga varje resursgrupp med ett PostgreSQL-kluster som har säkerhetskopiering påslagen.

Den tar bort dem igen från en namnrymd när inget sådant kluster finns kvar där. ObjectStore pekar på:

Namnrymd Mål
Plattformens namnrymd s3://<bucket>/platform/postgres/
En resursgrupps namnrymd s3://<bucket>/boundaries/<boundary-id>/<namespace>/postgres/

WAL och baskopior komprimeras med gzip. Inom den sökvägen arkiverar varje kluster under ett eget namn: klustrets namn och ett slumpat suffix på sex tecken, som behålls så länge säkerhetskopieringen är på; slås säkerhetskopieringen av och på igen börjar ett nytt namn. Varje återställning flyttar klustret till nästa generation av det namnet — -g2, -g3 och så vidare — så att det aldrig skriver till ett arkiv som redan innehåller data.

Lagringstid

Varje projicerad ObjectStore har lagringspolicyn 30d, och pluginet tillämpar den var 30:e minut: det behåller det som behövs för att återställa till vilket ögonblick som helst de senaste 30 dagarna och tar bort äldre baskopior och WAL. Det är den enda lagringstid som gäller för användarnas PostgreSQL-säkerhetskopior; den Backup Retention Policy en användare anger på ett kluster, och den livslängd som begärs när en ögonblicksbild tas, ändrar den inte.

Pluginet tillämpar den från instanserna i ett körande kluster, på det arkiv som klustret skriver till. Arkiv som inget kluster skriver till längre — tidigare generationer efter en återställning, det gamla namnet efter att säkerhetskopieringen slagits av och på, och arkiven för borttagna kluster — rensas aldrig och ligger kvar i bucketen tills någon tar bort dem.

Schemalagda ögonblicksbilder

Ett kluster med säkerhetskopiering påslagen får en BackupPolicy bredvid sig, ägd av klustret. Operatorn gör om den till en CloudNativePG ScheduledBackup med namnet <cluster>-policy, med policyns cron-uttryck med fem fält i UTC. Den första schemalagda säkerhetskopian tas vid nästa schemalagda tidpunkt, inte när schemat skapas, och när policyn pausas stängs den av. De schemalagda säkerhetskopiorna ägs av CloudNativePG-klustret (backupOwnerReference: cluster), så en återställning, som tar bort och återskapar klustret, tar bort dem; deras data finns kvar i arkivet.

Plattformens egen säkerhetskopia

Plattformens filsystemsäkerhetskopia med Velero hoppar över PostgreSQL-volymerna: varje instanspodd har backup.velero.io/backup-volumes-excludes: pgdata,pg-wal. Ett PostgreSQL-kluster återställs bara någonsin från sitt arkiv, som en kopia av dess volymer inte kan ersätta.

Utan ett mål

När Veleros hemlighet eller lagringsplats saknas, eller inte anger någon bucket eller några inloggningsuppgifter, projicerar operatorn ingenting — och tar inte bort något den projicerat tidigare. En användare kan fortfarande slå på säkerhetskopiering, men klustret har ingenstans att arkivera till: ingen ögonblicksbild blir klar, en ögonblicksbild eller en återställning avvisas när klustret rapporterar att arkiveringen misslyckas, och återställning till tidpunkt har inget fönster.

Så länge arkiveringen misslyckas behåller PostgreSQL varje WAL-segment som inte har arkiverats, så klustrets volymer fylls tills målet fungerar igen. Detsamma gäller när ett fungerande mål blir fullt eller slutar gå att nå.