Hallitut tietokannat

Frostmoln ajaa puolestasi hallittuja PostgreSQL- ja MySQL-instansseja — alusta luo virtuaalikoneen, liittää pysyvän tallennustilan, määrittää palvelimen ja antaa sinulle käyttövalmiin yhteyden. Sinä hallitset dataasi; me hallitsemme alla olevaa infrastruktuuria.

Tyypin ja version valinta

Valitse luontihetkellä PostgreSQL tai MySQL. Kummallakin tyypillä on useita versioita, ja luonnin pudotusvalikko on totuuden lähde sille, mitä voit tällä hetkellä käynnistää — tällä hetkellä noin PostgreSQL 14–18 ja MySQL 8.0 / 8.4.

Jokaisella versiolla on elinkaaren tila:

Tila	Käynnistettävissä?	Merkitys
current	Kyllä	Uusin täysin tuettu julkaisu
supported	Kyllä	Täysin tuettu
deprecated	Kyllä (merkitty)	Edelleen käynnistettävissä, näytetään (deprecated)-merkinnällä — suunnittele siirtyminen pois
eol	Ei	Elinkaaren loppu — piilotettu luonnin pudotusvalikosta

Kunkin tyypin suositeltu versio on merkitty (Recommended). Elinkaaren loppupäässä olevia ja esikatseluversioita ei tarjota uusille instansseille.

Mitoitus

Instanssien koot käyttävät db.gp1.<size>-kokoperhettä (yleiskäyttöinen):

Koko	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

Valitset tallennustilan erikseen (20–1000 GB). Luontidialogi näyttää arvioidun kustannuksen ennen vahvistusta.

Luo instanssi

Mene portaalissa kohtaan Databases → Instances → Create ja valitse tyyppi, versio, koko, tallennustilan koko sekä VPC + aliverkko, johon instanssi liitetään. Ota halutessasi käyttöön korkea käytettävyys PostgreSQL:lle.

Komentoriviltä

Elinkaarikomennot ovat tyyppikohtaisia (fm database postgres … / fm database mysql …); tyypit ylittävä fm database … -ryhmä listaa tyyppien poikki.

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

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

# Tyypit ylittävät näkymät:
fm database instance list
fm database version list

Terraformilla

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
}

Yhdistä

Provisioinnin jälkeen instanssin tietosivu paljastaa yhteystiedot Show Credentials -painikkeen takaa:

• Host — instanssin yksityinen osoite
• Port — 5432 (PostgreSQL) tai 3306 (MySQL)
• Username — pgadmin (PostgreSQL) tai mysqladmin (MySQL)
• Password — sinulle generoitu (kierrätettävissä)
• käyttövalmis yhteyden URI

Tietokannat ovat tavoitettavissa samassa VPC:ssä olevista instansseista; luontiprosessi avaa tietokantaportin instanssin suojausryhmässä. Yhdistä kuten millä tahansa vakioasiakkaalla:

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

TIP

Käsittele järjestelmänvalvojan tunnistetietoja kuten mitä tahansa salaisuutta — tallenna ne Secrets-palveluun tai sovelluksesi salaisuusvarastoon, älä lähdekoodin hallintaan.

Korkea käytettävyys

Korkea käytettävyys ylläpitää synkronista varapalvelinta ensisijaisen instanssin rinnalla. Synkronisen replikoinnin ollessa käytössä commit, jonka ensisijainen instanssi on kuitannut asiakkaallesi, on jo varapalvelimen levyllä, joten vikasiirto ei menetä mitään kuitattua.

• Vain PostgreSQL. MySQL-instanssia ei voi luoda korkealla käytettävyydellä — pyyntö hylätään.
• Valitaan luontihetkellä ja pysyy kiinteänä instanssin koko eliniän. Korkeaa käytettävyyttä ei voi lisätä käynnissä olevaan instanssiin eikä poistaa siitä; asetuksen muuttaminen jälkikäteen hylätään. Siirtääksesi olemassa olevan tietokannan korkean käytettävyyden instanssiin luo uusi instanssi ja siirrä datasi.
• Suoja on isäntäkoneiden välinen, ei saatavuusvyöhykkeiden välinen. Pari jakaa instanssin VPC:n ja aliverkon ja siten yhden saatavuusvyöhykkeen. Kaksi solmua sijoitetaan tavallisesti eri fyysisille isäntäkoneille; isäntäkapasiteetin ollessa niukka pari voi jakaa saman isäntäkoneen, joten erottelu on pyrkimys eikä takuu. Saatavuusvyöhykkeiden välistä korkeaa käytettävyyttä ei tarjota.

