Administrerte databaser

Frostmoln kjører administrerte PostgreSQL- og MySQL-instanser for deg — plattformen klargjør den virtuelle maskinen, kobler til persistent lagring, konfigurerer serveren og gir deg en klar-til-bruk-tilkobling. Du administrerer dataene dine; vi administrerer infrastrukturen under.

Velge type og versjon

Velg PostgreSQL eller MySQL ved opprettelse. Hver type tilbyr flere versjoner, og opprettelsesnedtrekkslisten er fasiten for hva du kan starte akkurat nå — for øyeblikket omtrent PostgreSQL 14–18 og MySQL 8.0 / 8.4.

Hver versjon har en livssyklusstatus:

Status	Startbar?	Betydning
current	Ja	Nyeste fullt støttede utgivelse
supported	Ja	Fullt støttet
deprecated	Ja (merket)	Fortsatt startbar, vises med en (deprecated)-markering — planlegg å gå bort fra den
eol	Nei	Slutt på levetid — skjult fra opprettelsesnedtrekkslisten

Den anbefalte versjonen for hver type er merket (Anbefalt). Versjoner ved slutt på levetid og forhåndsvisningsversjoner tilbys ikke for nye instanser.

Dimensjonering

Instansstørrelser bruker db.gp1.<size>-størrelsesfamilien (generelt formål):

Størrelse	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 velger lagring separat (20–1000 GB). Opprettelsesdialogen viser den estimerte kostnaden før du bekrefter.

Opprette en instans

I portalen går du til Databaser → Instanser → Opprett og velger type, versjon, størrelse, lagringsstørrelse og VPC + subnett som instansen kobles til. Aktiver eventuelt høy tilgjengelighet for PostgreSQL.

Fra CLI-en

Livssykluskommandoer er typespesifikke (fm database postgres … / fm database mysql …); den typeoverskridende fm database …-gruppen lister på tvers av typer.

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

# Typeoverskridende visninger:
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
}

Koble til

Etter klargjøring viser instansens detaljside tilkoblingsinformasjonen bak en Vis påloggingsinformasjon-knapp:

• Vert — instansens private adresse
• Port — 5432 (PostgreSQL) eller 3306 (MySQL)
• Brukernavn — pgadmin (PostgreSQL) eller mysqladmin (MySQL)
• Passord — generert for deg (kan roteres)
• en klar-til-bruk tilkoblings-URI

Databaser er tilgjengelige fra instanser på samme VPC; opprettelsesflyten åpner databaseporten i instansens sikkerhetsgruppe. Koble til som med en hvilken som helst standardklient:

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

TIP

Behandle administratorpåloggingsinformasjonen som enhver hemmelighet — lagre den i Secrets eller applikasjonens hemmelighetslager, ikke i versjonskontroll.

Høy tilgjengelighet

Høy tilgjengelighet kjører en synkron standby ved siden av primærnoden. Mens synkron replikering er aktiv, ligger en commit som primærnoden har bekreftet til klienten din allerede på standbyens disk, så en failover mister ingenting som er bekreftet.

• Kun PostgreSQL. En MySQL-instans kan ikke opprettes med høy tilgjengelighet — forespørselen avvises.
• Velges ved opprettelse, og ligger fast hele instansens levetid. Høy tilgjengelighet kan verken legges til på en instans som allerede kjører eller fjernes fra den; å endre innstillingen i etterkant avvises. For å flytte en eksisterende database til en instans med høy tilgjengelighet oppretter du en ny instans og migrerer dataene dine.
• Beskyttelsen gjelder mellom verter, ikke mellom tilgjengelighetssoner. Paret deler instansens VPC og subnett, og dermed én tilgjengelighetssone. De to nodene plasseres normalt på ulike fysiske verter; når vertskapasiteten er knapp, kan paret dele én vert, så adskillelsen er et beste forsøk og ingen garanti. Høy tilgjengelighet på tvers av tilgjengelighetssoner tilbys ikke.

Aktiver den i portalens opprettelsesskjema, med --ha på CLI-en, eller med ha_enabled = true i Terraform.

HA-status

