Hanterade databaser

Frostmoln kör hanterade PostgreSQL- och MySQL-instanser åt dig — plattformen tillhandahåller den virtuella maskinen, kopplar på beständig lagring, konfigurerar servern och ger dig en färdig anslutning. Du hanterar dina data; vi hanterar infrastrukturen under.

Välja typ och version

Välj PostgreSQL eller MySQL när du skapar instansen. Varje typ erbjuder flera versioner, och rullgardinsmenyn vid skapandet är källan till sanning för vad du kan starta just nu — för närvarande ungefär PostgreSQL 14–18 och MySQL 8.0 / 8.4.

Varje version har en livscykelstatus:

Status	Startbar?	Betydelse
current	Ja	Nyaste fullt stödda utgåvan
supported	Ja	Fullt stödd
deprecated	Ja (markerad)	Fortfarande startbar, visas med en (deprecated)-markering — planera att gå ifrån
eol	Nej	Slut på livscykeln — dold från rullgardinsmenyn vid skapandet

Den rekommenderade versionen för varje typ är markerad med (Recommended). Versioner som nått slutet på livscykeln samt förhandsversioner erbjuds inte för nya instanser.

Dimensionering

Instansstorlekar använder storleksfamiljen db.gp1.<size> (generellt ändamål):

Storlek	vCPU	RAM
db.gp1.small	1	4 GB
db.gp1.medium	2	8 GB
db.gp1.large	4	16 GB
db.gp1.xlarge	8	32 GB
db.gp1.2xlarge	16	64 GB

Du väljer lagring separat (20–1000 GB). Dialogrutan vid skapandet visar den uppskattade kostnaden innan du bekräftar.

Skapa en instans

I portalen, gå till Databaser → Instanser → Skapa och välj typ, version, storlek, lagringsstorlek och vilket VPC + subnät instansen ansluts till. Aktivera valfritt hög tillgänglighet för PostgreSQL.

Från CLI:n

Livscykelkommandon är typspecifika (fm database postgres … / fm database mysql …); den typöverskridande gruppen fm database … listar över alla typer.

fm database postgres instance create \
  --name app-db \
  --version 16 \
  --flavor db.gp1.medium \
  --storage 100 \
  --vpc my-vpc \
  --subnet my-subnet

# MySQL är symmetriskt:
fm database mysql instance create --name app-db --version 8.4 --flavor db.gp1.small --storage 40 --vpc my-vpc --subnet my-subnet

# Typöverskridande vyer:
fm database instance list
fm database version list

Med Terraform

resource "frostmoln_postgres_instance" "app" {
  name             = "app-db"
  version          = "16"
  flavor_id        = "db.gp1.medium"
  storage_gb       = 100
  vpc_id           = frostmoln_vpc.main.id
  subnet_id        = frostmoln_subnet.main.id
  ha_enabled       = true
}

Anslut

Efter tillhandahållandet visar instansens detaljsida anslutningsuppgifterna bakom en Visa autentiseringsuppgifter-knapp:

• Värd — instansens privata adress
• Port — 5432 (PostgreSQL) eller 3306 (MySQL)
• Användarnamn — pgadmin (PostgreSQL) eller mysqladmin (MySQL)
• Lösenord — genererat åt dig (kan roteras)
• en färdig anslutnings-URI

Databaser är nåbara från instanser på samma VPC; flödet vid skapandet öppnar databasporten i instansens säkerhetsgrupp. Anslut som med vilken standardklient som helst:

psql "host=<host> port=5432 user=pgadmin dbname=postgres"

Tips

Behandla administratörsuppgifterna som vilken hemlighet som helst — lagra dem i Secrets eller din applikations hemlighetslagring, inte i versionshanteringen.

Hög tillgänglighet

Hög tillgänglighet kör en synkron standby vid sidan av primärinstansen. Medan synkron replikering är aktiv finns en commit som primärinstansen har bekräftat till din klient redan på standbyns disk, så en failover förlorar inget som har bekräftats.

