{"id":30356,"date":"2019-10-31T21:35:06","date_gmt":"2019-10-31T18:35:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql\/"},"modified":"2019-10-31T21:35:06","modified_gmt":"2019-10-31T18:35:06","slug":"kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Hogyan haszn\u00e1ltuk a k\u00e9sleltetett replik\u00e1ci\u00f3t v\u00e9szhelyzeti helyre\u00e1ll\u00edt\u00e1shoz PostgreSQL-lel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hogyan
\nA replik\u00e1ci\u00f3 nem biztons\u00e1gi ment\u00e9s. Vagy m\u00e9gis? \u00cdme, hogyan haszn\u00e1ltuk a k\u00e9sleltetett replik\u00e1ci\u00f3t a v\u00e9letlen\u00fcl t\u00f6r\u00f6lt linkek helyre\u00e1ll\u00edt\u00e1s\u00e1hoz.<\/p>\n

<\/p>\n

Infrastrukt\u00fara szak\u00e9rt\u0151k<\/a><\/noindex> a GitLabn\u00e1l felelnek a m\u0171k\u00f6d\u00e9s\u00e9rt GitLab.com<\/a><\/noindex> \u2014 a legnagyobb GitLab p\u00e9ld\u00e1ny a vil\u00e1gon. Itt 3 milli\u00f3 felhaszn\u00e1l\u00f3 \u00e9s k\u00f6zel 7 milli\u00f3 projekt tal\u00e1lhat\u00f3, \u00e9s ez az egyik legnagyobb ny\u00edlt forr\u00e1sk\u00f3d\u00fa SaaS weboldal dedik\u00e1lt architekt\u00far\u00e1val. PostgreSQL adatb\u00e1zis rendszer n\u00e9lk\u00fcl a GitLab.com infrastrukt\u00far\u00e1ja nem menne messze, \u00e9s mindent megtesz\u00fcnk az adatveszt\u00e9s eseten t\u00f6rt\u00e9n\u0151 hibamentess\u00e9g \u00e9rdek\u00e9ben. Val\u00f3sz\u00edn\u0171tlen, hogy ilyen katasztr\u00f3fa bek\u00f6vetkezik, de alaposan felk\u00e9sz\u00fclt\u00fcnk \u00e9s k\u00fcl\u00f6nb\u00f6z\u0151 biztons\u00e1gi ment\u00e9si \u00e9s replik\u00e1ci\u00f3s mechanizmusokkal k\u00e9sz\u00fclt\u00fcnk.<\/p>\n

<\/p>\n

A replik\u00e1ci\u00f3 nem adatb\u00e1zis biztons\u00e1gi ment\u00e9s(l\u00e1sd al\u00e1bb<\/a><\/noindex>). De most megn\u00e9zz\u00fck, hogyan lehet gyorsan helyre\u00e1ll\u00edtani a v\u00e9letlen\u00fcl t\u00f6r\u00f6lt adatokat k\u00e9sleltetett replik\u00e1ci\u00f3val: amikor GitLab.com<\/a><\/noindex> a felhaszn\u00e1l\u00f3 t\u00f6r\u00f6lte a linket<\/a><\/noindex> a projekt sz\u00e1m\u00e1ra gitlab-ce<\/code><\/a><\/noindex> \u00e9s elvesztette a kapcsolatot az \u00f6sszeolvaszt\u00e1si k\u00e9r\u00e9sekkel \u00e9s feladatokkal.<\/p>\n

<\/p>\n

K\u00e9sleltetett replik\u00e1ci\u00f3val mind\u00f6ssze 1,5 \u00f3ra alatt helyre\u00e1ll\u00edtottuk az adatokat. N\u00e9zd meg, hogyan t\u00f6rt\u00e9nt.<\/p>\n

<\/a><\/noindex><\/p>\n

Id\u0151pont szerinti helyre\u00e1ll\u00edt\u00e1s PostgreSQL-lel<\/h3>\n

<\/p>\n

