{"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\/et\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Kuidas kasutame viivitusega replikatsiooni h\u00e4daolukordade taastamiseks PostgreSQL-is","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\nReplikatsioon \u2014 ei ole varundamine. V\u00f5i siiski? Nii kasutasime me edasil\u00fckatud replikatsiooni taastamiseks, kogemata kustutades otseteed.<\/p>\n

<\/p>\n

Infrastruktuuri spetsialistid<\/a><\/noindex> GitLabis vastutavad t\u00f6\u00f6 eest GitLab.com<\/a><\/noindex> \u2014 k\u00f5ige suurema GitLabi instantsi eest maailmas. Siin on 3 miljonit kasutajat ja peaaegu 7 miljonit projekti, ja see on \u00fcks suurimaid avatud l\u00e4htekoodiga SaaS saite p\u00fchendatud arhitektuuriga. Ilma PostgreSQL andmebaasis\u00fcsteemita ei p\u00e4\u00e4se GitLab.com kaugele, ja mida iganes me ei tee, et tagada t\u00f5rkeajalise j\u00e4tkusuutlikkuse saamiseks, kui andmed v\u00f5ivad kaduda. Selline katastroof ei pruugi juhtuda, kuid oleme h\u00e4sti ette valmistatud ja varustatud erinevate varundamis- ja replikatsioonimehhanismidega.<\/p>\n

<\/p>\n

Replikatsioon ei ole andmebaasi varundamise vahend (vt allpool<\/a><\/noindex>). Aga n\u00fc\u00fcd n\u00e4eme, kui kiiresti saab kogemata kustutatud andmeid taastada edasil\u00fckatud replikatsiooni abil: eemaldasin GitLab.com<\/a><\/noindex> kasutaja otsetee<\/a><\/noindex> projekti jaoks gitlab-ce<\/code><\/a><\/noindex> ja kaotasin sidemed \u00fchendamise taotluste ja \u00fclesannetega.<\/p>\n

<\/p>\n

Edasil\u00fckatud replikatsiooniga taastasime andmed vaid 1,5 tunniga. Vaadake, kuidas see toimus.<\/p>\n

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

Taastamine PostgreSQL-i ajas<\/h3>\n

<\/p>\n

PostgreSQL-l on sisseehitatud funktsioon, mis taastab andmebaasi oleku kindlal ajahetkel. Selle nimi on Punkt-aegne taastamine<\/a><\/noindex> (PITR) ja see kasutab samu mehhanisme, mis s\u00e4ilitavad repliika ajakohasuse: alates usaldusv\u00e4\u00e4rsest kogu andmebaasi klastrist tehtud pildist (baasbackup), rakendame muudatusi olekusse kuni kindla ajani.<\/p>\n

<\/p>\n

Selle funktsiooni kasutamiseks k\u00fclma varundamise jaoks teeme regulaarselt andmebaasi baasbackup'i ja hoiame seda arhiivis (GitLabi arhiivid elavad Google'i pilvek\u00fcljel<\/a><\/noindex>). Samuti j\u00e4lgime andmebaasi oleku muudatusi, arhiveerides ette kirjutamise ajakirja (write-ahead log<\/a><\/noindex>, WAL). K\u00f5ikide nende andmetega saame teha PITR-i avariirestaurimiseks: alustame pildist, mis tehti enne viga, ja rakendame WAL-i arhiivist muudatused kuni t\u00f5rkeni.<\/p>\n

<\/p>\n

Mis on viivitusega replikatsioon?<\/h3>\n

<\/p>\n

Viivitusega replikatsioon on muudatuste rakendamine WAL-ist viivitusega. See t\u00e4hendab, et tehing toimus kell X<\/code>, kuid replikatsioonis ilmneb see viivitusega d<\/code> tunni v\u00f5rra X + d<\/code>.<\/p>\n

<\/p>\n

PostgreSQL-is on 2 viisi andmebaasi f\u00fc\u00fcsilise replika seadistamiseks: taastamine arhivist ja voogedastusreplikatsioon. Taastamine arhivist<\/a><\/noindex>, toimib p\u00f5him\u00f5tteliselt nagu PITR, kuid pidevalt: me ekstraktime pidevalt muudatused arhivist WAL ja kohandame need replikale. Ja voogedastusreplikatsioon<\/a><\/noindex> ekstraktib otse WAL voolu k\u00f5rgemalt andmebaasi hostilt. Eelistame taastamist arhivist \u2013 sellega on lihtsam hallata ja sellel on normaalne j\u00f5udlus, mis ei j\u00e4\u00e4 t\u00f6\u00f6klastrist maha.<\/p>\n

<\/p>\n