• Endast PostgreSQL. En MySQL-instans kan inte skapas med hög tillgänglighet — begäran avvisas.
• Väljs när instansen skapas och ligger fast under hela dess livstid. Hög tillgänglighet kan varken läggas till på en instans som redan körs eller tas bort från den; att ändra inställningen i efterhand avvisas. För att flytta en befintlig databas till en instans med hög tillgänglighet skapar du en ny instans och migrerar dina data.
• Skyddet gäller mellan värdar, inte mellan tillgänglighetszoner. Paret delar instansens VPC och subnät, och därmed en tillgänglighetszon. De två noderna placeras normalt på skilda fysiska värdar; när värdkapaciteten är knapp kan paret dela värd, så åtskillnaden är en strävan och ingen garanti. Hög tillgänglighet över tillgänglighetszoner erbjuds inte.

Aktivera den i portalens skapandeformulär, med --ha på CLI:n eller med ha_enabled = true i Terraform.

HA-status

En instans med hög tillgänglighet visar en HA-status på sin detaljsida och i instanslistan:

Status	Betydelse
healthy	En synkron standby strömmar och skyddar primärinstansens skrivningar.
degraded	En nod betjänar trafiken och ingenting skyddar dess skrivningar — standbyn är otillgänglig eller byggs om efter en failover.
provisioning	Paret håller fortfarande på att byggas upp.
failing_over	En failover pågår.
no_standby	Instansen saknar standby (se nedan).

Vad som garanteras, och när

En commit är skyddad mot en failover endast om den bekräftades medan synkron replikering var aktiv. HA-statusen rapporterar det tillståndet med en kort fördröjning — upp till ungefär en minut — så en status som visar healthy är inte i sig ett bevis för att den commit du just gjorde redan finns på standbyn.

Om standbyn slutar strömma blockeras skrivningar kortvarigt och fortsätter sedan asynkront: plattformen släpper den synkrona replikeringen så att instansen fortsätter ta emot skrivningar, och rapporterar den som degraded. Det är en medveten avvägning — databasen förblir tillgänglig, och priset är att commits som bekräftas under det försämrade fönstret ännu inte finns på standbyn och kan gå förlorade om en failover sker innan standbyn har hunnit ikapp. När standbyn är i synk igen återgår statusen till healthy och nya commits är skyddade på nytt.

WARNING

Håll ett öga på HA-statusen för allt som inte får förlora en skrivning. degraded är det fönster där en failover kan kosta dig bekräftade commits.

Failover

En failover begärs av dig — från portalen, med fm-CLI:n eller via API:et. Plattformen övervakar paret kontinuerligt och rapporterar dess HA-status; att befordra standbyn är ett beslut du fattar, inte något plattformen gör på egen hand.

En failover accepteras bara medan HA-statusen är healthy — att växla över till en standby som inte är i synk skulle kasta bort bekräftade skrivningar. Den har också en budget: högst 2 failover per instans per 24 timmar, med minst 30 minuter mellan försöken. En instans som har gjort failover två gånger på ett dygn har ett fel som ytterligare en failover inte åtgärdar.

Din anslutningsadress ändras inte. Det är hela poängen med konstruktionen — du behöver inte peka om din applikation, slå upp ett nytt namn eller uppdatera en anslutningssträng. Öppna anslutningar bryts kortvarigt och måste återupprättas, så din klient eller anslutningspool behöver sedvanlig återanslutningslogik; därefter ansluter allt till samma adress igen.

Instanser som skapades innan hög tillgänglighet lanserades

Ett fåtal instanser skapades med flaggan för hög tillgänglighet satt innan någon standby faktiskt tillhandahölls för dem. De rapporterar no_standby: det finns en nod, och inget failover-skydd. no_standby löser inte upp sig själv, och hög tillgänglighet kan inte läggas till i efterhand — skapa en ny instans med hög tillgänglighet och migrera till den.

Säkerhetskopior och återställning

PostgreSQL- och MySQL-instanser stöder schemalagda säkerhetskopior och säkerhetskopior on demand. De kräver ett aktivt val: portalens skapandeformulär kryssar i Enable Automated Backups åt dig, men på CLI:n anger du --backup och i Terraform sätter du backup_enabled = true — annars skapas instansen utan dem. Schemat anges som ett cron-uttryck (0 2 * * * som standard). Varje säkerhetskopia krypteras med din tenants egen säkerhetskopieringsnyckel innan den lämnar instansen.