Ota se käyttöön portaalin luontilomakkeella, komentorivillä valitsimella --ha tai Terraformissa asetuksella ha_enabled = true.

HA-tila

Korkean käytettävyyden instanssi näyttää HA-tilan tietosivullaan ja instanssiluettelossa:

Tila	Merkitys
healthy	Synkroninen varapalvelin vastaanottaa muutosvirtaa ja suojaa ensisijaisen instanssin kirjoituksia.
degraded	Yksi solmu palvelee eikä mikään suojaa sen kirjoituksia — varapalvelin ei ole käytettävissä tai sitä rakennetaan uudelleen vikasiirron jälkeen.
provisioning	Paria rakennetaan yhä.
failing_over	Vikasiirto on käynnissä.
no_standby	Instanssilla ei ole varapalvelinta (katso alta).

Mitä taataan ja milloin

Commit on suojassa vikasiirrolta vain, jos se kuitattiin synkronisen replikoinnin ollessa käytössä. HA-tila raportoi tuon tilan lyhyellä viiveellä — noin minuuttiin asti — joten tila healthy ei sinänsä ole todiste siitä, että juuri tekemäsi commit on jo varapalvelimella.

Jos varapalvelin lakkaa vastaanottamasta muutosvirtaa, kirjoitukset estyvät hetkeksi ja jatkuvat sitten asynkronisesti: alusta luopuu synkronisesta replikoinnista, jotta instanssi ottaa edelleen kirjoituksia vastaan, ja raportoi sen tilaksi degraded. Tämä on tietoinen valinta — tietokanta pysyy käytettävissä, ja hintana on, että heikentyneen jakson aikana kuitatut commitit eivät vielä ole varapalvelimella ja ne voidaan menettää, jos vikasiirto tapahtuu ennen kuin varapalvelin on saanut kiinni. Kun varapalvelin on jälleen synkronissa, tila palaa arvoon healthy ja uudet commitit ovat taas suojassa.

WARNING

Seuraa HA-tilaa kaikessa, joka ei saa menettää kirjoitusta. degraded on se jakso, jonka aikana vikasiirto voi maksaa sinulle kuitattuja committeja.

Vikasiirto

Vikasiirtoa pyydät sinä — portaalista, fm-komentorivityökalulla tai API:n kautta. Alusta tarkkailee paria jatkuvasti ja raportoi sen HA-tilan; varapalvelimen ylentäminen on sinun päätöksesi, ei jotain jonka alusta tekee omasta aloitteestaan.

Vikasiirto hyväksytään vain, kun HA-tila on healthy — vaihtaminen varapalvelimeen, joka ei ole synkronissa, hylkäisi kuitattuja kirjoituksia. Sillä on myös budjetti: enintään 2 vikasiirtoa instanssia kohti 24 tunnissa, ja vähintään 30 minuuttia yritysten välillä. Instanssilla, joka on tehnyt vikasiirron kahdesti vuorokaudessa, on vika, jota uusi vikasiirto ei korjaa.

Yhteysosoitteesi ei muutu. Se on koko suunnittelun ydin — sinun ei tarvitse osoittaa sovellustasi uudelleen, selvittää uutta nimeä tai päivittää yhteysmerkkijonoa. Avoimet yhteydet katkeavat hetkeksi ja ne on muodostettava uudelleen, joten asiakasohjelmasi tai yhteyspoolisi tarvitsee tavanomaisen uudelleenyhdistämislogiikan; sen jälkeen kaikki yhdistyy samaan osoitteeseen.

Ennen korkean käytettävyyden julkaisua luodut instanssit

Pieni joukko instansseja luotiin korkean käytettävyyden lippu asetettuna ennen kuin niille tosiasiassa luotiin varapalvelin. Ne raportoivat tilaa no_standby: solmuja on yksi eikä vikasiirtosuojaa ole. no_standby ei korjaannu itsestään, eikä korkeaa käytettävyyttä voi lisätä jälkikäteen — luo uusi instanssi korkealla käytettävyydellä ja siirry siihen.