En instans med høy tilgjengelighet viser en HA-status på detaljsiden og i instanslisten:

Status	Betydning
healthy	En synkron standby strømmer og beskytter primærnodens skrivinger.
degraded	Én node betjener trafikken, og ingenting beskytter skrivingene dens — standbyen er utilgjengelig eller bygges opp igjen etter en failover.
provisioning	Paret bygges fortsatt opp.
failing_over	En failover pågår.
no_standby	Instansen har ingen standby (se nedenfor).

Hva som garanteres, og når

En commit er beskyttet mot en failover bare hvis den ble bekreftet mens synkron replikering var aktiv. HA-statusen rapporterer den tilstanden med en kort forsinkelse — opptil omtrent ett minutt — så en status som viser healthy er ikke i seg selv bevis for at commiten du nettopp gjorde, allerede ligger på standbyen.

Hvis standbyen slutter å strømme, blokkeres skrivinger kortvarig og fortsetter deretter asynkront: plattformen slipper den synkrone replikeringen slik at instansen fortsetter å ta imot skrivinger, og rapporterer den som degraded. Det er en bevisst avveining — databasen forblir tilgjengelig, og prisen er at commits som bekreftes i det forringede vinduet ennå ikke ligger på standbyen og kan gå tapt hvis en failover skjer før standbyen har tatt igjen. Når standbyen er i synk igjen, går statusen tilbake til healthy, og nye commits er beskyttet på nytt.

WARNING

Følg med på HA-statusen for alt som ikke kan miste en skriving. degraded er vinduet der en failover kan koste deg bekreftede commits.

Failover

En failover bes om av deg — fra portalen, med fm-CLI-en eller via API-et. Plattformen overvåker paret kontinuerlig og rapporterer HA-statusen; å forfremme standbyen er en beslutning du tar, ikke noe plattformen gjør av seg selv.

En failover godtas bare mens HA-statusen er healthy — å veksle over til en standby som ikke er i synk, ville forkastet bekreftede skrivinger. Den har også et budsjett: maksimalt 2 failover per instans per 24 timer, med minst 30 minutter mellom forsøkene. En instans som har utført failover to ganger på ett døgn, har en feil som enda en failover ikke retter.

Tilkoblingsadressen din endres ikke. Det er hele poenget med designet — du trenger ikke peke om applikasjonen, slå opp et nytt navn eller oppdatere en tilkoblingsstreng. Åpne tilkoblinger blir kortvarig brutt og må gjenopprettes, så klienten eller tilkoblingspoolen din trenger vanlig gjenopprettingslogikk; etterpå kobler alt seg til samme adresse igjen.

Instanser opprettet før høy tilgjengelighet ble lansert

Et lite antall instanser ble opprettet med flagget for høy tilgjengelighet satt før det faktisk ble klargjort en standby for dem. De rapporterer no_standby: det finnes én node, og ingen failover-beskyttelse. no_standby løser seg ikke selv, og høy tilgjengelighet kan ikke legges til i etterkant — opprett en ny instans med høy tilgjengelighet og migrer til den.

Sikkerhetskopier og gjenoppretting

PostgreSQL- og MySQL-instanser støtter planlagte sikkerhetskopier og sikkerhetskopier på forespørsel. De må velges aktivt: portalens opprettelsesskjema huker av Enable Automated Backups for deg, men på CLI-en sender du --backup og i Terraform setter du backup_enabled = true — ellers opprettes instansen uten dem. Planen angis som et cron-uttrykk (0 2 * * * som standard). Hver sikkerhetskopi krypteres med tenantens egen sikkerhetskopinøkkel før den forlater instansen.

Oppbevaringstiden er minst 35 dager og maksimalt 90. Sikkerhetskopier skrives til uforanderlig, objektlåst lagring som beholder hvert objekt i 35 dager, så en kortere oppbevaringstid kunne ikke slettet noe tidligere — API-et avviser den. At du selv sletter en sikkerhetskopi får effekt for deg umiddelbart; det lagrede objektet fjernes når uforanderlighetsvinduet er utløpt.

