Administrerede databaser

Frostmoln kører administrerede PostgreSQL- og MySQL-instanser for dig — platformen provisionerer den virtuelle maskine, tilknytter vedvarende lagring, konfigurerer motoren og giver dig en forbindelse, der er klar til brug. Du administrerer dine data; vi administrerer infrastrukturen nedenunder.

Vælg motor og version

Vælg PostgreSQL eller MySQL ved oprettelsen. Hver motor tilbyder flere versioner, og dropdown-menuen ved oprettelsen er kilden til sandhed for, hvad du kan starte lige nu — i øjeblikket omkring PostgreSQL 14–18 og MySQL 8.0 / 8.4.

Hver version har en livscyklusstatus:

Status	Kan startes?	Betydning
current	Ja	Nyeste fuldt understøttede udgivelse
supported	Ja	Fuldt understøttet
deprecated	Ja (markeret)	Kan stadig startes, vises med en (deprecated)-markering — planlæg at flytte væk fra den
eol	Nej	End of life — skjult i dropdown-menuen ved oprettelsen

Den anbefalede version for hver motor er markeret (Recommended). End-of-life- og preview-versioner tilbydes ikke til nye instanser.

Dimensionering

Instansstørrelser bruger flavor-familien db.gp1.<size> (general purpose):

Flavor	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ælger lagring separat (20–1000 GB). Opret-dialogen viser den estimerede omkostning, før du bekræfter.

Opret en instans

I portalen går du til Databaser → Instanser → Opret og vælger motor, version, flavor, lagringsstørrelse og den VPC + subnet, instansen tilknyttes. Du kan eventuelt slå høj tilgængelighed til for PostgreSQL.

Fra CLI'en

Livscykluskommandoer er motorspecifikke (fm database postgres … / fm database mysql …); den motoruafhængige gruppe fm database … lister på tværs af motorer.

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

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

# Visninger på tværs af motorer:
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
}

Opret forbindelse

Efter provisioneringen viser instansens detaljeside forbindelsesoplysningerne bag en Vis legitimationsoplysninger-knap:

• Host — instansens private adresse
• Port — 5432 (PostgreSQL) eller 3306 (MySQL)
• Brugernavn — pgadmin (PostgreSQL) eller mysqladmin (MySQL)
• Adgangskode — genereret til dig (kan roteres)
• en forbindelses-URI, der er klar til brug

Databaser kan nås fra instanser på samme VPC; opret-flowet åbner motorens port i instansens sikkerhedsgruppe. Opret forbindelse som med enhver standardklient:

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

TIP

Behandl administratorlegitimationen som enhver anden hemmelighed — gem den i Hemmeligheder eller din applikations hemmelighedslager, ikke i versionsstyringen.

Høj tilgængelighed

Høj tilgængelighed kører en synkron standby ved siden af den primære. Så længe synkron replikering er armeret, ligger et commit, som den primære har kvitteret for over for din klient, allerede på standbyens disk, så en failover mister intet, der er kvitteret for.

• Kun PostgreSQL. En MySQL-instans kan ikke oprettes med høj tilgængelighed — anmodningen afvises.
• Vælges ved oprettelsen og ligger fast i instansens levetid. Høj tilgængelighed kan hverken tilføjes til en kørende instans eller fjernes fra en; ændrer du indstillingen bagefter, afvises det. Vil du flytte en eksisterende database over på en højtilgængelig instans, skal du oprette en ny instans og migrere dine data.
• Beskyttelsen er på tværs af værter, ikke på tværs af tilgængelighedszoner. Parret deler instansens VPC og subnet og dermed én tilgængelighedszone. De to noder placeres normalt på adskilte fysiske værter; når værtskapaciteten er knap, kan parret dele én, så adskillelse på værter er efter bedste evne frem for garanteret. Høj tilgængelighed på tværs af tilgængelighedszoner tilbydes ikke.