Varmuuskopiot ja palautus

PostgreSQL- ja MySQL-instanssit tukevat ajastettuja ja pyynnöstä otettavia varmuuskopioita. Ne otetaan käyttöön erikseen: portaalin luontilomake rastittaa Enable Automated Backups puolestasi, mutta komentorivillä annat --backup ja Terraformissa asetat backup_enabled = true — muuten instanssi luodaan ilman niitä. Aikataulu annetaan cron-lausekkeena (oletuksena 0 2 * * *). Jokainen varmuuskopio salataan tenantisi omalla varmuuskopiointiavaimella ennen kuin se poistuu instanssista.

Säilytysaika on vähintään 35 ja enintään 90 päivää. Varmuuskopiot kirjoitetaan muuttumattomaan, objektilukittuun tallennustilaan, joka säilyttää jokaisen objektin 35 päivää, joten lyhyempi säilytysaika ei voisi poistaa mitään aiemmin — API hylkää sen. Itse tekemäsi varmuuskopion poisto tulee voimaan sinulle heti; tallennettu objekti siivotaan, kun sen muuttumattomuusikkuna on kulunut.

Portaalissa käytä instanssin Backups-välilehteä. Varmuuskopion voi ottaa vain, kun instanssi on käynnissä. Tenantisi varmuuskopiointiavaimen peruminen (fm database backup-key revoke) poistaa käytöstä sekä varmuuskopioinnin että palautuksen kaikilta tenantin hallituilta tietokannoilta, kunnes otat sen uudelleen käyttöön.

Ennen varmuuskopioiden julkaisua luodut instanssit

Varmuuskopioagentti tulee instanssin levykuvan mukana, joten ennen hallittujen varmuuskopioiden julkaisua luotu instanssi ei sisällä sitä: tällaisen instanssin varmuuskopio jää tilaan creating eikä valmistu koskaan. Luo uusi instanssi saadaksesi varmuuskopiot.

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" {
  # … luontiargumentit kuten yllä …
  backup_enabled        = true
  backup_schedule       = "0 2 * * *"
  backup_retention_days = 35
}

Palautus

Palautus ei ole tuhoava: se luo lähteestä uuden instanssin ja jättää lähteen koskemattomaksi. PostgreSQL-instanssit voivat lisäksi palautua mihin tahansa sekuntiin palautusikkunan sisällä — katso Ajanhetkeen palauttaminen.

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

Kun palautus instanssista on vielä käynnissä — varmuuskopiosta tai ajanhetkeen — lähdettä ei voi poistaa: poistaminen saisi palautuksen epäonnistumaan. Portaali, fm ja Terraform saavat kaikki vastauksen 409 restore_from_instance_in_progress. Odota, kunnes palautettu instanssi on tilassa running (tai error, jos palautus epäonnistui), ja poista lähde vasta sitten.

Instanssin poistaminen on pysyvää

Instanssin poistaminen poistaa sen ja sen tallennustilavolyymin. Ota ensin varmuuskopio, jos saatat tarvita dataa — ja säilytä oma looginen vedos jossakin kestävässä, kuten objektitallennustilassa, jos haluat kopion alustan ulkopuolelle:

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

Ajanhetkeen palauttaminen

Ajanhetkeen palauttaminen (PITR) palauttaa PostgreSQL-instanssin mihin tahansa sekuntiin sen palautusikkunan sisällä, ei ainoastaan siihen hetkeen, jona varmuuskopio otettiin. Alusta arkistoi instanssin write-ahead-lokia jatkuvasti, joten arkistoinnin ollessa käynnissä vaarassa on enintään viiden minuutin edestä kirjoituksia (katso Kun arkistointi keskeytyy). Kuten jokainen palautus, sekin rakentaa uuden instanssin ja jättää lähteen koskemattomaksi.