I portalen bruker du fanen Backups på instansen. En sikkerhetskopi kan bare tas mens instansen kjører. Å tilbakekalle tenantens sikkerhetskopinøkkel (fm database backup-key revoke) slår av både sikkerhetskopiering og gjenoppretting for alle administrerte databaser i tenanten til du aktiverer den igjen.

Instanser opprettet før sikkerhetskopiene ble lansert

Agenten som tar sikkerhetskopier følger med instansbildet, så en instans som ble opprettet før administrerte sikkerhetskopier ble lansert, mangler den: en sikkerhetskopi på en slik instans blir stående i creating og fullføres aldri. Opprett en ny instans for å få sikkerhetskopier.

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" {
  # … opprettelsesargumenter som ovenfor …
  backup_enabled        = true
  backup_schedule       = "0 2 * * *"
  backup_retention_days = 35
}

Gjenoppretting

Gjenoppretting er ikke-destruktiv: den klargjør en ny instans fra kilden og lar kilden være urørt. PostgreSQL-instanser kan i tillegg gjenopprettes til et hvilket som helst sekund innenfor et gjenopprettingsvindu — se Gjenoppretting til et tidspunkt.

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

Mens en gjenoppretting fra en instans fortsatt pågår — fra en sikkerhetskopi eller til et tidspunkt — kan ikke kilden slettes: sletting ville få gjenopprettingen til å mislykkes. Portalen, fm og Terraform får alle 409 restore_from_instance_in_progress. Vent til den gjenopprettede instansen er running (eller error, hvis gjenopprettingen mislyktes), og slett deretter kilden.

Sletting av en instans er permanent

Sletting av en instans fjerner den og lagringsvolumet. Ta en sikkerhetskopi først hvis du kan trenge dataene — og behold en egen logisk dump et varig sted, slik som objektlagring, hvis du vil ha en kopi utenfor plattformen:

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

Gjenoppretting til et tidspunkt

Gjenoppretting til et tidspunkt (PITR) gjenoppretter en PostgreSQL-instans til et hvilket som helst sekund innenfor gjenopprettingsvinduet, ikke bare til øyeblikket en sikkerhetskopi ble tatt. Plattformen arkiverer instansens write-ahead-logg kontinuerlig, så mens arkiveringen kjører, står høyst fem minutter med skriving i fare (se Når arkiveringen pauses). Som all gjenoppretting bygger den en ny instans og lar kilden være urørt.

"Restorable to" — det nyeste øyeblikket du faktisk kan gjenopprette til — ligger normalt noen minutter bak sanntid. På en instans med lite skriving kan det ligge lenger bak, fordi plattformen først flytter den fram når den kan bevise at ingen senere commit mangler. En instans uten skrivinger kan etter en basissikkerhetskopi vise ikke noe vindu i det hele tatt til den neste gang mottar en skriving.

PITR gjelder kun PostgreSQL og krever sikkerhetskopier.

# 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

Oppgi nøyaktig én av --backup og --to-time.

Sikt innenfor vinduet, ikke mot kanten av det

"Restorable from" er den seneste av den eldste brukbare basissikkerhetskopien din — den eldste som er tatt etter et eventuelt avbrudd i arkiveringen — og oppbevaringsgrensen. Så snart det er oppbevaringstiden som avgrenser den, flytter verdien seg i sanntid, så et øyeblikk kopiert fra instance get kan allerede ha falt utenfor vinduet innen gjenopprettingen sendes inn.

Hvilke instanser kan bruke det

PITR er på som standard for nye PostgreSQL-instanser som opprettes med sikkerhetskopier. En gjenoppretting — fra en sikkerhetskopi eller til et tidspunkt — gir også en PITR-kapabel instans, så lenge kilden hadde sikkerhetskopier på og ikke var høytilgjengelig.

Om en instans noen gang kan utføre PITR, stemples ved opprettelsen, og det stempelet er permanent:

• Instanser opprettet før PITR ble lansert kan ikke gjøre det. Å gjenopprette en av dem gir en ny instans som kan.
• Instanser opprettet med høy tilgjengelighet kan ikke gjøre det, og kan ikke få det senere. Høy tilgjengelighet og PITR er et enten-eller-valg som tas ved opprettelse, og en gjenoppretting endrer det ikke — en gjenoppretting kopierer kildens høye tilgjengelighet, så den nye instansen kan heller ikke utføre PITR. For å få en høytilgjengelig database over på PITR må du opprette en ny instans uten høy tilgjengelighet og migrere dataene dine.
• En instans som opprettes med PITR slått av (--no-pitr på CLI-en, pitr_enabled = false i Terraform) kan aldri få det. Å gjenopprette den gir en ny instans som kan.

Slå det av, og på igjen

På en instans som er PITR-kapabel kan du slå PITR av senere — i portalen, eller med pitr_enabled = false i Terraform. (fm har ingen kommando for å oppdatere en instans.) Å slå det av — eller å slå av sikkerhetskopier, som lukker det på samme måte:

• stopper arkiveringen i løpet av noen minutter, og instansen har da ikke noe gjenopprettingsvindu — en gjenoppretting til et tidspunkt avvises;
• beholder basissikkerhetskopiene og den arkiverte loggen som allerede er tatt, og de faktureres fortsatt til oppbevaringstiden utløper og de ryddes bort. Oppbevaringstiden er minst 35 dager i uforanderlig lagring, så å slå av PITR stopper ikke kostnaden umiddelbart;
• starter en karenstid på 24 timer. Å slå PITR på igjen — eller å slå sikkerhetskopier på igjen, som har samme effekt — innenfor de 24 timene avvises, og avvisningen oppgir tidspunktet du kan prøve på nytt.

Når du slår det på igjen, starter vinduet på nytt ved neste basissikkerhetskopi. Det rekker ikke tilbake over avbruddet.

Basissikkerhetskopier og planen

På en PITR-instans er den planlagte sikkerhetskopien en basissikkerhetskopi: en fysisk kopi som den arkiverte loggen spilles av på. Den kjører på din egen sikkerhetskopiplan — det finnes ingen egen PITR-frekvens. Sikkerhetskopier du selv tar på forespørsel, forblir logiske (full) og flyttbare.

Hvis du ikke angir noen plan, velger plattformen en ut fra instansens lagringsstørrelse; større volumer trenger lengre tid mellom planlagte sikkerhetskopier. Hvis du angir en plan plattformen ikke kan opprettholde ved den størrelsen, avvises forespørselen med en melding som oppgir minsteintervallet for størrelsen din. La planfeltet i portalen stå tomt for å bety «plattformens standard for denne størrelsen».

Endring av størrelse kontrollerer planen på nytt. Hvis plattformen valgte planen, velger den en ny for den nye størrelsen og rapporterer den tilbake. Hvis du skrev planen selv, avvises en ny størrelse som ikke lenger opprettholder den — send med en plan som gjør det i samme forespørsel (med Terraform; størrelsesendringen i portalen og i fm tar bare størrelsen), så trer størrelsesendringen og den nye planen i kraft sammen.

En størrelsesendring avvises mens en hvilken som helst sikkerhetskopi kjører. Vent til den er ferdig, og prøv på nytt.

Gjenopprettingstiden vokser med intervallet mellom basissikkerhetskopiene, fordi mer logg må spilles av: omtrent 16 sekunder per GB for å pakke ut basisen, pluss omtrent 2,3 timer for hvert travle døgn med logg, før tiden som går med til å hente den. En daglig basis ligger i størrelsesorden et par timer; en ukentlig i størrelsesorden 16 timer.

Når arkiveringen pauses

Hver tenant har et tak for hvor mange byte med PITR-data den kan oppbevare om gangen. Når en tenant når det, slutter plattformen å ta imot nye loggsegmenter for tenantens instanser, og instansen rapporterer arkiveringen som pauset med årsaken tenant_cap — fm database postgres instance get skriver ut "Archiving paused", og API-et og Terraform bærer selve årsaken. Plattformen kan også pause arkiveringen for hele flåten under en hendelse, noe som vises som platform_disabled.

En tenant over taket har ikke noe gjenopprettingsvindu