Slå det til i portalens opret-formular, med --ha i CLI'en eller med ha_enabled = true i Terraform.

HA-status

En højtilgængelig instans rapporterer en HA-status på sin detaljeside og i instanslisten:

Status	Betydning
healthy	En synkron standby streamer og beskytter den primæres skrivninger.
degraded	Én node betjener trafikken, og intet beskytter dens skrivninger — standbyen er utilgængelig eller bliver bygget op igen efter en failover.
provisioning	Parret er stadig under opbygning.
failing_over	En failover er i gang.
no_standby	Instansen har ingen standby (se nedenfor).

Hvad der garanteres, og hvornår

Et commit er kun beskyttet mod en failover, hvis der blev kvitteret for det, mens synkron replikering var armeret. HA-statussen rapporterer den tilstand med en kort forsinkelse — op til omkring et minut — så en status, der viser healthy, er ikke i sig selv bevis for, at det commit, du lige har lavet, allerede er på standbyen.

Holder standbyen op med at streame, blokerer skrivninger kortvarigt og fortsætter derefter asynkront: platformen dropper synkron replikering, så instansen bliver ved med at tage imod skrivninger, og rapporterer det som degraded. Det er en bevidst afvejning — databasen forbliver tilgængelig, og prisen er, at commits, der kvitteres for i det degraderede vindue, endnu ikke er på standbyen og kan gå tabt, hvis en failover sker, før standbyen har indhentet det. Når standbyen er synkron igen, vender statussen tilbage til healthy, og nye commits er beskyttet igen.

WARNING

Hold øje med HA-statussen for alt, der ikke må miste en skrivning. degraded er det vindue, hvor en failover kan koste dig commits, der er kvitteret for.

Failover

En failover anmodes af dig — fra portalen, med fm-CLI'en eller gennem API'et. Platformen overvåger parret løbende og rapporterer dets HA-status; at forfremme standbyen er en beslutning, du træffer, ikke noget platformen gør af sig selv.

En failover accepteres kun, mens HA-statussen er healthy — at fejle over til en standby, der ikke er synkron, ville kassere skrivninger, der er kvitteret for. Den har også et budget: højst 2 failovers pr. instans pr. 24 timer, med mindst 30 minutter mellem forsøgene. En instans, der har fejlet over to gange på én dag, har en fejl, som endnu en failover ikke retter.

Din forbindelsesadresse ændrer sig ikke. Det er hele pointen med designet — du skal ikke pege din applikation et nyt sted hen, slå et nyt navn op eller opdatere en forbindelsesstreng. Åbne forbindelser afbrydes kortvarigt og skal genetableres, så din klient eller din forbindelsespulje har brug for den sædvanlige genforbindelseslogik; derefter forbinder alt til den samme adresse igen.

Instanser oprettet før høj tilgængelighed blev lanceret

Et lille antal instanser blev oprettet med flaget for høj tilgængelighed sat, før der rent faktisk blev provisioneret en standby til dem. De rapporterer no_standby: der er én node og ingen failover-beskyttelse. no_standby løser sig ikke af sig selv, og høj tilgængelighed kan ikke tilføjes bagefter — opret en ny instans med høj tilgængelighed og migrér over til den.

Backup og gendannelse

PostgreSQL- og MySQL-instanser understøtter planlagte og ad hoc-backups. De er opt-in: portalens opret-formular sætter flueben i Enable Automated Backups for dig, men i CLI'en angiver du --backup, og i Terraform sætter du backup_enabled = true — ellers oprettes instansen uden dem. Planen er et cron-udtryk (0 2 * * * som standard). Hver backup krypteres med din tenants egen backupnøgle, før den forlader instansen.

Opbevaringen er minimum 35 dage, maksimum 90. Backups skrives til uforanderligt, objektlåst lager, der holder på hvert objekt i 35 dage, så en kortere opbevaring ikke ville kunne slette noget hurtigere — API'et afviser den. Sletter du selv en backup, træder det i kraft for dig med det samme; det lagrede objekt fjernes, når dets uforanderlighedsvindue er udløbet.