A PostgreSQL rendelkezik egy be\u00e9p\u00edtett funkci\u00f3val, amely lehet\u0151v\u00e9 teszi az adatb\u00e1zis \u00e1llapot\u00e1nak helyre\u00e1ll\u00edt\u00e1s\u00e1t egy adott id\u0151pontban. Ezt nevezik Point-in-Time Recovery<\/a><\/noindex> (PITR) \u00e9s ugyanazokat a mechanizmusokat haszn\u00e1lja, amelyek t\u00e1mogatj\u00e1k a replik\u00e1k aktualit\u00e1s\u00e1t: egy megb\u00edzhat\u00f3 pillanatfelv\u00e9telt\u0151l kezdve az eg\u00e9sz adatb\u00e1zis klaszterr\u0151l (alap biztons\u00e1gi ment\u00e9s) egy sor v\u00e1ltoztat\u00e1st alkalmazunk egy adott id\u0151pontig.<\/p>\n

<\/p>\n

E funkci\u00f3 haszn\u00e1lat\u00e1hoz hideg biztons\u00e1gi ment\u00e9shez rendszeresen k\u00e9sz\u00edt\u00fcnk alap biztons\u00e1gi ment\u00e9st az adatb\u00e1zisr\u00f3l, \u00e9s archiv\u00e1ljuk azt (a GitLab arch\u00edvumok a Google felh\u0151t\u00e1rol\u00f3j\u00e1ban<\/a><\/noindex>). Ezen k\u00edv\u00fcl nyomon k\u00f6vetj\u00fck az adatb\u00e1zis \u00e1llapot\u00e1nak v\u00e1ltoz\u00e1sait, archiv\u00e1lva az el\u0151re \u00edr\u00e1si napl\u00f3t (write-ahead log<\/a><\/noindex>, WAL). Ezzel pedig elv\u00e9gezhetj\u00fck a PITR-t a v\u00e9szhelyzeti helyre\u00e1ll\u00edt\u00e1shoz: kezdj\u00fck a hiba el\u0151tti pillanatfelv\u00e9tellel, \u00e9s alkalmazzuk a WAL arch\u00edvumb\u00f3l sz\u00e1rmaz\u00f3 v\u00e1ltoz\u00e1sokat a hib\u00e1ig.<\/p>\n

<\/p>\n

Mi az a k\u00e9sleltetett replik\u00e1ci\u00f3?<\/h3>\n

<\/p>\n

A k\u00e9sleltetett replik\u00e1ci\u00f3 a WAL-b\u00f3l sz\u00e1rmaz\u00f3 v\u00e1ltoztat\u00e1sok k\u00e9sleltetett alkalmaz\u00e1s\u00e1t jelenti. Teh\u00e1t a tranzakci\u00f3 X \u00f3rakor t\u00f6rt\u00e9nt, X<\/code>de a replik\u00e1n k\u00e9sleked\u00e9ssel fog megjelenni, d<\/code> X \u00f3r\u00e1ban X + d<\/code>.<\/p>\n

<\/p>\n

A PostgreSQL-ban k\u00e9t m\u00f3dja van az adatb\u00e1zis fizikai replik\u00e1j\u00e1nak be\u00e1ll\u00edt\u00e1s\u00e1ra: arch\u00edvum helyre\u00e1ll\u00edt\u00e1sa \u00e9s streaming replik\u00e1ci\u00f3. Arch\u00edvum helyre\u00e1ll\u00edt\u00e1sa<\/a><\/noindex>, l\u00e9nyeg\u00e9ben \u00fagy m\u0171k\u00f6dik, mint a PITR, de folyamatosan: folyamatosan kinyerj\u00fck a v\u00e1ltoz\u00e1sokat a WAL arch\u00edvumb\u00f3l \u00e9s alkalmazzuk azokat a replik\u00e1n. A streaming replik\u00e1ci\u00f3<\/a><\/noindex> k\u00f6zvetlen\u00fcl kinyeri a WAL adatfolyamot a magasabb szint\u0171 adatb\u00e1zis gazd\u00e1t\u00f3l. Az arch\u00edvum helyre\u00e1ll\u00edt\u00e1s\u00e1t prefer\u00e1ljuk \u2014 k\u00f6nnyebb kezelni, \u00e9s norm\u00e1lis teljes\u00edtm\u00e9nyt ny\u00fajt, amely nem marad el a m\u0171k\u00f6d\u0151 klasztert\u0151l.<\/p>\n