Lagringstiden är minst 35 dagar och högst 90. Säkerhetskopior skrivs till oföränderlig, objektlåst lagring som behåller varje objekt i 35 dagar, så en kortare lagringstid skulle inte kunna radera något tidigare — API:et avvisar den. Att du själv raderar en säkerhetskopia får effekt för dig direkt; det lagrade objektet rensas när dess oföränderlighetsfönster har löpt ut.

I portalen använder du fliken Backups på instansen. En säkerhetskopia kan bara tas medan instansen är igång. Att återkalla din tenants säkerhetskopieringsnyckel (fm database backup-key revoke) stänger av både säkerhetskopiering och återställning för alla hanterade databaser i tenanten tills du aktiverar den igen.

Instanser som skapades innan säkerhetskopiorna lanserades

Agenten som tar säkerhetskopior följer med instansavbilden, så en instans som skapades innan hanterade säkerhetskopior lanserades saknar den: en säkerhetskopia på en sådan instans fastnar i creating och blir aldrig klar. Skapa en ny instans för att få säkerhetskopior.

fm database postgres backup list <instance-id>
fm database postgres backup create <instance-id> --name pre-migration
fm database postgres backup delete <instance-id> <backup-id>

resource "frostmoln_postgres_instance" "app" {
  # … skapandeargument enligt ovan …
  backup_enabled        = true
  backup_schedule       = "0 2 * * *"
  backup_retention_days = 35
}

Återställning

Återställning är icke-destruktiv: den skapar en ny instans från källan och lämnar källan orörd. PostgreSQL-instanser kan dessutom återställas till vilken sekund som helst inom ett återställningsfönster — se Återställning till en tidpunkt.

fm database postgres restore <instance-id> --backup <backup-id> --target-name app-db-restored

Medan en återställning från en instans fortfarande pågår — från en säkerhetskopia eller till en tidpunkt — går källan inte att radera: att radera den skulle få återställningen att misslyckas. Portalen, fm och Terraform får alla 409 restore_from_instance_in_progress. Vänta tills den återställda instansen är running (eller error, om återställningen misslyckades) och radera sedan källan.

Att radera en instans är permanent

Att radera en instans tar bort den och dess lagringsvolym. Ta en säkerhetskopia först om du kan behöva data — och behåll en egen logisk dump någonstans varaktigt, såsom objektlagring, om du vill ha en kopia utanför plattformen:

pg_dump   "host=<host> user=pgadmin dbname=app"  > app.sql   # PostgreSQL
mysqldump -h <host> -u mysqladmin app            > app.sql   # MySQL

Återställning till en tidpunkt

Återställning till en tidpunkt (PITR) återställer en PostgreSQL-instans till vilken sekund som helst inom dess återställningsfönster, inte bara till det ögonblick då en säkerhetskopia togs. Plattformen arkiverar instansens write-ahead-logg kontinuerligt, så medan arkiveringen körs kan högst fem minuters skrivningar gå förlorade (se När arkiveringen pausas). Som vid varje återställning byggs en ny instans och källan lämnas orörd.

"Restorable to" — det senaste ögonblick du faktiskt kan återställa till — ligger normalt några minuter efter realtid. På en instans med få skrivningar kan eftersläpningen bli längre, eftersom plattformen flyttar fram värdet först när den kan bevisa att ingen senare commit saknas. En instans utan skrivningar kan efter en bassäkerhetskopia visa inget fönster alls tills den nästa gång tar emot en skrivning.

PITR gäller endast PostgreSQL och kräver säkerhetskopior.

# Fönstret: "Restorable from" och "Restorable to"
fm database postgres instance get <instance-id>

fm database postgres restore <instance-id> \
  --to-time 2026-09-20T14:30:00Z --target-name app-db-recovered

Ange exakt en av --backup och --to-time.

Sikta in i fönstret, inte på dess kant

"Restorable from" är den senare av din äldsta användbara bassäkerhetskopia — den äldsta som tagits efter ett eventuellt avbrott i arkiveringen — och lagringstidens gräns. När det är lagringstiden som avgränsar fönstret flyttas värdet fram i realtid, så ett ögonblick som kopierats från instance get kan redan ha hamnat utanför fönstret när återställningen skickas in.