I portalen bruger du fanen Backups på instansen. En backup kan kun tages, mens instansen kører. Tilbagekalder du din tenants backupnøgle (fm database backup-key revoke), deaktiverer det backups og gendannelser for hver administreret database i tenanten, indtil du slår den til igen.

Instanser oprettet før backups blev lanceret

Backupagenten i gæsten leveres inde i instans-imaget, så en instans, der er oprettet, før administrerede backups gik i luften, har den ikke: en backup på sådan en instans bliver stående i creating og bliver aldrig færdig. Opret en ny instans for at få backups.

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" {
  # … create arguments as above …
  backup_enabled        = true
  backup_schedule       = "0 2 * * *"
  backup_retention_days = 35
}

Gendannelse

Gendannelse er ikke-destruktiv: den provisionerer en ny instans ud fra kilden og lader kilden være urørt. PostgreSQL-instanser kan desuden gendannes til et hvilket som helst sekund inden for et gendannelsesvindue — se Point-in-time-gendannelse.

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

Mens en gendannelse fra en instans stadig kører — fra en backup eller til et tidspunkt — kan kilden ikke slettes: sletning ville få gendannelsen til at mislykkes. Portalen, fm og Terraform får alle 409 restore_from_instance_in_progress. Vent, til den gendannede instans er running (eller error, hvis gendannelsen mislykkedes), og slet derefter kilden.

Sletning af en instans er permanent

Sletter du en instans, fjernes den og dens lagringsvolumen. Tag en backup først, hvis du kan få brug for dataene — og hold en uafhængig logisk dump et holdbart sted som objektlagring, hvis du vil have en kopi uden for platformen:

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

Point-in-time-gendannelse

Point-in-time-gendannelse (PITR) gendanner en PostgreSQL-instans til et hvilket som helst sekund inden for dens gendannelsesvindue, ikke kun til det øjeblik, hvor en backup blev taget. Platformen arkiverer instansens write-ahead-log løbende, så mens arkiveringen kører, er højst fem minutters skrivninger i fare (se Når arkiveringen sættes på pause). Som enhver anden gendannelse bygger den en ny instans og lader kilden være urørt.

"Restorable to" — det nyeste tidspunkt, du reelt kan gendanne til — ligger normalt et par minutter efter realtid. På en instans med få skrivninger kan der gå længere, fordi platformen først rykker det frem, når den kan bevise, at ingen senere commit mangler. En instans uden skrivninger kan efter en basisbackup vise slet intet vindue, indtil den næste gang modtager en skrivning.

PITR er kun til PostgreSQL og kræver backups.

# Vinduet: "Restorable from" og "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

Angiv præcis én af --backup og --to-time.

Sigt inde i vinduet, ikke mod kanten

"Restorable from" er den seneste af din ældste brugbare basisbackup — den ældste, der er taget efter en eventuel afbrydelse i arkiveringen — og opbevaringsgrænsen. Når det er opbevaringen, der afgrænser vinduet, rykker værdien i realtid, så et tidspunkt, du har kopieret fra instance get, allerede kan være faldet uden for vinduet, når gendannelsen indsendes.

Hvilke instanser kan bruge det

PITR er slået til som standard for nye PostgreSQL-instanser, der oprettes med backups. En gendannelse — fra en backup eller til et tidspunkt — giver også en instans, der kan bruge PITR, så længe kilden havde backups slået til og ikke var højt tilgængelig.

Om en instans nogensinde kan bruge PITR, stemples ved oprettelsen, og det stempel er permanent:

• Instanser, der er oprettet, før PITR blev lanceret, kan ikke bruge det. Gendanner du en af dem, får du en ny instans, der kan.
• Instanser oprettet med høj tilgængelighed kan ikke bruge det og kan ikke få det senere. Høj tilgængelighed og PITR er et enten-eller-valg, der træffes ved oprettelsen, og en gendannelse ændrer det ikke — en gendannelse kopierer kildens høje tilgængelighed, så den nye instans kan heller ikke bruge PITR. Vil du flytte en højt tilgængelig database over på PITR, skal du oprette en ny instans uden høj tilgængelighed og migrere dine data.
• En instans oprettet med PITR slået fra (--no-pitr i CLI'en, pitr_enabled = false i Terraform) kan aldrig få det. Gendanner du den, får du en ny instans, der kan.

Slå det fra — og til igen

På en instans, der kan bruge PITR, kan du slå PITR fra senere — i portalen eller med pitr_enabled = false i Terraform. (fm har ingen kommando til at opdatere en instans.) Slår du det fra — eller slår backups fra, hvilket lukker det på samme måde:

• stopper arkiveringen i løbet af få minutter, og instansen har derefter intet gendannelsesvindue — en point-in-time-gendannelse afvises;
• beholder den de basisbackups og den arkiverede log, der allerede er taget, og de faktureres fortsat, indtil opbevaringen udløber, og de ryddes op. Opbevaringen er minimum 35 dage i uforanderligt lager, så det stopper ikke omkostningen med det samme at slå PITR fra;
• starter en 24-timers afkølingsperiode. At slå PITR til igen — eller slå backups til igen, hvilket har samme virkning — inden for de 24 timer afvises, og afvisningen oplyser, hvornår du må prøve igen.

Når du slår det til igen, starter vinduet forfra ved den næste basisbackup. Det rækker ikke tilbage hen over afbrydelsen.

Basisbackups og backupplanen

På en PITR-instans er den planlagte backup en basisbackup: en fysisk kopi, som den arkiverede log afspilles oven på. Den kører efter din egen backupplan — der er ingen særskilt PITR-kadence. Ad hoc-backups, du selv tager, forbliver logiske (full) og portable.

Sætter du ingen backupplan, vælger platformen en ud fra instansens lagringsstørrelse; større volumener kræver længere mellem de planlagte backups. Sætter du en backupplan, platformen ikke kan holde ved den størrelse, afvises anmodningen med en besked, der oplyser minimumsintervallet for din størrelse. Lad portalens backupplanfelt stå tomt for at betyde "platformens standard for denne størrelse".

Ændrer du størrelsen, tjekkes backupplanen igen. Har platformen valgt backupplanen, vælger den en ny til den nye størrelse og melder den tilbage. Har du selv skrevet backupplanen, afvises en ny størrelse, der ikke længere kan holde den — send en backupplan, der kan, i samme anmodning (med Terraform; portalens og fm's størrelsesændring tager kun størrelsen), så træder den nye størrelse og den nye backupplan i kraft sammen.

En ændring af størrelsen afvises, mens der kører en backup. Vent, til den er færdig, og prøv igen.

Gendannelsestiden vokser med intervallet mellem basisbackups, fordi mere log skal afspilles: omkring 16 sekunder pr. GB til at pakke basis ud, plus omkring 2,3 timer for hvert travlt døgn med log, før den tid det tager at hente den. En daglig basis ligger i størrelsesordenen et par timer; en ugentlig i størrelsesordenen 16 timer.

Når arkiveringen sættes på pause

Hver tenant har en grænse for, hvor mange bytes PITR-data den må opbevare ad gangen. Når en tenant når den, holder platformen op med at tage imod nye logsegmenter for den tenants instanser, og instansen rapporterer arkiveringen som sat på pause med årsagen tenant_cap — fm database postgres instance get udskriver "Archiving paused", og API'et og Terraform bærer selve årsagen. Platformen kan også sætte arkiveringen på pause på tværs af hele flåden under en hændelse, hvilket vises som platform_disabled.

En tenant over grænsen har intet gendannelsesvindue

Mens en tenant er over grænsen, har dens PITR-instanser slet intet gendannelsesvindue, og en point-in-time-gendannelse afvises. Vinduet kommer ikke tilbage, før tenanten er under grænsen igen.

Planlagte basisbackups kører videre imens. Hver af dem er en fuld kopi af volumet og opbevares og faktureres som alle andre, men ingen af dem danner vinduet igen, så længe grænsen binder. Ældre basisbackups udløber efter deres egen opbevaringstid, så en tenant over grænsen kommer kun under den igen uden indgriben, når den udløbning går hurtigere, end de nye basisbackups kommer til.

Vil du komme hurtigere i gang igen, så slå PITR fra på den instans, der producerer mest log, gør dens backupplan mindre hyppig, eller bed supporten om at hæve din tenants grænse.

Basisbackups i backuplisten

Basisbackups vises i backuplisten med typen base ved siden af dine logiske full-backups. De administreres af platformen: du kan ikke slette en — anmodningen afvises — og du kan ikke oprette en ad hoc. De fjernes automatisk, når en nyere basis afløser dem, og opbevaringen er udløbet; en basis, der aldrig blev brugbar, udløber efter sin egen opbevaringstid.

PITR-lagring — basisbackups og arkiveret log — måles på den samme database_backup-linje som dine øvrige backups af administrerede databaser. Priserne kommer fra platformens priskatalog og vises i portalen; denne vejledning nævner ingen beløb. Se Fakturering.

Fejl, du kan møde

Kode	Betydning	Hvad du gør
pitr_unavailable_for_instance	Denne instans kan ikke bruge PITR. Årsagen siger hvilken: type (kun PostgreSQL), ha (høj tilgængelighed), legacy (oprettet før PITR eller oprettet med det slået fra), not_enabled (kan godt, men PITR eller backups er slået fra lige nu)	Ved not_enabled: slå PITR og backups til; vinduet starter ved den næste basisbackup. Ved legacy: gendan instansen til en ny. ha og type kan ikke ændres på en eksisterende instans, og en gendannelse kopierer begge dele.
pitr_window_unavailable	Der er intet gendannelsesvindue — den første basisbackup kører stadig, et hul har startet det forfra, eller tenanten er over sin grænse	Tjek vinduet igen senere. Lad være med at prøve igen automatisk med faste intervaller.
pitr_out_of_window	Det tidspunkt, du bad om, ligger uden for vinduet. Fejlen indeholder vinduets grænser	Vælg et tidspunkt inden for de grænser, den oplyser, og indsend igen.
invalid_input	En backup og et tidspunkt på én gang, eller ingen af dem; en base-række angivet som den backup, der skal gendannes fra; PITR uden backups; en backupplan under minimummet for instansens størrelse	Læs beskeden — den oplyser hvilken.
conflict	backup_running: en ændring af størrelsen, mens en backup kører. pitr_cooldown: at slå til igen inden for 24-timers afkølingsperioden, med det tidspunkt du må prøve igen. base_managed: at slette en basisbackup	Vent og prøv igen — undtagen ved base_managed, for basisbackups kan ikke slettes.

Med Terraform

resource "frostmoln_postgres_instance" "app" {
  # … oprettelsesargumenter som ovenfor …
  backup_enabled = true
  pitr_enabled   = true
  # backup_schedule er ikke sat: platformen vælger en til denne lagringsstørrelse
}

Fuld attributreference: frostmoln_postgres_instance.

• Skriv pitr_enabled eksplicit. Platformen stempler den ved oprettelsen, og stemplet er permanent, så en instans, der er oprettet uden PITR, kan aldrig få det. Udelader du den, får du det, platformen beslutter, hvilket kan være slået til — og faktureret.
• Vinduesattributterne vises som "known after apply" i enhver plan med ændringer. latest_restorable_time rykker med hvert arkiveret segment, så den er aldrig den samme ved plan og ved apply. Det er efter hensigten — læs værdierne, men bind dig ikke til dem.
• restore_from kan kun sættes ved oprettelsen. Peger du den mod en anden kilde eller et andet tidspunkt, erstattes ressourcen, hvilket ødelægger den gendannede database. At føje den til en instans, der allerede findes, afvises, og importerer du en gendannet instans, registreres der intet.
• At fjerne restore_from er ikke en tom handling. Det er én enkelt in-place-opdatering, der rydder den registrering, Terraform havde gemt. Intet ændrer sig på platformen, og den næste plan er ren.
• Gendannelsesmålet bygges ud fra kildens egen form, så kilden skal være en PostgreSQL-instans, og version, flavor_id, ha_enabled, vpc_id og subnet_id skal svare til kildens. storage_gb må være større, aldrig mindre. Terraform læser kilden først og afviser med det, der ikke stemmer, i stedet for stille og roligt at oprette en tom database.

Efter en mislykket gendannelse skal du køre refresh, før du læser planen

En gendannelse opretter først den nye instans og anvender derefter de resterende forskelle (lagring, backups, backupplan, pitr_enabled) som én opdatering. Mislykkes den opdatering, registrerer Terraforms state det, planen bad om, og ikke det, platformen rent faktisk har — og ressourcen markeres bevidst ikke som tainted, fordi det ville ødelægge den gendannede database ved næste apply.

Forskellen viser sig kun ved en refresh. terraform plan -refresh=false viser slet ingen forskel. Kør terraform plan (eller terraform refresh), og anvend den in-place-opdatering, den derefter melder.

PostgreSQL-udvidelser

PostgreSQL-instanser kan aktivere udvidelser fra platformens udvidelseskatalog — TimescaleDB, pg_stat_statements, pg_trgm og pgcrypto i dag, flere efterhånden som kataloget vokser. De, der kræver shared_preload_libraries (TimescaleDB, pg_stat_statements), koster et genstartsvindue, og platformen kører én handling ad gangen. Se PostgreSQL-udvidelser.

Stop, start og genstart

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

• Stop lukker serveren kontrolleret ned. Instansen viser stopping og derefter stopped. Beregning faktureres ikke, mens den er stoppet; lagring til gendannelse til et tidspunkt faktureres.
• Start starter en stoppet instans: starting og derefter running, på samme adresse og med de samme data.
• Genstart genstarter en kørende instans: restarting og derefter running. Alle forbindelser afbrydes under genstarten; klienter skal forbinde igen.
• Hver handling tager et minut eller to. fm venter, til instansen er faldet på plads; brug --no-wait for at vende tilbage, så snart handlingen er modtaget. Hvis en handling mislykkes, viser instansen error. Kontakt support, som kan prøve den igen.
• Høj tilgængelighed: en instans med høj tilgængelighed kan endnu ikke stoppes (genstart virker). Intet kan stoppes eller genstartes under en failover, en igangværende sikkerhedskopiering eller et skift af loginoplysninger. Vent, til det er færdigt, og prøv igen.
• Læsereplikaer kører videre, mens deres primære instans er stoppet, og indhenter det forsømte, når den startes igen.

Livscyklus og begrænsninger

• Versioner ligger fast i en instans' levetid — opgraderinger på stedet er endnu ikke tilgængelige. Vil du over på en nyere hovedversion, skal du oprette en ny instans på den version og migrere dine data (f.eks. med pg_dump / mysqldump).
• Høj tilgængelighed ligger fast i en instans' levetid — den vælges ved oprettelsen og kan ikke tilføjes eller fjernes senere (se ovenfor).
• Sletning er permanent og fjerner lagringsvolumenet (se ovenfor).
• En instans lever i én VPC/ét subnet (én region).

Relateret

• PostgreSQL-udvidelser
• Netværk: VPC'er · Sikkerhedsgrupper
• Objektlagring (et sted at gemme dine dumps)
• Cacher · Fakturering