"Restorable to" — uusin hetki, johon todella voit palautua — jää normaalisti reaaliajasta jälkeen muutaman minuutin. Vähän kirjoitetulla instanssilla se voi jäädä jälkeen pidempään, koska alusta siirtää sitä eteenpäin vasta, kun se voi todistaa, ettei yhtään myöhempää commitia puutu. Instanssi, johon ei kirjoiteta, voi perusvarmuuskopion jälkeen näyttää, ettei ikkunaa ole lainkaan, kunnes se seuraavan kerran vastaanottaa kirjoituksen.

PITR on vain PostgreSQL:lle ja vaatii varmuuskopiot.

# Ikkuna: "Restorable from" ja "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

Anna täsmälleen toinen valitsimista --backup ja --to-time.

Tähtää ikkunan sisälle, älä sen reunaan

"Restorable from" on myöhempi näistä kahdesta: vanhin käyttökelpoinen perusvarmuuskopiosi — vanhin, joka on otettu arkistoinnin mahdollisen katkoksen jälkeen — tai säilytysajan katkaisuhetki. Kun säilytysaika on se, joka rajaa sitä, arvo etenee reaaliajassa, joten instance get -komennosta kopioitu hetki voi jo olla pudonnut ikkunan ulkopuolelle siinä vaiheessa, kun palautus lähetetään.

Mitkä instanssit voivat käyttää sitä

PITR on oletuksena käytössä uusilla PostgreSQL-instansseilla, jotka luodaan varmuuskopioiden kanssa. Palautus — varmuuskopiosta tai ajanhetkeen — tuottaa instanssin, joka sekin kykenee PITR:ään, kunhan lähteellä oli varmuuskopiot käytössä eikä se ollut korkeasti käytettävä.

Se, voiko instanssi koskaan tehdä PITR:ää, leimataan luontihetkellä, ja leima on pysyvä:

• Ennen PITR:n julkaisua luodut instanssit eivät voi tehdä sitä. Sellaisen palauttaminen tuottaa uuden instanssin, joka voi.
• Korkealla käytettävyydellä luodut instanssit eivät voi tehdä sitä, eikä sitä voi antaa niille myöhemmin. Korkea käytettävyys ja PITR ovat luontihetkellä tehtävä joko–tai-valinta, eikä palautus muuta sitä — palautus kopioi lähteen korkean käytettävyyden, joten uusikaan instanssi ei voi tehdä PITR:ää. Saadaksesi korkeasti käytettävän tietokannan PITR:n piiriin sinun on luotava uusi instanssi ilman korkeaa käytettävyyttä ja siirrettävä tietosi sinne.
• Instanssille, joka on luotu PITR pois kytkettynä (komentorivillä --no-pitr, Terraformissa pitr_enabled = false), sitä ei voi koskaan antaa. Sen palauttaminen tuottaa uuden instanssin, joka voi.

Pois kytkeminen ja takaisin käyttöön

Instanssilla, joka kykenee PITR:ään, voit kytkeä PITR:n myöhemmin pois — portaalissa tai Terraformissa asetuksella pitr_enabled = false. (fm-työkalussa ei ole instanssin päivityskomentoa.) Pois kytkeminen — tai varmuuskopioiden kytkeminen pois, mikä sulkee sen samalla tavalla:

• pysäyttää arkistoinnin muutamassa minuutissa, eikä instanssilla sen jälkeen ole lainkaan palautusikkunaa — ajanhetkeen palautus hylätään;
• säilyttää jo otetut perusvarmuuskopiot ja arkistoidun lokin, ja ne pysyvät laskutettavina, kunnes säilytysaika umpeutuu ja ne siivotaan. Säilytysaika on vähintään 35 päivää muuttumattomassa tallennustilassa, joten PITR:n pois kytkeminen ei lopeta veloitusta välittömästi;
• käynnistää 24 tunnin jäähtymisajan. PITR:n kytkeminen takaisin käyttöön — tai varmuuskopioiden kytkeminen takaisin käyttöön, jolla on sama vaikutus — noiden 24 tunnin sisällä hylätään, ja hylkäys kertoo ajan, jolloin voit yrittää uudelleen.

Kun kytket sen takaisin käyttöön, ikkuna alkaa uudelleen seuraavasta perusvarmuuskopiosta. Se ei ulotu taaksepäin katkoksen yli.

Perusvarmuuskopiot ja aikataulu