Vilka instanser kan använda det

PITR är aktiverat som standard för nya PostgreSQL-instanser som skapas med säkerhetskopior. En återställning — från en säkerhetskopia eller till en tidpunkt — ger också en instans som klarar PITR, så länge källan hade säkerhetskopiering påslagen och inte hade hög tillgänglighet.

Huruvida en instans någonsin kan göra PITR stämplas när den skapas, och den stämpeln är permanent:

• Instanser som skapades innan PITR lanserades kan inte göra det. Att återställa en sådan ger en ny instans som kan.
• Instanser som skapades med hög tillgänglighet kan inte göra det, och kan inte få det senare. Hög tillgänglighet och PITR är ett antingen-eller-val som görs när instansen skapas, och en återställning ändrar inte det — en återställning kopierar källans höga tillgänglighet, så den nya instansen kan inte heller göra PITR. För att flytta en högtillgänglig databas till PITR måste du skapa en ny instans utan hög tillgänglighet och migrera dina data.
• En instans som skapades med PITR avstängt (--no-pitr på CLI:n, pitr_enabled = false i Terraform) kan aldrig få det. Att återställa den ger en ny instans som kan.

Stänga av det, och sätta på det igen

På en instans som klarar PITR kan du stänga av PITR senare — i portalen eller med pitr_enabled = false i Terraform. (fm har inget kommando för att uppdatera en instans.) Att stänga av det — eller att stänga av säkerhetskopieringen, vilket stänger det på samma sätt:

• stoppar arkiveringen inom några minuter, och instansen har därefter inget återställningsbart fönster — en återställning till en tidpunkt avvisas;
• behåller de bassäkerhetskopior och den arkiverade logg som redan tagits, och de fortsätter att debiteras tills lagringstiden löper ut och de rensas. Lagringstiden är minst 35 dagar i oföränderlig lagring, så att stänga av PITR stoppar inte kostnaden omedelbart;
• startar en avkylningsperiod på 24 timmar. Att sätta på PITR igen — eller att sätta på säkerhetskopiering igen, vilket har samma effekt — inom de 24 timmarna avvisas, och avvisandet anger när du får försöka igen.

När du sätter på det igen börjar fönstret om vid nästa bassäkerhetskopia. Det sträcker sig inte tillbaka över avbrottet.

Bassäkerhetskopior och schemat

På en PITR-instans är den schemalagda säkerhetskopian en bassäkerhetskopia: en fysisk kopia som den arkiverade loggen spelas upp på. Den körs enligt ditt eget säkerhetskopieringsschema — det finns ingen separat PITR-takt. Säkerhetskopior du tar on demand själv förblir logiska (full) och portabla.

Om du inte anger något schema väljer plattformen ett utifrån instansens lagringsstorlek; större volymer behöver längre tid mellan schemalagda säkerhetskopior. Om du anger ett schema som plattformen inte kan upprätthålla vid den storleken avvisas begäran med ett meddelande som anger minsta intervall för din storlek. Lämna portalens schemafält tomt för att mena "plattformens standard för den här storleken".

En storleksändring omprövar schemat. Om plattformen valde schemat väljer den ett nytt för den nya storleken och rapporterar tillbaka det. Om du själv skrev schemat avvisas en ny storlek som inte längre kan upprätthålla det — skicka med ett schema som kan det i samma begäran (med Terraform; portalens och fm😒 storleksändring tar bara storleken), så får storleksändringen och det nya schemat effekt tillsammans.

En storleksändring avvisas medan någon säkerhetskopia körs. Vänta tills den är klar och försök igen.

Återställningstiden växer med intervallet mellan bassäkerhetskopior, eftersom mer logg måste spelas upp: ungefär 16 sekunder per GB för att packa upp basen, plus ungefär 2,3 timmar för varje aktivt dygn av logg, innan tiden det tar att hämta den. En daglig bas ligger i storleksordningen ett par timmar; en veckovis i storleksordningen 16 timmar.

När arkiveringen pausas