Mens en tenant er over taket, har PITR-instansene dens ikke noe gjenopprettingsvindu i det hele tatt, og en gjenoppretting til et tidspunkt avvises. Vinduet kommer ikke tilbake før tenanten er under taket igjen.

Planlagte basissikkerhetskopier fortsetter å kjøre i mellomtiden. Hver av dem er en full kopi av volumet og oppbevares og faktureres som alle andre, men ingen av dem danner vinduet på nytt mens taket binder. Eldre basissikkerhetskopier utløper etter sin egen oppbevaringstid, så en tenant over taket kommer under det igjen uten inngripen bare når den utløpingen går raskere enn de nye basisene kommer til.

For å komme tilbake raskere slår du av PITR på instansen som produserer mest logg, gjør sikkerhetskopiplanen dens sjeldnere, eller ber support om å heve tenantens tak.

Basissikkerhetskopier i sikkerhetskopilisten

Basissikkerhetskopier vises i sikkerhetskopilisten med typen base, ved siden av de logiske full-sikkerhetskopiene dine. De administreres av plattformen: du kan ikke slette en — forespørselen avvises — og du kan ikke opprette en på forespørsel. De fjernes automatisk når en nyere basis erstatter dem og oppbevaringstiden er utløpt; en basis som aldri ble brukbar, utløper etter sin egen oppbevaringstid.

PITR-lagring — basissikkerhetskopier og arkivert logg — måles på den samme database_backup-linjen som de øvrige sikkerhetskopiene for administrerte databaser. Prisene kommer fra plattformens priskatalog og vises i portalen; denne guiden oppgir ingen beløp. Se Fakturering.

Feil du kan møte

Kode	Hva det betyr	Hva du gjør
pitr_unavailable_for_instance	Denne instansen kan ikke utføre PITR. Årsaken sier hvilken: type (kun PostgreSQL), ha (høy tilgjengelighet), legacy (opprettet før PITR, eller opprettet med det avslått), not_enabled (kapabel, men PITR eller sikkerhetskopier er av nå)	For not_enabled: slå på PITR og sikkerhetskopier; vinduet starter ved neste basissikkerhetskopi. For legacy: gjenopprett til en ny instans. ha og type kan ikke endres på en eksisterende instans, og en gjenoppretting kopierer begge.
pitr_window_unavailable	Det finnes ikke noe gjenopprettingsvindu — den første basissikkerhetskopien kjører fortsatt, et hull startet det på nytt, eller tenanten er over taket sitt	Sjekk vinduet igjen senere. Ikke prøv på nytt automatisk med faste intervaller.
pitr_out_of_window	Tidspunktet du ba om, er utenfor vinduet. Feilen bærer med seg vinduets grenser	Velg et tidspunkt innenfor grensene den oppgir, og send inn på nytt.
invalid_input	En sikkerhetskopi og et tidspunkt sammen, eller ingen av dem; en base-rad oppgitt som sikkerhetskopi å gjenopprette fra; PITR uten sikkerhetskopier; en plan under gulvet for instansens størrelse	Les meldingen — den oppgir hvilken.
conflict	backup_running: en størrelsesendring mens en sikkerhetskopi kjører. pitr_cooldown: gjenaktivering innenfor karenstiden på 24 timer, med tidspunktet du kan prøve på nytt. base_managed: sletting av en basissikkerhetskopi	Vent og prøv på nytt, bortsett fra base_managed — basissikkerhetskopier kan ikke slettes.

Med Terraform

resource "frostmoln_postgres_instance" "app" {
  # … opprettelsesargumenter som ovenfor …
  backup_enabled = true
  pitr_enabled   = true
  # backup_schedule er ikke satt: plattformen velger en for denne lagringsstørrelsen
}

Full attributtreferanse: frostmoln_postgres_instance.