PITR-instanssilla ajastettu varmuuskopio on perusvarmuuskopio: fyysinen kopio, jonka päälle arkistoitu loki toistetaan. Se ajetaan omalla varmuuskopiointiaikataulullasi — erillistä PITR-tahtia ei ole. Itse pyynnöstä ottamasi varmuuskopiot pysyvät loogisina (full) ja siirrettävinä.

Jos et aseta aikataulua, alusta valitsee sellaisen instanssin tallennustilan koon perusteella; suuremmat volyymit tarvitsevat pidemmän välin ajastettujen varmuuskopioiden välille. Jos asetat aikataulun, jota alusta ei kykene ylläpitämään kyseisellä koolla, pyyntö hylätään viestillä, joka kertoo koollesi sallitun vähimmäisvälin. Jätä portaalin aikataulukenttä tyhjäksi, kun tarkoitat "alustan oletus tälle koolle".

Koon muutos tarkistaa aikataulun uudelleen. Jos alusta valitsi aikataulun, se valitsee uuden koon mukaisen ja raportoi sen takaisin. Jos kirjoitit aikataulun itse, uusi koko, joka ei enää ylläpidä sitä, hylätään — lähetä samassa pyynnössä (Terraformilla; portaalin ja fm:n koon muutos ottaa vain koon) aikataulu, joka ylläpitää, niin koon muutos ja uusi aikataulu tulevat voimaan yhdessä.

Koon muutos hylätään, kun mikä tahansa varmuuskopio on käynnissä. Odota sen valmistumista ja yritä sitten uudelleen.

Palautusaika kasvaa perusvarmuuskopioiden välisen ajan mukana, koska lokia on toistettava enemmän: noin 16 sekuntia gigatavua kohti perustan purkamiseen, plus noin 2,3 tuntia jokaista kiireistä lokipäivää kohti, ennen kuin lasketaan mukaan lokin noutamiseen kuluva aika. Päivittäinen perusta on suuruusluokaltaan pari tuntia; viikoittainen suuruusluokaltaan 16 tuntia.

Kun arkistointi keskeytyy

Jokaisella tenantilla on katto sille, kuinka monta tavua PITR-dataa se saa säilyttää kerrallaan. Kun tenant saavuttaa sen, alusta lakkaa ottamasta vastaan uusia lokisegmenttejä kyseisen tenantin instansseilta, ja instanssi raportoi arkistoinnin keskeytyneeksi syyllä tenant_cap — fm database postgres instance get tulostaa "Archiving paused", ja API ja Terraform välittävät itse syyn. Alusta voi myös keskeyttää arkistoinnin koko alustan laajuisesti häiriön aikana, mikä näkyy arvona platform_disabled.

Katon ylittäneellä tenantilla ei ole palautusikkunaa

Kun tenant on katon yli, sen PITR-instansseilla ei ole palautusikkunaa lainkaan, ja ajanhetkeen palauttaminen hylätään. Ikkuna palaa vasta, kun tenant on taas katon alla.

Ajastetut perusvarmuuskopiot jatkuvat sillä välin. Jokainen niistä on volyymin täysi kopio, ja se säilytetään ja laskutetaan kuten muutkin, mutta mikään niistä ei muodosta ikkunaa uudelleen katon rajoittaessa. Vanhemmat perusvarmuuskopiot vanhenevat oman säilytysaikansa mukaan, joten katon ylittänyt tenant palaa katon alle ilman toimenpiteitä vain, jos vanhenemista tapahtuu nopeammin kuin uusia perustoja syntyy.

Toipuaksesi nopeammin kytke PITR pois siltä instanssilta, joka tuottaa eniten lokia, harvenna sen varmuuskopiointiaikataulua tai ota yhteyttä tukeen tenanttisi katon nostamiseksi.

Perusvarmuuskopiot varmuuskopioluettelossa

Perusvarmuuskopiot näkyvät varmuuskopioluettelossa tyypillä base loogisten full-varmuuskopioidesi vierellä. Ne ovat alustan hallinnoimia: et voi poistaa niitä — pyyntö hylätään — etkä voi luoda niitä pyynnöstä. Ne poistetaan automaattisesti, kun uudempi perusta korvaa ne ja säilytysaika on kulunut; perusta, josta ei koskaan tullut käyttökelpoista, vanhenee oman säilytysaikansa mukaan.