<\/p>\n

Hogyan \u00e1ll\u00edtsuk be az arch\u00edvum helyre\u00e1ll\u00edt\u00e1s\u00e1t k\u00e9sleltetve<\/h3>\n

<\/p>\n

Helyre\u00e1ll\u00edt\u00e1si be\u00e1ll\u00edt\u00e1sok<\/a><\/noindex> a k\u00f6vetkez\u0151 f\u00e1jlban tal\u00e1lhat\u00f3 recovery.conf<\/code>. P\u00e9lda:<\/p>\n

<\/p>\n

standby_mode = 'on'\nrestore_command = '\\\/usr\\\/bin\\\/envdir \\\/etc\\\/wal-e.d\\\/env \\\/opt\\\/wal-e\\\/bin\\\/wal-e wal-fetch -p 4 \"%f\" \"%p\"'\nrecovery_min_apply_delay = '8h'\nrecovery_target_timeline = 'latest'<\/code><\/pre>\n
<\/p>\n
Ezekkel a be\u00e1ll\u00edt\u00e1sokkal \u00e1ll\u00edtottuk be az arch\u00edvum helyre\u00e1ll\u00edt\u00e1sa r\u00e9v\u00e9n a k\u00e9sleltetett replik\u00e1t. Itt a wal-e<\/a><\/noindex> haszn\u00e1latos a WAL szegmensek kinyer\u00e9s\u00e9hez (restore_command<\/code>) az arch\u00edvumb\u00f3l, \u00e9s a v\u00e1ltoz\u00e1sokat nyolc \u00f3r\u00e1n bel\u00fcl fogj\u00e1k alkalmazni (recovery_min_apply_delay<\/code>). A replik\u00e1nak figyelemmel kell k\u00eds\u00e9rnie a v\u00e1ltoz\u00e1sokat az arch\u00edvum id\u0151vonal\u00e1n, p\u00e9ld\u00e1ul a klaszterben fell\u00e9p\u0151 hiba miatt (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
K\u00e9sleltetett streaming replik\u00e1ci\u00f3t is be\u00e1ll\u00edthatunk, de van n\u00e9h\u00e1ny csapda, amelyek a replik\u00e1ci\u00f3s slotokkal, a forr\u00f3 tartal\u00e9k visszajelz\u00e9s\u00e9vel stb. kapcsolatosak. A WAL arch\u00edvum lehet\u0151v\u00e9 teszi, hogy elker\u00fclj\u00fck ezeket. recovery_min_apply_delay<\/code> csak a PostgreSQL 9.3-ban jelent meg. A kor\u00e1bbi verzi\u00f3kban a k\u00e9sleltetett replik\u00e1ci\u00f3hoz egy kombin\u00e1ci\u00f3t kellett be\u00e1ll\u00edtani<\/p>\n
<\/p>\n
A parameter recovery_min_apply_delay<\/code> helyre\u00e1ll\u00edt\u00e1si vez\u00e9rl\u00e9si funkci\u00f3kb\u00f3l pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/a><\/noindex> () vagy a WAL szegmenseket meg kellett tartani az arch\u00edvumban a k\u00e9sleltet\u00e9s idej\u00e9re.<\/code>Hogyan v\u00e9gzi mindezt a PostgreSQL?<\/p>\n
<\/p>\n
\u00c9rdekes megn\u00e9zni, hogyan val\u00f3s\u00edtja meg a PostgreSQL a k\u00e9sleltetett helyre\u00e1ll\u00edt\u00e1st. N\u00e9zz\u00fck meg a<\/h3>\n
<\/p>\n
recoveryApplyDelay(XlogReaderState) . Ez a f\u0151 ism\u00e9tl\u00e9si ciklusb\u00f3l h\u00edvhat\u00f3 meg<\/code><\/a><\/noindex>minden egyes WAL bejegyz\u00e9shez. minden WAL bejegyz\u00e9shez.<\/a><\/noindex> minden egyes bejegyz\u00e9shez a WAL-b\u00f3l.<\/p>\n
<\/p>\n
static bool\nrecoveryApplyDelay(XLogReaderState *record)\n{\n    uint8       xact_info;\n    TimestampTz xtime;\n    long        secs;\n    int         microsecs;\n\n    \/* semmi teend\u0151, ha nincs be\u00e1ll\u00edtva k\u00e9sleltet\u00e9s *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* a k\u00e9sleltet\u00e9s nem alkalmazhat\u00f3 olyan adatb\u00e1zison, amely m\u00e9g nem konzisztens *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/**\n     * Ez egy COMMIT rekord?\n     *\n     * Kifejezetten \u00fagy d\u00f6nt\u00fcnk, hogy nem k\u00e9sleltetj\u00fck az abortokat, mivel azoknak\n     * nincs hat\u00e1suk az MVCC-ra. M\u00e1r lehet\u0151v\u00e9 tessz\u00fck olyan rekordok visszaj\u00e1tsz\u00e1s\u00e1t,\n     * amelyeknek nincs id\u0151b\u00e9lyeg\u00fck, \u00edgy m\u00e1r van lehet\u0151s\u00e9g a korai \u00fctk\u00f6z\u00e9sek okozta\n     * probl\u00e9m\u00e1kra a standbys szolg\u00e1ltat\u00e1sokon.\n     * \/\n    if (XLogRecGetRmid(record) != RM_XACT_ID)\n        return false;\n\n    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;\n\n    if (xact_info != XLOG_XACT_COMMIT &&\n        xact_info != XLOG_XACT_COMMIT_PREPARED)\n        return false;\n\n    if (!getRecordTimestamp(record, &xtime))\n        return false;\n\n    recoveryDelayUntilTime =\n        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);\n\n    \/**\n     * Kil\u00e9p\u00e9s a r\u00f6gz\u00edtett k\u00e9sleltet\u00e9s aktiv\u00e1l\u00e1sa n\u00e9lk\u00fcl, ha m\u00e1r\n     * eld\u0151lt, mikor kell alkalmazni ezt a rekordot\n     * \/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ R\u00f6vid\u00edtve:\n        \/\/ Haszn\u00e1lj WaitLatch-t, am\u00edg el nem \u00e9rj\u00fck recoveryDelayUntilTime\n        \/\/ \u00e9s azt\u00e1n\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
A l\u00e9nyeg az, hogy a k\u00e9sleltet\u00e9s a tranzakci\u00f3 commit id\u0151b\u00e9lyeg\u00e9ben r\u00f6gz\u00edtettxtime<\/code>). Ahogyan l\u00e1that\u00f3, a k\u00e9sleltet\u00e9s csak a commitokra vonatkozik, \u00e9s nem \u00e9rinti a t\u00f6bbi rekordot \u2014 az \u00f6sszes v\u00e1ltoztat\u00e1s k\u00f6zvetlen\u00fcl alkalmaz\u00e1sra ker\u00fcl, m\u00edg a commit k\u00e9slekedik, \u00edgy a v\u00e1ltoz\u00e1sok csak a be\u00e1ll\u00edtott k\u00e9sleltet\u00e9s ut\u00e1n v\u00e1lnak l\u00e1that\u00f3v\u00e1.<\/p>\n
<\/p>\n
Hogyan haszn\u00e1ljunk k\u00e9sleltetett replik\u00e1t az adatok vissza\u00e1ll\u00edt\u00e1s\u00e1hoz<\/h3>\n
<\/p>\n
Tegy\u00fck fel, hogy van egy produkci\u00f3s adatb\u00e1zis klaszter\u00fcnk \u00e9s egy nyolc \u00f3r\u00e1s k\u00e9sleked\u00e9ssel rendelkez\u0151 replik\u00e1nk. N\u00e9zz\u00fck meg, hogyan \u00e1ll\u00edthatjuk vissza az adatokat egy v\u00e9letlenszer\u0171 hivatkoz\u00e1s t\u00f6rl\u00e9s p\u00e9ld\u00e1j\u00e1n.<\/a><\/noindex>.<\/p>\n
<\/p>\n
Amikor \u00e9rtes\u00fclt\u00fcnk a probl\u00e9m\u00e1r\u00f3l, mi felf\u00fcggesztett\u00fck a vissza\u00e1ll\u00edt\u00e1st az arch\u00edvumb\u00f3l<\/a><\/noindex> a k\u00e9sleltetett replik\u00e1hoz:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
A sz\u00fcnettel nem volt kock\u00e1zatunk, hogy a replik\u00e1t ism\u00e9telje a lek\u00e9rdez\u00e9st DELETE<\/code>. Hasznos dolog, ha id\u0151t kell sz\u00e1nnunk a dolgok \u00e1tgondol\u00e1s\u00e1ra.<\/p>\n
<\/p>\n
A l\u00e9nyeg az, hogy a k\u00e9sleltetett replik\u00e1nak el kell jutnia a lek\u00e9rdez\u00e9s el\u0151tti id\u0151ponthoz. DELETE<\/code>Tudtuk k\u00f6r\u00fclbel\u00fcl a t\u00f6rl\u00e9s id\u0151b\u00e9lyeg\u00e9t. T\u00f6r\u00f6lt\u00fck recovery_min_apply_delay<\/code> \u00e9s hozz\u00e1adtuk recovery_target_time<\/code> be. recovery.conf<\/code>\u00cdgy a replik\u00e1hoz a megfelel\u0151 id\u0151pontra jutunk k\u00e9sleltet\u00e9s n\u00e9lk\u00fcl:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Az id\u0151b\u00e9lyegekkel jobb kevesebbet levonni, hogy ne hib\u00e1zzunk. Igaz, hogy min\u00e9l t\u00f6bbet vonunk le, ann\u00e1l t\u00f6bb adatot vesz\u00edt\u00fcnk. Ism\u00e9t, ha \u00e1tugorjuk a lek\u00e9rdez\u00e9st, DELETE<\/code>minden \u00fajra t\u00f6rl\u0151dik, \u00e9s \u00fajra el kell kezden\u00fcnk (vagy h\u00e1tulr\u00f3l kell venn\u00fcnk hideg biztons\u00e1gi ment\u00e9st a PITR-folyamat\u00e1hoz).<\/p>\n
<\/p>\n
\u00dajraind\u00edtottuk a k\u00e9sleltetett Postgres p\u00e9ld\u00e1nyt, \u00e9s a WAL szegmensek a megadott id\u0151pontig ism\u00e9tl\u0151dtek. Ezen a ponton a halad\u00e1s nyomon k\u00f6vet\u00e9s\u00e9re a k\u00f6vetkez\u0151 lek\u00e9rdez\u00e9st haszn\u00e1lhatjuk:<\/p>\n
<\/p>\n
SELECT\n  -- aktu\u00e1lis hely a WAL-ban\n  pg_last_xlog_replay_location(),\n  -- aktu\u00e1lis tranzakci\u00f3s id\u0151b\u00e9lyeg (a replik\u00e1ci\u00f3 \u00e1llapota)\n  pg_last_xact_replay_timestamp(),\n  -- aktu\u00e1lis fizikai id\u0151\n  now(),\n  -- az az id\u0151tartam, amely m\u00e9g alkalmaz\u00e1sra v\u00e1r, am\u00edg a recovery_target_time el nem \u00e9rkezik\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Ha az id\u0151b\u00e9lyeg t\u00f6bb\u00e9 nem v\u00e1ltozik, a helyre\u00e1ll\u00edt\u00e1s befejez\u0151d\u00f6tt. Be\u00e1ll\u00edthat\u00f3 a m\u0171velet recovery_target_action<\/code><\/a><\/noindex>, hogy a p\u00e9ld\u00e1nyt bez\u00e1rja, el\u0151r\u00e9bb mozgatja vagy sz\u00fcnetelteti a repeat ut\u00e1n (alap\u00e9rtelmez\u00e9s szerint sz\u00fcneteltetik).<\/p>\n
<\/p>\n
Az adatb\u00e1zis visszat\u00e9rt annak a balj\u00f3s lek\u00e9rdez\u00e9snek az \u00e1llapot\u00e1ba. Most p\u00e9ld\u00e1ul ki lehet export\u00e1lni az adatokat. Export\u00e1ltuk a t\u00f6r\u00f6lt c\u00edmk\u00e9kr\u0151l \u00e9s minden feladattal \u00e9s merge-k\u00e9relmekkel kapcsolatos kapcsolatr\u00f3l sz\u00f3l\u00f3 adatokat, \u00e9s \u00e1thelyezt\u00fck \u0151ket a munkaadatb\u00e1zisba. Ha a vesztes\u00e9g m\u00e9rt\u00e9ke nagy, egyszer\u0171en el\u0151r\u00e9bb mozgathatjuk a replik\u00e1t, \u00e9s haszn\u00e1lhatjuk mint f\u0151 adatb\u00e1zist. De akkor minden v\u00e1ltoztat\u00e1s elveszik att\u00f3l a pontt\u00f3l kezdve, amelyig vissza\u00e1lltunk.<\/p>\n
<\/p>\n
Id\u0151b\u00e9lyegek helyett \u00e9rdemes a tranzakci\u00f3s azonos\u00edt\u00f3kat haszn\u00e1lni. Hasznos ezeket az azonos\u00edt\u00f3kat feljegyezni, p\u00e9ld\u00e1ul a DDL oper\u00e1torok eset\u00e9n (mint p\u00e9ld\u00e1ul DROP TABLE<\/code>), a k\u00f6vetkez\u0151vel: log_statements = 'ddl'<\/code>. Ha lett volna tranzakci\u00f3s azonos\u00edt\u00f3nk, megkaptuk volna a recovery_target_xid<\/code> -t, \u00e9s minden tranzakci\u00f3t futtattunk volna a lek\u00e9rdez\u00e9s el\u0151tti \u00e1llapotig. DELETE<\/code>.<\/p>\n
<\/p>\n
Visszat\u00e9rni a munk\u00e1hoz nagyon egyszer\u0171: t\u00e1vol\u00edtsa el az \u00f6sszes m\u00f3dos\u00edt\u00e1st a recovery.conf<\/code> -b\u0151l, \u00e9s ind\u00edtson \u00fajra Postgres-t. Hamarosan a replik\u00e1ban ism\u00e9t megjelenik a nyolc\u00f3r\u00e1s k\u00e9sedelem, \u00e9s k\u00e9szen \u00e1llunk a j\u00f6v\u0151beli kellemetlens\u00e9gekre.<\/p>\n
<\/p>\n
El\u0151ny\u00f6k a helyre\u00e1ll\u00edt\u00e1s szempontj\u00e1b\u00f3l<\/h3>\n
<\/p>\n
K\u00e9sleltetett replik\u00e1val a hideg biztons\u00e1gi m\u00e1solat helyett nem kell \u00f3r\u00e1kig vissza\u00e1ll\u00edtani az eg\u00e9sz pillanatk\u00e9pet az arch\u00edvumb\u00f3l. P\u00e9ld\u00e1ul \u00f6t \u00f3r\u00e1ra van sz\u00fcks\u00e9g\u00fcnk, hogy el\u0151hozzuk az alap biztons\u00e1gi m\u00e1solatot a 2 TB-os m\u00e9retb\u0151l. \u00c9s tov\u00e1bbi id\u0151t kell t\u00f6lteni az eg\u00e9sz napi WAL alkalmaz\u00e1s\u00e1ra, hogy vissza\u00e1lljunk a k\u00edv\u00e1nt \u00e1llapotba (a legrosszabb esetben).<\/p>\n
<\/p>\n
A k\u00e9sleltetett replik\u00e1nak k\u00e9t szempontb\u00f3l jobb, mint a hideg biztons\u00e1gi m\u00e1solat:<\/p>\n
<\/p>\n
    \n
  1. Nem kell az eg\u00e9sz alap biztons\u00e1gi m\u00e1solatot el\u0151hoznunk az arch\u00edvumb\u00f3l.<\/li>\n
  2. Van egy r\u00f6gz\u00edtett nyolc\u00f3r\u00e1s ablak a WAL szegmensek ism\u00e9tl\u00e9s\u00e9re.<\/li>\n<\/ol>\n
    <\/p>\n
    Emellett folyamatosan ellen\u0151rizz\u00fck, hogy a WAL-b\u00f3l lehet-e PITR-t v\u00e9gezni, \u00e9s gyorsan \u00e9szleln\u00e9nk a WAL arch\u00edvum s\u00e9r\u00fcl\u00e9seit vagy egy\u00e9b probl\u00e9m\u00e1it, figyelve a k\u00e9sleltetett replik\u00e1ra.<\/p>\n
    <\/p>\n
    Ebben a p\u00e9ld\u00e1ban 50 percet vett ig\u00e9nybe a helyre\u00e1ll\u00edt\u00e1s, \u00edgy a sebess\u00e9g 110 GB WAL adatot jelentett \u00f3r\u00e1nk\u00e9nt (az arch\u00edvum akkor m\u00e9g mindig AWS S3<\/a><\/noindex>). \u00d6sszess\u00e9g\u00e9ben 1,5 \u00f3ra alatt megoldottuk a probl\u00e9m\u00e1t \u00e9s helyre\u00e1ll\u00edtottuk az adatokat.<\/p>\n
    <\/p>\n
    \u00d6sszegz\u00e9s: hol hasznos az elhalasztott replik\u00e1ci\u00f3 (\u00e9s hol nem)<\/h3>\n
    <\/p>\n
    Haszn\u00e1lja az elhalasztott replik\u00e1ci\u00f3t els\u0151seg\u00e9lyk\u00e9nt, ha v\u00e9letlen\u00fcl elvesztette az adatokat, \u00e9s \u00e9szrevette ezt a probl\u00e9m\u00e1t a be\u00e1ll\u00edtott k\u00e9sleltet\u00e9sen bel\u00fcl.<\/p>\n
    <\/p>\n
    De vegye figyelembe: a replik\u00e1ci\u00f3 nem biztons\u00e1gi ment\u00e9s.<\/p><\/blockquote>\n
    A biztons\u00e1gi ment\u00e9s \u00e9s a replik\u00e1ci\u00f3 k\u00fcl\u00f6nb\u00f6z\u0151 c\u00e9lokat szolg\u00e1l. A hideg biztons\u00e1gi ment\u00e9s hasznos, ha v\u00e9letlen\u00fcl l\u00e9trehozott DELETE<\/code> vagy DROP TABLE<\/code>. A hideg t\u00e1rol\u00f3b\u00f3l biztons\u00e1gi ment\u00e9st k\u00e9sz\u00edt\u00fcnk, \u00e9s vissza\u00e1ll\u00edtjuk a t\u00e1bl\u00e1zat vagy az eg\u00e9sz adatb\u00e1zis el\u0151z\u0151 \u00e1llapot\u00e1t. De ek\u00f6zben a k\u00e9r\u00e9s DROP TABLE<\/code> majdnem azonnal reproduk\u00e1l\u00f3dik minden replik\u00e1n a m\u0171k\u00f6d\u0151 klaszterben, ez\u00e9rt a szok\u00e1sos replik\u00e1ci\u00f3 itt nem seg\u00edt. Mag\u00e1ban a replik\u00e1ci\u00f3 fenntartja az adatb\u00e1zis el\u00e9rhet\u0151s\u00e9g\u00e9t, amikor egyes szerverek le\u00e1llnak, \u00e9s elosztja a terhel\u00e9st.<\/p>\n
    <\/p>\n
    M\u00e9g az elhalasztott replik\u00e1ci\u00f3val is n\u00e9ha nagyon sz\u00fcks\u00e9g\u00fcnk van a hideg biztons\u00e1gi ment\u00e9sre egy biztons\u00e1gos helyen, ha v\u00e1ratlanul adatk\u00f6zponti hiba, rejtett s\u00e9r\u00fcl\u00e9s vagy m\u00e1s olyan esem\u00e9ny t\u00f6rt\u00e9nik, amit azonnal nem \u00e9szlel. Itt az egyetlen replik\u00e1ci\u00f3 nem elegend\u0151.<\/p>\n
    <\/p>\n
    Megjegyz\u00e9s<\/strong>. A GitLab.com<\/a><\/noindex> jelenleg csak a rendszer szintj\u00e9n v\u00e9dj\u00fck az adatveszt\u00e9st, \u00e9s nem \u00e1ll\u00edtjuk vissza az adatokat a felhaszn\u00e1l\u00f3i szinten.<\/p>\n
    Forr\u00e1s: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u0420\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044f \u2014 \u043d\u0435 \u0431\u044d\u043a\u0430\u043f. \u0418\u043b\u0438 \u043d\u0435\u0442? \u0412\u043e\u0442 \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f, \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u043e \u0443\u0434\u0430\u043b\u0438\u0432 \u044f\u0440\u043b\u044b\u043a\u0438. \u0421\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u043f\u043e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0435 \u043d\u0430 GitLab \u043e\u0442\u0432\u0435\u0447\u0430\u044e\u0442 \u0437\u0430 \u0440\u0430\u0431\u043e\u0442\u0443 GitLab.com \u2014 \u0441\u0430\u043c\u043e\u0433\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u044d\u043a\u0437\u0435\u043c\u043f\u043b\u044f\u0440\u0430 GitLab \u0432 \u043f\u0440\u0438\u0440\u043e\u0434\u0435. \u0417\u0434\u0435\u0441\u044c 3 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u0430 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438 \u043f\u043e\u0447\u0442\u0438 7 \u043c\u0438\u043b\u043b\u0438\u043e\u043d\u043e\u0432 \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0438 \u044d\u0442\u043e \u043e\u0434\u0438\u043d \u0438\u0437 \u0441\u0430\u043c\u044b\u0445 \u043a\u0440\u0443\u043f\u043d\u044b\u0445 \u043e\u043f\u0435\u043d\u0441\u043e\u0440\u0441-\u0441\u0430\u0439\u0442\u043e\u0432 SaaS \u0441 \u0432\u044b\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043e\u0439. \u0411\u0435\u0437 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22360,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30356","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Hogyan haszn\u00e1ltuk az elhalasztott replik\u00e1ci\u00f3t katasztr\u00f3fa-helyre\u00e1ll\u00edt\u00e1shoz PostgreSQL-lel | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043b\u0438 \u043e\u0442\u043b\u043e\u0436\u0435\u043d\u043d\u0443\u044e \u0440\u0435\u043f\u043b\u0438\u043a\u0430\u0446\u0438\u044e \u0434\u043b\u044f \u0430\u0432\u0430\u0440\u0438\u0439\u043d\u043e\u0433\u043e \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f \u0441 PostgreSQL | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:35:06+00:00","article:modified_time":"2019-10-31T18:35:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30356","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 00:50:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:48:29","updated":"2026-01-21 00:50:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}