Kuidas seadistada viivitusega taastamine arhivist<\/h3>\n

<\/p>\n

Taastamisvalikud<\/a><\/noindex> on kirjeldatud failis recovery.conf<\/code>. N\u00e4ide:<\/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
Nende parameetritega oleme seadistanud viivitusega repliika taastamise arhivist. Siin kasutatakse wal-e<\/a><\/noindex> WAL segmentide (restore_command<\/code>) ekstraheerimiseks arhivist, ja muudatused rakendatakse kaheksa tunni p\u00e4rast (recovery_min_apply_delay<\/code>). Replika j\u00e4lgib arhivi ajaskaala muutusi, n\u00e4iteks klasteri t\u00f5rke juhtumite korral (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
C recovery_min_apply_delay<\/code> streamingu replikatsiooni on v\u00f5imalik seadistada viivitusega, kuid siin on m\u00f5ned takistused, mis on seotud replikatsiooni slotidega, kuuma varundamise tagasisidega jne. WAL arhiiv aitab neid v\u00e4ltida.<\/p>\n
<\/p>\n
Parameeter recovery_min_apply_delay<\/code> ilmus ainult PostgreSQL 9.3-s. Eelmistes versioonides tuli viivitatud replikatsiooni seadistamiseks kasutada kombinatsiooni taasterehvide haldusfunktsioonidest<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) v\u00f5i hoida WAL segmente arhiivis viivituse kestuse jooksul.<\/p>\n
<\/p>\n
Kuidas PostgreSQL seda teeb?<\/h3>\n
<\/p>\n
Huvitav on vaadata, kuidas PostgreSQL rakendab viivitatud taastamist. Vaatame recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Seda kutsutakse v\u00e4lja peamise kordusprotsessi k\u00e4igus<\/a><\/noindex> iga WAL-i kirje jaoks.<\/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    \/* \u043d\u0438\u0447\u0435\u0433\u043e \u0434\u0435\u043b\u0430\u0442\u044c \u043d\u0435 \u043d\u0443\u0436\u043d\u043e, \u0435\u0441\u043b\u0438 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0435 \u043d\u0430\u0441\u0442\u0440\u043e\u0435\u043d\u0430 *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0435 \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0435\u0442\u0441\u044f \u043a \u0431\u0430\u0437\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0435\u0449\u0435 \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0439 *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * \u042d\u0442\u043e \u0437\u0430\u043f\u0438\u0441\u044c COMMIT?\n     *\n     * \u041c\u044b \u0441\u043e\u0437\u043d\u0430\u0442\u0435\u043b\u044c\u043d\u043e \u0432\u044b\u0431\u0438\u0440\u0430\u0435\u043c \u043d\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0442\u044c \u043e\u0442\u043c\u0435\u043d\u044b, \u0442\u0430\u043a \u043a\u0430\u043a \u043e\u043d\u0438 \u043d\u0435 \u0432\u043b\u0438\u044f\u044e\u0442 \u043d\u0430\n     * MVCC. \u041c\u044b \u0443\u0436\u0435 \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u0435\u043c \u0432\u043e\u0441\u043f\u0440\u043e\u0438\u0437\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0437\u0430\u043f\u0438\u0441\u0435\u0439, \u0443 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043d\u0435\u0442 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0439 \u043c\u0435\u0442\u043a\u0438,\n     * \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0443\u0436\u0435 \u0435\u0441\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0434\u043b\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u0432\u044b\u0437\u0432\u0430\u043d\u043d\u044b\u0445 \u0440\u0430\u043d\u043d\u0438\u043c\u0438 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u0430\u043c\u0438 \u043d\u0430\n     * \u0437\u0430\u043f\u0430\u0441\u043d\u044b\u0445.\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     * \u0412\u044b\u0445\u043e\u0434\u0438\u0442\u0435, \u043d\u0435 \u0432\u0437\u0432\u043e\u0434\u044f \u0437\u0430\u0434\u0432\u0438\u0436\u043a\u0443, \u0435\u0441\u043b\u0438 \u0443\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0432\u0440\u0435\u043c\u044f \u0434\u043b\u044f \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439\n     * \u0437\u0430\u043f\u0438\u0441\u0438\n     *\/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ \u0423\u043a\u043e\u0440\u043e\u0447\u0435\u043d\u043e:\n        \/\/ \u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0439\u0442\u0435 WaitLatch, \u043f\u043e\u043a\u0430 \u043d\u0435 \u0434\u043e\u0441\u0442\u0438\u0433\u043d\u0435\u043c recoveryDelayUntilTime\n        \/\/ \u0438 \u0437\u0430\u0442\u0435\u043c\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
M\u00f5te on selles, et viivitus p\u00f5hineb f\u00fc\u00fcsilisel ajal, mis on fikseeritud tehingu kinnituse ajal (xtime<\/code>). Nagu n\u00e4ha, rakendatakse viivitust ainult kinnitustele ja see ei puuduta teisi sisestusi \u2014 k\u00f5ik muudatused rakendatakse otse, samas kui kinnitus l\u00fckatakse edasi, nii et n\u00e4eme muudatusi alles p\u00e4rast seadistatud viivitust.<\/p>\n
<\/p>\n
Kuidas kasutada viivitavat koopiat andmete taastamiseks<\/h3>\n
<\/p>\n
Oletame, et meil on tootmises andmebaasi klaster ja kaheksa tunni viivitusega koopiad. Vaatame, kuidas andmeid taastada n\u00e4ite kaudu juhusliku otste kustutamise<\/a><\/noindex>.<\/p>\n
<\/p>\n
Kui me probleemist teada saime, peatame taastamise arhiivist<\/a><\/noindex> viivitava koopia jaoks:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Peatamise ajal ei olnud meil riski, et koopia kordab p\u00e4ringut DELETE<\/code>. Kasulik asi, kui on vaja aega k\u00f5ike l\u00e4bi m\u00f5elda.<\/p>\n
<\/p>\n
K\u00fcsimus on selles, et viivitav koopia peab j\u00f5udma hetke enne p\u00e4ringut DELETE<\/code>. Me teadsime ligikaudset f\u00fc\u00fcsilist kustutamise aega. Kustutasime recovery_min_apply_delay<\/code> ja lisasime recovery_target_time<\/code> \u00fches recovery.conf<\/code>. Nii j\u00f5uab koopia soovitud hetkeni viivitusteta:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Aja m\u00e4rkide puhul on parem liialdamist v\u00e4ltida, et eksida ei teeks. Kuid mida rohkem v\u00e4hendate, seda rohkem andmeid kaotate. Taas, kui eksime p\u00e4ringust m\u00f6\u00f6da DELETE<\/code>, k\u00f5ik j\u00e4lle kustutatakse ja tuleb alustada uuesti (v\u00f5i \u00fcldse v\u00f5tta k\u00fclm varundus PITR jaoks).<\/p>\n
<\/p>\n
Me taask\u00e4ivitame edasi l\u00fckatud Postgres'i eksemplari ja WAL segmentide korduvad kuni m\u00e4\u00e4ratud ajani. Selle etapi edenemist saab j\u00e4lgida p\u00e4ringuga:<\/p>\n
<\/p>\n
SELECT\n  -- praegune asukoht WAL'is\n  pg_last_xlog_replay_location(),\n  -- praegune tehingu ajatemperatuur (repliika seisund)\n  pg_last_xact_replay_timestamp(),\n  -- praegune f\u00fc\u00fcsiline aeg\n  now(),\n  -- aeg, mis on veel rakendamiseks, kuni recovery_target_time on saavutatud\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Kui ajatemperatuur enam ei muutu, on taastamine l\u00f5petatud. V\u00f5ib seadistada toimingu recovery_target_action<\/code><\/a><\/noindex>, et sulgeda, edendada v\u00f5i peatada eksemplar p\u00e4rast kordamist (vaikimisi peatatakse see).<\/p>\n
<\/p>\n
Andmebaas on j\u00f5udnud enne seda kurikuulsat p\u00e4ringut. N\u00fc\u00fcd saab n\u00e4iteks andmeid eksportida. Me eksportisime kustutatud andmed sildist ja k\u00f5ik seosed \u00fclesannete ja sulandumisettepanekutega ning kandisime need t\u00f6\u00f6tavasse andmebaasi. Kui kaduded on ulatuslikud, v\u00f5ib lihtsalt edendada repliika ja kasutada seda p\u00f5hina. kuid siis kaovad k\u00f5ik muudatused p\u00e4rast seda aega, millele me taastusime.<\/p>\n
<\/p>\n
Aja aegade asemel on parem kasutada tehingu ID-sid. Need ID-d on kasulikud n\u00e4iteks DDL-operaatorite jaoks (nagu DROP TABLE<\/code>), kasutades log_statements = 'ddl'<\/code>. Kui meil oleks tehingu ID, v\u00f5taksime recovery_target_xid<\/code> ja viiksime l\u00e4bi k\u00f5ik kuni tehinguni, mis eelnes p\u00e4ringule DELETE<\/code>.<\/p>\n
<\/p>\n
Tagasi t\u00f6\u00f6le saamine on v\u00e4ga lihtne: kustutage k\u00f5ik muudatused ja recovery.conf<\/code> ja taask\u00e4ivitage Postgres. Peagi ilmub replikas taas kaheksa tunni viivitus ja oleme valmis tulevaste h\u00e4dadeks.<\/p>\n
<\/p>\n
Taastamise eelised<\/h3>\n
<\/p>\n
Kavandatud replikaga ei pea tundide kaupa kogu arhiivist tagasi t\u00f5mbama. N\u00e4iteks kulub meil viis tundi, et hankida kogu 2 TB p\u00f5hi varukoopia. Ja siis tuleb veel rakendada kogu \u00fchep\u00e4evane WAL, et taastuda soovitud olekusse (halvimal juhul).<\/p>\n
<\/p>\n
Kavandatud replikal on kaks eelist k\u00fclmalt varukoopialt:<\/p>\n
<\/p>\n
    \n
  1. Pole vaja terve p\u00f5hi varukoopia arhiivist v\u00e4lja t\u00f5mmata.<\/li>\n
  2. On fikseeritud kaheksa tunni akna WAL-s segmentoore, mida tuleb korrata.<\/li>\n<\/ol>\n
    <\/p>\n
    Ja me kontrollime pidevalt, kas WAL-ist on v\u00f5imalik PITR-i teha, ning m\u00e4rkaksime kiiresti kahjustusi v\u00f5i muid WAL arhiiviga seotud probleeme, j\u00e4lgides kavandatud replikate mahaj\u00e4\u00e4must.<\/p>\n
    <\/p>\n
    Selles n\u00e4ites kulus meie taastamiseks 50 minutit, st kiirus oli 110 GB WAL andmeid tunnis (arhiiv oli siis veel) AWS S3<\/a><\/noindex>). Kokku lahendasime probleemi ja taastamise aeg oli 1,5 tundi.<\/p>\n
    <\/p>\n
    Kokkuv\u00f5tteks: kus v\u00f5ib abiks olla viivitusega replikatsioon (ja kus mitte)<\/h3>\n
    <\/p>\n
    Kasutage viivitusega replikatsiooni esmaabina, kui te juhuslikult kaotasite andmeid ja m\u00e4rkate seda probleemi seadedud viivituse jooksul.<\/p>\n
    <\/p>\n
    Aga pidage meeles: replikatsioon ei ole varundamine.<\/p><\/blockquote>\n
    Varundamise ja replikatsiooni eesm\u00e4rgid on erinevad. K\u00fclman varundamine on kasulik, kui olete juhuslikult teinud DELETE<\/code> v\u00f5i DROP TABLE<\/code>. Teeme varundamise k\u00fclmhoidlast ja taastame tabeli v\u00f5i kogu andmebaasi eelneva oleku. Kuid sel juhul p\u00e4ring DROP TABLE<\/code> kordub peaaegu koheselt k\u00f5igis replikatsioonides t\u00f6\u00f6klusteris, seega tavaline replikatsioon ei p\u00e4\u00e4sta siin. Replikatsioon ise hoiab andmebaasi kergesti saadaval, kui eraldi serverid langevad, ja jagab koormust.<\/p>\n
    <\/p>\n
    Isegi viivitusega replikatsiooniga on meil m\u00f5nikord v\u00e4ga vajalik k\u00fclmv\u00f5tt varundamine ohutus kohas, kui peaks toimuma andmekeskuse rike, varjatud kahjustus v\u00f5i muud s\u00fcndmused, mida kohe ei m\u00e4rkate. Siin ei aita ainult replikatsioon.<\/p>\n
    <\/p>\n
    M\u00e4rkus<\/strong>. Lehelt GitLab.com<\/a><\/noindex> meie kaitse andmete kadumise eest kehtib praegu ainult s\u00fcsteemitasemel ega taasta andmeid kasutajatulemuses.<\/p>\n
    Allikas: 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\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\udd47Kuidas kasutasime viivitatud replikatsiooni katastroofide taastamiseks PostgreSQL-i | ProHoster","description":"Replikatsioon ei ole varukoopia. V\u00f5i siiski? Nii kasutasime me viivitatud replikatsiooni taastamiseks, kui kustutasime kogemata otseteed. GitLabi infrastruktuuri spetsialistid vastutavad GitLab.com-i, looduse suurima GitLabi instantsi, eest. Siin on 3 miljonit kasutajat ja peaaegu 7 miljonit projekti, ning see on \u00fcks suurimaid avatud l\u00e4htekoodiga SaaS-saitide p\u00fchendatud arhitektuuriga. Ilma s\u00fcsteemita","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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":"\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","og:url":"https:\/\/prohoster.info\/et\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}