hi,
Van 1 gép, ami GCP-ben van és egy másik, ami kishazánk egyik hosting szolgáltatójánál. A két gép között ha pl. scp-vel nézem, jó minőségű kapcsolatot látok, azaz nagy sávszélességet és alacsony latency-t.
Szeretnék a két gép között SQL kapcsolatottal üzemeltetni vmit (egy weboldal egyébkétn).
A probléma, hogy lassú, de irgalmatlanul, pl. select * egy táblára helyben 0.2 sec távolra pedig 1.2 - 2 sec. Miért, hogy lehetne ezen tuningolni? Az általam olvasott fórumok és szakirodalom szerint messze nem szabadna, hogy ennyit számítson. De lehet, hogy rosszat olvastam.
Update:
Most épp "viszonylag' gyors, azaz kb. 2x olyan gyors volt, mint amit nap közben mértem. Nem tudom, minek tudható be, egyelőre annak tulajdonítom, hogy este van. Holnap napközben megnézem újra. Ha valóban ez befolyásolja ennyire, akkor nyílván nem lesz élhető így a szolgáltatás. Bár az az igazság, hogy ez még mindig harmatos így összességében, ha ilyen is maradna örökre.
update:
Időszűke miatt ebbol valószínűleg jelenleg nem lesz semmi, más vonalon megyünk megoldás irányába.
Hozzászólások
Mit jelent pontosan, hogy SQL kapcsolatot üzemeltetsz, mi csatlakozik hova, és milyen módon megy? A csatlakozás direkt, nincs valami trükk?
A teszt erejéig direkt.
GCP-ben van a kliens.
Konkrétan mit jelent nálad az alacsony latency? A helyi és a távoli kapcsolat latency-je közt nincs véletlen egy tízes szorzó? Már egy Budapest-Debrecen kapcsolaton is durván látszik, nálad meg nagyobbról beszélünk
A ping 20 ms.
Az en megertesem szerint a latency-nek nem kene, h ekkora jelentosege legyen, mivel ha egyszer felepul a kapcsolat es elkezd joni az adat, akkor onnantol jon ugyanugy, fuggetlenul attol, hogy lokalisan v. 100000 km-re van.
Maskepp megfogalmazva ha lokalisan 0.1 egyseg alatt epul fel a kapcsolat (tortenik minden mas az data transferen kivul) es 100 egyseg alatt tortenik meg a raw data transfer akkor a teljes ido 100.1 egysegnyi ido.
Ha remote 1 egyseg alatt epul fel a kapcsolat es 100 egyseg alatt tortenik a raw data transzfer, akkor 101 egysegnyi ido kene legyen.
Itt meg mondjuk 500 egysegnyi lesz az ido. A latency-t elfogadnam, hogy 0.035s-rol 0.2s lett (valojaban sokallom) a select now().
Az nem tetszik, hogy a 'select *' egy 3082 soros picinyke tablan 1.5s lett.
Ez az okfejtésed csak akkor igaz, ha perzisztens az SQL kapcsolat. Ha nem (pl: egy weboldal 100 SQL query-t futtat le és mindegyiknél felépít-lekér-lebont folyamat fut le), akkor már egy pár msec növekedés is azonnal észrevehető lesz alkalmazás oldalon.
Egy psql client connection-ről beszélünk.
Beiírom, hogy psql (él a connection).
Majd lefuttatom a select-et és annyi.
"Az en megertesem szerint a latency-nek nem kene, h ekkora jelentosege legyen, mivel ha egyszer felepul a kapcsolat es elkezd joni az adat, akkor onnantol jon ugyanugy, fuggetlenul attol, hogy lokalisan v. 100000 km-re van."
Az a kérdés, hogy mi a domináns: sok kicsi kérés van vagy kevés, de nagy adatmennyiséget válaszoló kérdés. Nem mondom, hogy a sebesség közömbös - de az út hossz sem mindegy.
Hogy vonatos példával éljek (az autós helyett), van a TVG 250km/h tempóval meg a MÁV, legyen 70km/h mert mondjuk IC. Budapest-Győr viszonylatban vitán felül állóan nem a MÁV a befutó. De ha TVG-t használsz mindkét vonalon, viszont az egyik esetben Budapest-Győr a táv, a másik esetben Budapest-Párizs, akkor megint egyértelmű, hogy melyik út futható le hamarabb. Te elkezdhetsz azzal játszani, hogy hosszabb szerelvényeket indítasz, mondhatsz olyat is, hogy egymás után többet is indítasz - de ha van függőséged, azaz nem indíthatod a következő szerelvényt addig, amíg az előző vissza nem érkezett (DB szinten: kérdésre a válasz), akkor innen kezdve hiába dönget 250km/h a szerelvényed, a Győrben megforduló már akkor visszaér Pestre, amikor a Párizsba döngető még félúton sincs. Azt persze megteheted, hogy több szerelvényt indítasz (párhuzamosan több select), de ettől nem fog előbb visszaérni az elsőként induló szerelvényed.
http://www.vonatka.hu/tvg.htm
vs
https://en.wikipedia.org/wiki/TGV
Megelőztél :-D
Köszi, valóban felcseréltem 2 betűt.
1 db select van.
Adatbázis szervert és web/alkalmazás szervert különböző data centerben futtatni nem jó ötlet, és pont ilyen jelenségekhez vezet. A sávszél tipikusan kevésbé probléma, a késleltetés annál inkább. Pl. ha a késleletés a round tripek száma miatt tízszereződik, akkor az data centeren belül 1 msec-nél kisebb késleltetést feltételezve még csak 10 msec, észre sem vehető. Másik országban lévő data centerek közt, ahol a latency mondjuk 100msec, ott máris 1 másodpercet kell várni összesen.
Kérdés, hogy a mérésbe beleszámolod-e a kapcsolat felépítést, vagy mondjuk a connection pooling működik, és tényleg csak a select query lefutását méred a teszt esetedben. És ugyanez a kérdés felmerül, hogy a webalkalmazás hogyan csinálja ugyanezt.
Van connection pooling, De egyelore engem egy sima psql-en beluli select erdekelne.
Az elso mondatodat nem ertem. Azt irod, hogy ...kesleltetes ha 1msec kesletetlest feltetelezve 10 msec...ennek szamomra nincs ertelme. Mire gondolsz pontosan?
Pont arra gondolok, amit leírtam :) Ha mondjuk méred a connection felépítést is, meg a query végrehajtást, simán lehet 10 roundtrip, mire lesz adatod. És minden egyes roundtrip megfelel a késleltetésnek.
Így képzeld el, egy hipotetikus példa, connection pool nélkül:
Kliens fel akarja építeni a kapcsolatot, TCP kapcsolatot nyit, ez már alapból 2 round trip.
Kliens elküldi a user nevet.
Szerver válaszol hogy oké. 3. round trip
Kliens elküldi a jelszót.
Szerver válaszol hogy oké. 4. round trip
Kliens elküldi x. connection paramétert.
Szerver válaszol hogy oké. 5. round trip.
...
Kliens elküldi a query-t.
Szerver elkezdi küldeni az adatokat. 10. round trip.
Ha a latency csak 1 msec, akkor ez összesen 10 msec plusz latency lesz, és igazából észre sem veszed. Ha a latency 100 msec, akkor kijön az össz 1 másodperces latency, és egyből észreveszed.
Valaki írta a wireshark-ot egy másik commentben, ha azzal megnézed ezt, összevetve a csomagok beérkezésének időbélyegével, akkor nagyon jól meg lehet ezeket figyelni.
Én most ezt mérem, ezzel van a problámám:
"Kliens elküldi a query-t."
ps.: A többit is mértem, nincs igazán jelentősége ebben a pillanatban számomra.
Node mi nem világos? A sok roundtrip simán ennyit emel, ha egy gugli - bp valamit nézel. Egy sok kis file-os feltöltés pontosan ezért "lassú", nem a sávszél miatt.
A guglinak hiába van bix node csatlakozása, könnyen lehet, hogy az optika túlvége mondjuk frankfurt vagy amsterdam, és nekik az íreknél van dc-jük biztosan. Az ab ovo 40-50ms körüli távolság, ha onnan működsz. Rossz esetben egy usa nyugati parti dc az 150-200ms között lehet.
Megirtam, h 20s es noncs sok roundtrip, egy query van és ott is csak az a csatlakozas, auth stb. nem
"táblára helyben 0.2 sec távolra pedig 1.2 - 2 sec."
Pontosan honnan tudod, hogy nincs sok roundtrip, vagy bármi ami banális módon lassít? A valódi hálózati forgalom nem az lesz, hogy csatlakozás-auth-query, hanem már a postgres is protokol egyeztet, meg válaszol, akkor a kliens küld valamit, ha mindez SSL-en van, akkor pláne lesz valami SSL handshake. Azért maga a query futásideje valszin ugyanannyi innen is, meg onnan is, pusztán a körítés között lehet különbség. Például a névfeloldás a szerver oldalon, vajon kell-e a postgresnek, és ha van, akkor mennyire gyors? Olyan történetet már nem egyszer volt, hogy maga a reverz zóna válaszolt lassan, vagy egy névszervere már nem ment.
Ha ilyen .hu .us távú protokol alapú beszélgetésről van szó, akkor pláne számít, hogy 70-80ms körül van a keleti part, és 150ms körül a nyugati.
Érdemi debug (tcpdump és naplózás) nélkül nem fog kiderülni mi történik és miért, mindenki csak tippmixel az alapján, amit eddig már tapasztalt.
Onnan. h beirtam. h psql, majd onnantól mértem az időt.
Én továbbra is javasolnám, hogy futtass tcpdump-ot. Nyilván nem 100% csodaszer, de segíthet. Már legalább hárman ezt javasoltuk.
Kicsit olyan, mintha ez ismétlődne: "Doktor úr, fáj a jobb kezem", "Oké, menjen el erre meg arra a műszeres vizsgálatra", "Nem megyek, csak gyógyítsa meg a jobb kezem."
Nekem egyelőre inkább úgy tűnik, h a "doktor úr" paracetamolt ír fel mindenre is.
Hát oké, nyilván azt csinálsz, amit akarsz, csak akkor minek kérdezel egy fórumban?
Tehát beírod, hogy:
psql -c "select..." satöbbi -h ???? dbname
Nulladik kérdés: a -h paraméterében IP-cím vagy név szerepel? Ha név, akkor annak a feloldása meddig tart?
Következő kérdés: a psql ... satöbbi -h ???? dbname _után_ a psql prompt mennyi idő múlva jelenik meg?
Továbbá: A promptnál beírva az első kérdésnél adott select-et az mennyi idő alatt fut le?
Nem.
Beirom, h psql -h lofaszjoska
Majd utana merek. Miert ilyen nehez itt gyakorlatilag mindenkinek felfognia (elfogadnia), hogy nem a kapcsolat letrejottet mertem?
Mert explicit nem írtad le a mérés lényeges paraméterét, hogy ti. a psql promtban kiadott selet futási idejét mérted (Vagy merted mérni? Csak akkor vagy bátor, ha ott a prompt?)
Ez biztos?
Ebben a threadben ha visszamegyek:
https://hup.hu/comment/3082042#comment-3082042
https://hup.hu/comment/3084143#comment-3084143
Egy vesszo valoban hianyzik:)
Ezen kivul ugy emlekszem, meg parszor leirtam.
Fájós izület esetén elküldenek képalkotó diagnosztikára, illetve bizonyos esetekben (kor, anamnézis) akár vérvételre(!) is. Lehet, hogy neked csak a kézfájást kellene meggyógyítani, de ahhoz, hogy tudja a doki, hogy valóban mi a baj, kellenek olyan vizsgálatok, amiket esetleg te - kellő orvosi, élettani tudás hiányában - fölöslegesnek tartanál.
Tegyuk fel, h magam is orvos vagyok es egy konziliumot kertem, hatha vkinek van egy epkezlab otlete, mert mondjuk handson konkret tapasztalata van pontosan ugyanazzal a szituval:)
Es az feher kopenyesek fele azon eroskodik, h a paciens kurva biztos, h tordeli a kezet. A masik fele meg gerinccsapolast akar csinalni (Dr. House).
A feltételezésed ott bukott meg, hogy a kérdést olyan általánosan tetted fel, mint egy random "fáj a kezem" páciens... És igen, ha futási időt akarunk elemezni egy hálózati forgalommal járó kapcsolatnál, pláne ha csak annyit tudunk róla, hogy "lassú a select *...", akkor szépen elindulunk "fölfelé", és megnézzük, hogy hálózati szinten mik történnek ott, ahol rálátunk a dolgokra. Most, hogy kiderült, hogy psql szinten összeállt session-ben lassú a select-ed, a DB-ről kéne infó, hogy hány sor, mennyi adat van az ominózus táblában, milyen logolás van beállítva, stb.
https://hup.hu/comment/3082253#comment-3082253
Továbbra is igen gyanús, hogy ami helyben 0,2sec az távolról 1-1,2sec. Valami extrának ott történnie kell, és igen jó eséllyel a hálózaton történik. További opció, hogy eleve a szerveren terheltségtől függően változik a válaszidő.
A szerver tutira nem volt terhelt, mert olyan a környezet.
Ennek ellenére más értéket mértem legalább 1x napközben és este, írtam vmelyik másik threadben. Ez elég fura, mert amúgy szabad hálózati kapacitás tuti volt.
Ahogy másikban írtam, most teljesen másik irányt vett a projekt, így erről leálltam, de később szándékomban áll visszatérni ehhez és megnézni mélyebben és több szempontból is, pl. AWS-ből és új mérésekkel
Vhol tuti van vmi, ami úgy tűnik, senkinek nem triviális annyira, h kapásból rá mondja a megoldást.... akár csak annyit, h ez nem fog menni, mert ez a normális ezért és azért, vagy épp csak annyit, h neki ilyen-olyan hasonló paraméterekkel működik remekül.
Node miért tudná bárki és a random N+1. problémára a megoldást kapcsira? Azt viszont többen elmondtuk, hogy miből fogod megtudni mi történik.
Hogy még bekavarjak, még QoS is lehet ám a klódszolgáltatótól kimenőleg, meg csupa olyan hálózati csűrés csavarás lehet (lehet, hiszen majd a tcpdump/wireshark mondja el a valóságot, addig ködszurkálás van), ami nem abból következik, hogy óhát még 50Gbit optika szabadon van.
Éppen egy másik topikban írtam, hogy állandóan azonnali megoldást kérnek ittott, sőt néha már követelnek, közben meg csak végig kell menni a debugon, mert konkrétum nélkül mi lesz? Hát ködszurkálás. Ja tudom debugra nincs idő, és ahogy írtad máris más irányt vett a projekt.
Miért ne lehetne olyan, h tudja vki? Nem tilos.
Nem gondolom, h követeltem volna megoldást. Nekem ez itt és jelenleg ennyit ért meg. Szerintem meg az a fura, h ezt a jogot meg akarják vonni többen is.
Leírtam már másik threadben, h én kicsi esélyét látom ebben a szituban, h a csomagok elemzésével meglesz a megoldás rövid időn belül. Így hagytam ezt a vonalat és alternatív megoldást kerestem.
Arra számítottal, hogy lesz egy olyan konfig érték, hogy postgres_disable_slowness_for_tompos? És ezt majd valaki megírja, hogy ja csak ennyi, hogy ezt állítsd át true-ra? Azt írtad, hogy te is láttál már egykét dolgot, azért sejthető, hogy ezek a problémák ennél bonyolultabbak, megoldásuk vélhetően több lépésből áll. Főleg kívülállók számára, akik nálad sokkal kevesebbet látnak az egész szituból, miközben amúgy pont hogy segíteni akarnak.
Node szerinted mekkora szerencse kell ahhoz, hogy pont ezzel találkozott itt valaki? Nem azzal, hogy a remote psql konzol lassú, hanem hogy pont úgy lassú, ahogy, és amiért nálad. Egy kérdést megért persze, de miután kórusban mondjuk hogy tcpdump-wireshark, akkor azt kéne megnézni. Előfordulhat, hogy valóban nem derül ki belőle sok, de akkor legalább kiderült, hogy a hálózati rész patika... szóval még akkoris kiderül valami, ha igazából nem. Más ajánlott pgsql logot, meg doksit. Ez sajnos ilyen, és nem biztos, hogy azonnal a workaround felé jó indulni, mert később ez még visszaüthet.
Nekem például egy ügyviteli jellegű cucc napi használatban van, OpenVPN-et át postgres-t kérdezget, igaz itt nekem FTTB van, és dc-ben a szerver, de mivel normálisan megy, fel sem merült, hogy nézegessem jobban. Lehet még a postgres is kb. default beállításokkal megy... viszont kicsi az adatbázis. Annyira nincs ez így előttem protokol szinten, hogy csak most ugrott be....
"kicsi esélyét látom ebben a szituban, h a csomagok elemzésével meglesz a megoldás rövid időn belül"
Háttőőő... szóval nekem, mint hozzánemértőnek az a feltételezésem, hogy a select értéke nem byte-onként megy át, hanem bekerül egy bufferbe, és onnan tuszkolja ki.
Na, hogy ez a buffer hol van és mekkora, az számomra nem világos (ami találtam, az eléggé lehangoló: 4k - vagy 8? -, mert csak, és az jó mindenkinek, mert csak), de a tcpdumpból hátha látszik, hogy egybe küldi-e, mint a cat, vagy beszélget ide-oda. Nekem annyit nem ér, hogy kipróbáljam, de nem tűnik esélytelennek.
Ami egyszerűen kipróbálható: egy olyan select, aminek az eredménye belefér a bufferbe (remélhetőleg ez legalább két sor), összehasonlítva egy olyannal, ami 10x akkora. Ha az első ~RTT alatt megvan, és a második meg nem ~10x annyi, hanem jelentősen több, akkor bizony ez sokat csacsog.
Az első döntés valóban az, hogy meg akarod-e érteni hogy mi történik?
Ha nem akarod megérteni akkor mindegy is...
Ha netán mégis meg akarod érteni akkor van (legalább) két módszer:
- méred a konkrét rendszert, ahogy van
- megpróbálsz kicserélni (ideálisan) egyszerre egy komponenst és nézed hogy mit okoz a változás
Önmagában egy tcpdumpos-wiresharkos mérést összedobni a megfelelő jogosultságok birtokában fél-egyórás műveletnek mondanám.
Ebből kiderülne, hogy:
- mennyit tököl a rendszer a DNS-sel (negative hit?)
- mennyit tököl az authorizációval (tls)
- mennyit tököl az első packet elküldéséig
- hány packetet küld el
Nincsen nagy történet, egy tcp streamet kell követni kb.
Az alternatív megoldás mondjuk a saját gépedre (dockerbe) felhúzni egy postgrest és mint kliens "meglőni" a szervert.
Én mindenképpen javaslom a probléma okának felderítését, nagyon valószínű hogy ugyanebbe/hasonlóba bármikor máskor bele fogsz futni, nem kidobott idő.
Egy teljesen más infrastruktúrát / architektúrát felállítani nagyjából a nulláról újrakezdés. Aminek aztán vagy van értelme vagy nincs, érzésre a rizikója nem kisebb.
Gábriel Ákos
A távoli postgres serverre nem lehet véletlenül belépni ssh-n mondjuk?
Akkor azon a gépen helyben futtatható lenne a lekérdezés és nem menne át hálózaton. Ha nagy a kimenet, az ugyan átmenne a hálózaton - de ezen egy > /dev/null segíthet.
Ha ezt így lezongorázod, máris van info arról, hogy a távoli gépen mennyi ideig fut a lekérdezés és a hálózati átvittel tuti ki van küszöbölve.
Utána jöhet az összehasonlítás, hogy ha ugyanaz a kérdés távolról, hálózaton át kapja meg az SQL szerver, akkor mi történik.
Pontosan. TCP kapcsolat már technikailag is mindig vár választ, és akkor ez még csak L3, a fölötte lévő rétegek "üzleti" flow-ja pláne többlépcsős, mint ahogy a felettem szóló kifejti. A "kapcsolat után csak hányja az adatot" típusú működés UDP lenne, de DB kapcsolat gondolom nem örülne ha fogalma sem lenne hogy minden csomag átért e, így marad a kérdezz felelek játék.
Ezek az sql serverek logolhatnak is kapcsolatokat, ahhoz reverse nslookup-ot hasznalhatnak, igy a kapcsolodasok lassuak.
Javaslom hogy a pg szempontbol kliens gepre (webserver oldal) rakj fel egy pg client-et, ezzel a nativ parancsok sebesseget tudod merni, kiprobalni.
Azzal merem.
Milyen PG beállítások vannak szerver és kliens oldalon? Próbáltál-e rajtuk állítani az alapértelmezetthez képest?
Hányas PG verzióról beszélünk?
Wiresharkkal, tcpdumppal nézted már a hálózati forgalmat?
Nem néztem tcpdump-pal, mert nem igazán tudom, mit keressek.
PSQL 14 a server. Default beállítások (ha állítottam is vmit, nem hozott változást). A klienst psql 12-vel és 16-tal néztem. A 16 kicsit jobb volt, de nem nagyságrendbeli volt a különbség.
Szerveren a logokban mi látszódik?
Tcpdumppal csinálj egy dumpot - vedd bele a DNS forgalmat is mindkét oldalon. Abból látszódnia kell, hogy hol és mire vár hálózatilag, ha ott van a hiba - pl: tcp retransmission, elveszett csomag, túlméretes csomag, DNS probléma stb.
Szerveren a logokban semmi.
tcpdump-ot nem csináltam még.
Nem támadásnak szánom: Az ugye megvan, hogy default beállítások mellett a PG szinte semmit se logol?
Tehát remélem, hogy úgy néztél szerver logokat, hogy a PG logolási beállításai be voltak kapcsolva rendesen. Ha nem világos, hogy melyik beállításokra gondolok, akkor írd meg és akkor holnap leírom a paramétereket, amikre gondolok.
megvan
Igazából nem latom, milyen uzenetre vadászol?
Pl: kliens vár a szerverre, szerver vár a kliensre, DNS feloldást végez a szerver sikertelenül, SSL kapcsolatnál valamit (pl: CRL) nem tud ellenőrizni a kliens/szerver stb.
Meg tudod esetleg osztani a mostani PG szerver és kliens beállításokat? Hátha így gyorsabban tudunk segíteni. Mert most csak sötétben tapogatózunk szerintem.
Egy élő psql kapcsolaton belül szerintem már nincsenek ezek a lépések.
Mi van meg? Állítottál be mondjuk `log_min_duration_statement`-et? Ha igen, mit látsz a logokban (élőben), miközben a „lassú” kérést küldöd? Ebből például kiderülhet, hogy a logba bekerül a selected (ha jól emlékszem még azt is írja, hogy mennyi ideig babrált vele), és közben a lokális psql-ed csak másodpercek múlva kapja meg az eredményt. Mert akkor tényleg a válasz utazott ilyen sokáig.
+1.
Továbbá:
log_checkpoints: on
log_connections: on
log_disconnections: on
log_duration: on
log_hostname: off (az on teljesítmény csökkenést okozhat)
log_lock_waits: on
log_line_prefix (ahogy neked tetszik)
log_statement: all
log_replication_commands: on
log_temp_files: (ahogy neked tetszik, debug idejére vedd alacsonyra)
pg_stat_statements.track: all
track_activities: on
track_counts: on
track_io_timing: on
track_activity_query_size (ahogy neked tetszik)
track_wal_io_timing: on
wal_log_hints: 'on'
Nem volt idom ezzel azota foglalkozni es egy ideig nem is lesz. Mindenkepp vissza akarok majd terni ehhez, mert nem hagy nyugodni, h wtf.
És mi lenne, ha csinálnál végre? Többen is írtuk. Elég sok dolgot ki tud zárni vagy meg tud erősíteni.
Default beállításokkal nem használunk PostgreSQL szervert.
Össze kellene hasonlítani a SQL szerverek beállításait, a szerverek fizikai paramétereit,
helyileg futtatni mind a két helyen egy query-t explain-nel, stb. és nem a hálózatot kellene első körben boncolgatni.
select *, ezen sokat optimalizálni nem lehet, egy nyers teszt.
Nem lehet, hogy túl sok adat közlekedik? Az nagyon kijön ilyenkor.
Azt kimertem es az az adatmennyiseg gyakorlatilag prompt atment.
authorizacio ideje? dns?
Gábriel Ákos
En a TCP_NODELAY hiányára gyanakszom, de tényleg kellene egy-egy network dump mindkét végponton, hogy kiderüljön az igazság.
Majd írd meg mi volt a hiba oka és mi lett a megoldás. Köszi.
Ha lesz. megírom.
Még azt se írtad le hogy az adatbázis van a gcp-ben vagy a webserver...
Gábriel Ákos
https://hup.hu/comment/3081148#comment-3081148
Lehet jobban jönnél ki azzal ha a GCP's SQL lenne a replica és/vagy failover.
Bónuszként readonly lekérdezésekkel inkább azt fárasztanád mint azt az adatbázist amelyik a weboldalt direktben kiszolgálja.
Mielőtt összelövöd ezt, azért csinálj egy threat modelt hogy mire is kell majd figyelni és mi mehet rosszul.
Mondjuk ilyen adatbázis dolgokhoz azért kell majd TLS meg ilyesmi és ott annyi de annyi dolog csúszhat félre, kezdjük azzal hogy a certet kell managelni, engine upgrade, vagy épp ha a távoli gép valami miatt megborul - felhőszolgáltató hypervisorja ledöglik és a GCP gép vele zuhan, esetleg egész GCP AZ megborul.
A klasszikus: <xy> system detected instance in degraded mode, <provider_name> will terminate the instance on <date_here> .
Ha adatbázis akkor használd a szolgáltató által javasolt adatbázis megoldásokat, ahol van reliability, snapshot, replica, stb, ellenkező esetben semmi fontosat/pótolhatatlant ne rakj rá lehetőleg.