PITR-tallennustila — perusvarmuuskopiot ja arkistoitu loki — mitataan samalle database_backup-riville kuin muutkin hallittujen tietokantojesi varmuuskopiot. Hinnat tulevat alustan hinnastokatalogista ja näytetään portaalissa; tämä opas ei mainitse summia. Katso Laskutus.

Virheet, joita voit nähdä

Koodi	Mitä se tarkoittaa	Mitä tehdä
pitr_unavailable_for_instance	Tämä instanssi ei voi tehdä PITR:ää. Syy kertoo mikä niistä: type (vain PostgreSQL), ha (korkea käytettävyys), legacy (luotu ennen PITR:ää tai luotu se pois kytkettynä), not_enabled (kykenee, mutta PITR tai varmuuskopiot ovat nyt pois käytöstä)	Arvolla not_enabled kytke PITR ja varmuuskopiot käyttöön; ikkuna alkaa seuraavasta perusvarmuuskopiosta. Arvolla legacy palauta uudeksi instanssiksi. Arvoja ha ja type ei voi muuttaa olemassa olevalla instanssilla, ja palautus kopioi molemmat.
pitr_window_unavailable	Palautusikkunaa ei ole — ensimmäinen perusvarmuuskopio on yhä käynnissä, aukko aloitti sen alusta tai tenant on kattonsa yli	Tarkista ikkuna myöhemmin uudelleen. Älä yritä uudelleen ajastimella.
pitr_out_of_window	Pyytämäsi hetki on ikkunan ulkopuolella. Virhe kertoo ikkunan rajat	Valitse hetki sen ilmoittamien rajojen sisältä ja lähetä uudelleen.
invalid_input	Varmuuskopio ja ajanhetki yhdessä, tai ei kumpaakaan; base-rivi annettu varmuuskopioksi, josta palautetaan; PITR ilman varmuuskopioita; aikataulu instanssin koolle sallitun alarajan alle	Lue viesti — se kertoo mikä niistä.
conflict	backup_running: koon muutos varmuuskopion ollessa käynnissä. pitr_cooldown: uudelleen käyttöönotto 24 tunnin jäähtymisajan sisällä, mukana aika jolloin voit yrittää uudelleen. base_managed: perusvarmuuskopion poisto	Odota ja yritä uudelleen, paitsi arvolla base_managed — perusvarmuuskopioita ei voi poistaa.

Terraformilla

resource "frostmoln_postgres_instance" "app" {
  # … luontiargumentit kuten yllä …
  backup_enabled = true
  pitr_enabled   = true
  # backup_schedule jätetty asettamatta: alusta valitsee sellaisen tälle tallennustilan koolle
}

Täydellinen attribuuttiviite: frostmoln_postgres_instance.

• Kirjoita pitr_enabled eksplisiittisesti. Alusta leimaa sen luontihetkellä ja leima on pysyvä, joten instanssille, joka on luotu ilman PITR:ää, sitä ei voi koskaan antaa. Jos jätät sen pois, saat sen, minkä alusta päättää — ja se voi olla päällä ja laskutettava.
• Ikkuna-attribuutit näkyvät muodossa "known after apply" jokaisessa muuttuvassa suunnitelmassa. latest_restorable_time etenee jokaisen arkistoidun segmentin myötä, joten se ei koskaan ole sama suunnitelma- ja toteutushetkellä. Se on tarkoituksellista — lainaa arvoja, älä kiinnitä niihin.
• restore_from asetetaan vain luontihetkellä. Sen osoittaminen toiseen lähteeseen tai hetkeen korvaa resurssin, mikä tuhoaa palautetun tietokannan. Sen lisääminen jo olemassa olevaan instanssiin hylätään, eikä palautetun instanssin tuonti kirjaa mitään.
• restore_from-attribuutin poistaminen ei ole tyhjä operaatio. Se on yksi paikallaan tehtävä päivitys, joka tyhjentää Terraformin säilyttämän kirjauksen. Alustalla ei muutu mikään, ja seuraava suunnitelma on puhdas.
• Palautuksen kohde rakennetaan lähteen oman muodon pohjalta, joten lähteen on oltava PostgreSQL-instanssi ja version, flavor_id, ha_enabled, vpc_id ja subnet_id on oltava samat kuin lähteellä. storage_gb saa olla suurempi, ei koskaan pienempi. Terraform lukee lähteen ensin ja hylkää pyynnön nimeten eroavan arvon sen sijaan, että loisi hiljaisesti tyhjän tietokannan.