Varje tenant har ett tak för hur många byte PITR-data den får behålla samtidigt. När en tenant når det slutar plattformen ta emot nya loggsegment för den tenantens instanser, och instansen rapporterar arkiveringen som pausad med orsaken tenant_cap — fm database postgres instance get skriver ut "Archiving paused", och API:t och Terraform bär själva orsaken. Plattformen kan också pausa arkiveringen för hela flottan under en incident, vilket visas som platform_disabled.

En tenant över taket har inget återställningsfönster

Medan en tenant ligger över taket har dess PITR-instanser inget återställningsfönster alls, och en återställning till en tidpunkt avvisas. Fönstret kommer inte tillbaka förrän tenanten är under taket igen.

Schemalagda bassäkerhetskopior fortsätter att köras under tiden. Var och en är en fullständig kopia av volymen och behålls och debiteras som alla andra, men ingen av dem återbildar fönstret så länge taket binder. Äldre bassäkerhetskopior löper ut enligt sin egen lagringstid, så en tenant över taket kommer under det igen utan ingripande bara när den utgången går snabbare än de nya baserna tillkommer.

För att komma tillbaka snabbare: stäng av PITR på den instans som producerar mest logg, gör dess säkerhetskopieringsschema glesare, eller be supporten höja tenantens tak.

Bassäkerhetskopior i säkerhetskopielistan

Bassäkerhetskopior visas i säkerhetskopielistan med typen base, vid sidan av dina logiska full-säkerhetskopior. De hanteras av plattformen: du kan inte radera en — begäran avvisas — och du kan inte skapa en on demand. De tas bort automatiskt när en nyare bas ersätter dem och lagringstiden har löpt ut; en bas som aldrig blev användbar löper ut enligt sin egen lagringstid.

PITR-lagring — bassäkerhetskopior och arkiverad logg — mäts som samma database_backup-post som dina övriga säkerhetskopior för hanterade databaser. Priser kommer från plattformens priskatalog och visas i portalen; den här guiden anger inga belopp. Se Fakturering.

Fel du kan se

Kod	Vad det betyder	Vad du gör
pitr_unavailable_for_instance	Den här instansen kan inte göra PITR. Orsaken anger vilken: type (endast PostgreSQL), ha (hög tillgänglighet), legacy (skapad före PITR, eller skapad med det avstängt), not_enabled (klarar det, men PITR eller säkerhetskopiering är avstängt just nu)	För not_enabled: sätt på PITR och säkerhetskopiering; fönstret börjar vid nästa bassäkerhetskopia. För legacy: återställ till en ny instans. ha och type går inte att ändra på en befintlig instans, och en återställning kopierar båda.
pitr_window_unavailable	Det finns inget återställningsfönster — den första bassäkerhetskopian körs fortfarande, ett glapp startade om det, eller tenanten ligger över sitt tak	Kontrollera fönstret igen senare. Gör inte automatiska omförsök med fast intervall.
pitr_out_of_window	Det ögonblick du bad om ligger utanför fönstret. Felet innehåller fönstrets gränser	Välj ett ögonblick inom de gränser det rapporterar och skicka in igen.
invalid_input	En säkerhetskopia och en tidpunkt tillsammans, eller ingen av dem; en base-rad angiven som säkerhetskopia att återställa från; PITR utan säkerhetskopior; ett schema under golvet för instansens storlek	Läs meddelandet — det anger vilket.
conflict	backup_running: en storleksändring medan en säkerhetskopia körs. pitr_cooldown: att sätta på det igen inom avkylningsperioden på 24 timmar, med tiden du får försöka igen. base_managed: att radera en bassäkerhetskopia	Vänta och försök igen, utom för base_managed — bassäkerhetskopior går inte att radera.

Med Terraform

resource "frostmoln_postgres_instance" "app" {
  # … skapandeargument enligt ovan …
  backup_enabled = true
  pitr_enabled   = true
  # backup_schedule utelämnat: plattformen väljer ett för den här lagringsstorleken
}

Fullständig attributreferens: frostmoln_postgres_instance.