• Skriv pitr_enabled eksplisitt. Plattformen stempler den ved opprettelsen og stempelet er permanent, så en instans som opprettes uten PITR kan aldri få det. Utelater du den, får du det plattformen bestemmer, som kan være på — og faktureres.
• Vindusattributtene vises som "known after apply" i enhver plan som endrer noe. latest_restorable_time flytter seg for hvert arkiverte segment, så den er aldri den samme ved plan-tidspunktet og ved apply-tidspunktet. Det er tilsiktet — les av verdiene, ikke lås deg til dem.
• restore_from kan bare settes ved opprettelse. Å peke den mot en annen kilde eller et annet tidspunkt erstatter ressursen, noe som ødelegger den gjenopprettede databasen. Å legge den til på en instans som allerede finnes avvises, og import av en gjenopprettet instans registrerer ingenting.
• Å fjerne restore_from er ikke en nulloperasjon. Det er én enkelt oppdatering på stedet som tømmer det Terraform hadde notert. Ingenting endres på plattformen, og neste terraform plan er ren.
• Gjenopprettingsmålet bygges ut fra kildens egen form, så kilden må være en PostgreSQL-instans, og version, flavor_id, ha_enabled, vpc_id og subnet_id må være like kildens. storage_gb kan være større, aldri mindre. Terraform leser kilden først og avviser med avviket navngitt, i stedet for stille å opprette en tom database.

Etter en mislykket gjenoppretting: oppdater før du leser planen

En gjenoppretting oppretter først den nye instansen, og bruker deretter de resterende forskjellene (lagring, sikkerhetskopier, tidsplan, pitr_enabled) som én oppdatering. Hvis den oppdateringen mislykkes, registrerer Terraforms tilstand det planen ba om, ikke det plattformen faktisk har — og ressursen merkes bevisst ikke som tainted, fordi det ville ødelagt den gjenopprettede databasen ved neste terraform apply.

Avviket kommer bare fram ved en refresh. terraform plan -refresh=false viser ingen forskjell i det hele tatt. Kjør terraform plan (eller terraform refresh) og bruk oppdateringen på stedet som den da rapporterer.

PostgreSQL-utvidelser

PostgreSQL-instanser kan aktivere utvidelser fra plattformens utvidelseskatalog — TimescaleDB, pg_stat_statements, pg_trgm og pgcrypto i dag, flere etter hvert som katalogen vokser. De som krever shared_preload_libraries (TimescaleDB, pg_stat_statements) betaler et omstartsvindu, og plattformen kjører én operasjon om gangen. Se PostgreSQL-utvidelser.

Stoppe, starte og starte på nytt

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

• Stopp slår av serveren kontrollert. Instansen viser stopping og deretter stopped. Databehandling faktureres ikke mens den er stoppet; lagring for gjenoppretting til et tidspunkt faktureres.
• Start starter en stoppet instans: starting og deretter running, på samme adresse og med de samme dataene.
• Omstart starter en kjørende instans på nytt: restarting og deretter running. Alle tilkoblinger brytes under omstarten; klienter må koble til på nytt.
• Hver handling tar et minutt eller to. fm venter til instansen har landet; bruk --no-wait for å returnere så snart handlingen er mottatt. Hvis en handling mislykkes, viser instansen error. Kontakt support, som kan prøve den på nytt.
• Høy tilgjengelighet: en instans med høy tilgjengelighet kan ennå ikke stoppes (omstart fungerer). Ingenting kan stoppes eller startes på nytt under en failover, en pågående sikkerhetskopiering eller et bytte av påloggingsinformasjon. Vent til det er ferdig, og prøv igjen.
• Lesereplikaer fortsetter å kjøre mens primærinstansen er stoppet, og tar igjen det tapte når den startes igjen.

Livssyklus og begrensninger

• Versjoner er låst for instansens levetid — oppgraderinger på stedet er ennå ikke tilgjengelige. For å gå over til en nyere hovedversjon, opprett en ny instans på den versjonen og migrer dataene dine (f.eks. med pg_dump / mysqldump).
• Høy tilgjengelighet ligger fast hele instansens levetid — den velges ved opprettelse og kan ikke legges til eller fjernes senere (se ovenfor).
• Sletting er permanent og fjerner lagringsvolumet (se ovenfor).
• En instans lever i én VPC/ett subnett (én region).

Relatert

• PostgreSQL-utvidelser
• Nettverk: VPC-er · Sikkerhetsgrupper
• Objektlagring (et sted å oppbevare dumpene dine)
• Cacher · Fakturering