Epäonnistuneen palautuksen jälkeen päivitä tila ennen kuin luet suunnitelman

Palautus luo ensin uuden instanssin ja soveltaa sitten loput erot (tallennustila, varmuuskopiot, aikataulu, pitr_enabled) yhtenä päivityksenä. Jos tuo päivitys epäonnistuu, Terraformin tila kirjaa sen mitä suunnitelma pyysi, ei sitä mitä alustalla tosiasiassa on — eikä resurssia merkitä tarkoituksella pilatuksi, koska merkitseminen tuhoaisi palautetun tietokannan seuraavalla toteutuksella.

Ero paljastuu vain tilan päivityksessä. terraform plan -refresh=false ei näytä eroa lainkaan. Aja terraform plan (tai terraform refresh) ja toteuta paikallaan tehtävä päivitys, jonka se sitten raportoi.

PostgreSQL-laajennukset

PostgreSQL-instansit voivat ottaa käyttöön laajennuksia alustan laajennuskatalogista — TimescaleDB, pg_stat_statements, pg_trgm ja pgcrypto tänään, lisää kun katalogi kasvaa. shared_preload_libraries-vaatimuksiset (TimescaleDB, pg_stat_statements) maksavat uudelleenkäynnistysikkunan, ja alusta suorittaa yhden operaation kerrallaan. Katso PostgreSQL-laajennukset.

Pysäytys, käynnistys ja uudelleenkäynnistys

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

• Pysäytys sammuttaa palvelimen hallitusti. Instanssin tila on ensin stopping ja sitten stopped. Laskentaa ei laskuteta pysäytyksen aikana; ajankohtaan palautuksen tallennustila laskutetaan.
• Käynnistys käynnistää pysäytetyn instanssin: starting ja sitten running, samassa osoitteessa ja samoilla tiedoilla.
• Uudelleenkäynnistys käynnistää käynnissä olevan instanssin uudelleen: restarting ja sitten running. Kaikki yhteydet katkeavat uudelleenkäynnistyksen ajaksi; asiakkaiden on yhdistettävä uudelleen.
• Kukin toiminto kestää minuutin tai kaksi. fm odottaa, kunnes instanssi on asettunut; --no-wait palaa heti, kun toiminto on vastaanotettu. Jos toiminto epäonnistuu, instanssin tila on error. Ota yhteyttä tukeen, joka voi yrittää sitä uudelleen.
• Korkea käytettävyys: korkean käytettävyyden instanssia ei vielä voi pysäyttää (uudelleenkäynnistys toimii). Mitään ei voi pysäyttää tai käynnistää uudelleen vikasiirron, käynnissä olevan varmuuskopioinnin tai tunnistetietojen vaihdon aikana. Odota, että se valmistuu, ja yritä uudelleen.
• Lukukopiot jatkavat toimintaansa, kun niiden ensisijainen instanssi on pysäytetty, ja kuroutuvat ajan tasalle, kun se käynnistetään uudelleen.

Elinkaari ja rajoitukset

• Versiot ovat kiinteät instanssin koko eliniän ajan — paikallaan tehtäviä päivityksiä ei ole vielä saatavilla. Siirtyäksesi uudempaan pääversioon luo uusi instanssi kyseisellä versiolla ja siirrä datasi (esim. pg_dump- / mysqldump-työkalulla).
• Korkea käytettävyys on kiinteä instanssin koko eliniän ajan — se valitaan luontihetkellä eikä sitä voi lisätä tai poistaa myöhemmin (katso yltä).
• Poistaminen on pysyvää ja poistaa tallennustilavolyymin (katso yltä).
• Instanssi sijaitsee yhdessä VPC:ssä/aliverkossa (yhdellä alueella).

Aiheeseen liittyvää

• PostgreSQL-laajennukset
• Verkko: VPC:t · Suojausryhmät
• Objektitallennustila (paikka vedoksillesi)
• Välimuistit · Laskutus