• Skriv pitr_enabled explicit. Plattformen stämplar det när instansen skapas och stämpeln är permanent, så en instans som skapats utan PITR kan aldrig få det. Utelämnar du det får du det som plattformen bestämmer, vilket kan vara påslaget — och debiteras.
• Fönsterattributen visas som "known after apply" i varje plan som innehåller ändringar. latest_restorable_time flyttas fram med varje arkiverat segment, så det är aldrig detsamma vid plan och vid apply. Det är avsiktligt — läs av värdena, lås inte fast dig vid dem.
• restore_from kan bara anges när resursen skapas. Att peka om det mot en annan källa eller tidpunkt ersätter resursen, vilket raderar den återställda databasen. Att lägga till det på en instans som redan finns avvisas, och att importera en återställd instans registrerar ingenting.
• Att ta bort restore_from gör inte ingenting. Det är en enda uppdatering på plats som rensar den uppgift Terraform behöll. Ingenting ändras på plattformen, och nästa plan är ren.
• Återställningsmålet byggs utifrån källans egen form, så källan måste vara en PostgreSQL-instans och version, flavor_id, ha_enabled, vpc_id och subnet_id måste vara samma som källans. storage_gb får vara större, aldrig mindre. Terraform läser källan först och avvisar med avvikelsen utpekad, i stället för att tyst skapa en tom databas.

Uppdatera efter en misslyckad återställning innan du läser planen

En återställning skapar först den nya instansen och tillämpar sedan de återstående skillnaderna (lagring, säkerhetskopiering, schema, pitr_enabled) som en enda uppdatering. Om den uppdateringen misslyckas registrerar Terraforms state vad planen begärde, inte vad plattformen faktiskt har — och resursen markeras medvetet inte som tainted, eftersom det skulle radera den återställda databasen vid nästa apply.

Avvikelsen syns bara vid en refresh. terraform plan -refresh=false visar ingen skillnad alls. Kör terraform plan (eller terraform refresh) och tillämpa uppdateringen på plats som den då rapporterar.

PostgreSQL-tillägg

PostgreSQL-instanser kan aktivera tillägg från plattformens tilläggskatalog — TimescaleDB, pg_stat_statements, pg_trgm och pgcrypto i dag, fler i takt med att katalogen växer. De som kräver shared_preload_libraries (TimescaleDB, pg_stat_statements) betalar ett omstartsfönster, och plattformen kör en åtgärd i taget. Se PostgreSQL-tillägg.

Stoppa, starta och starta om

fm database postgres instance stop    <instance-id>
fm database postgres instance start   <instance-id>
fm database postgres instance restart <instance-id>

• Stoppa stänger ner servern kontrollerat. Instansen visar stopping och sedan stopped. Beräkning debiteras inte medan den är stoppad; lagring för återställning till en tidpunkt debiteras.
• Starta startar en stoppad instans: starting och sedan running, på samma adress och med samma data.
• Starta om startar om en körande instans: restarting och sedan running. Alla anslutningar bryts under omstarten; klienter ska ansluta igen.
• Varje åtgärd tar en minut eller två. fm väntar tills instansen har landat; ange --no-wait för att återvända så snart åtgärden har tagits emot. Om en åtgärd misslyckas visar instansen error. Kontakta supporten, som kan göra om den.
• Hög tillgänglighet: en instans med hög tillgänglighet kan ännu inte stoppas (omstart fungerar). Ingenting kan stoppas eller startas om under en failover, en pågående säkerhetskopiering eller ett byte av inloggningsuppgifter. Vänta tills det är klart och försök igen.
• Läsrepliker fortsätter att köra medan deras primära instans är stoppad och kommer ikapp när den startas igen.

Livscykel och begränsningar

• Versioner är fasta under instansens livstid — uppgraderingar på plats är ännu inte tillgängliga. För att gå över till en nyare större version, skapa en ny instans på den versionen och migrera dina data (t.ex. med pg_dump / mysqldump).
• Hög tillgänglighet ligger fast under instansens livstid — den väljs när instansen skapas och kan inte läggas till eller tas bort senare (se ovan).
• Radering är permanent och tar bort lagringsvolymen (se ovan).
• En instans lever i ett VPC/subnät (en region).

Relaterat

• PostgreSQL-tillägg
• Nätverk: VPC:er · Säkerhetsgrupper
• Objektlagring (någonstans att förvara dina dumpar)
• Cacheminnen · Fakturering