{"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 me kasutasime viivitusega replikatsiooni PostgreSQL-i t\u00f5rkeotsingu jaoks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\nReplikatsioon ei ole varundamine. V\u00f5i kuidas? Nii kasutasime edasil\u00fckatud replikatsiooni taastamiseks, kui juhuslikult kaotasime otseteed.<\/p>\n

<\/p>\n

Infrastruktuuri spetsialistid<\/a><\/noindex> GitLabis vastutavad GitLab.com<\/a><\/noindex> \u2014 k\u00f5ige suurema GitLabi eksemplari eest maailmas. Siin on 3 miljonit kasutajat ja peaaegu 7 miljonit projekti, ja see on \u00fcks suurimaid avatud l\u00e4htekoodiga SaaS veebisaite, millel on p\u00fchendatud arhitektuur. Ilma PostgreSQL andmebaasis\u00fcsteemita ei saaks GitLab.com kaugeltki hakkama ning me teeme k\u00f5ik, et tagada j\u00e4tkusuutlikkus igasuguste t\u00f5rgete korral, millega andmed v\u00f5ivad kaduda. See katastroof t\u00f5en\u00e4oliselt ei juhtu, kuid oleme h\u00e4sti ette valmistunud ja varustanud end erinevate varundamis- ja replikatsioonimehhanismidega.<\/p>\n

<\/p>\n

Replikatsioon ei ole andmebaasi varundamise vahend (vt allpool<\/a><\/noindex>). Kuid n\u00fc\u00fcd n\u00e4eme, kuidas kiiresti taastada juhuslikult kustutatud andmed edasil\u00fckatud replikatsiooni abil: GitLab.com<\/a><\/noindex> kasutaja kustutasin otsetee<\/a><\/noindex> projekti jaoks gitlab-ce<\/code><\/a><\/noindex> ja kaotasin \u00fchenduse liitmisettepanekute ja \u00fclesannetega.<\/p>\n

<\/p>\n

Edasil\u00fckatud replikatsiooni abil taastasime andmed vaid 1,5 tunni jooksul. Vaata, kuidas see juhtus.<\/p>\n

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

Ajapunkti taastamine PostgreSQLis<\/h3>\n

<\/p>\n

PostgreSQL-il on sisseehitatud funktsioon, mis taastab andmebaasi seisundi teatud ajapunktis. Seda nimetatakse Ajapunkti taastamine<\/a><\/noindex> (PITR) ja see kasutab samu mehhanisme, mis toetavad replikatsiooni ajakohasust: alustame usaldusv\u00e4\u00e4rsest v\u00e4ljav\u00f5ttest kogu andmebaasi klastrist (p\u00f5hivarundus) ning rakendame muudatusi seisundi osas kuni teatud ajapunktini.<\/p>\n

<\/p>\n

Selle funktsiooni kasutamiseks k\u00fclmavaru, teeme regulaarselt p\u00f5hivarunduse andmebaasist ja hoiame seda arhiivis (GitLabi arhiivide asukoht on Google\u2019i pilvehoidlas<\/a><\/noindex>). Ja j\u00e4lgime ka andmebaasi seisundi muutusi, arhiivides etteteatava kirjutamise p\u00e4eviku (etteteatava p\u00e4eva logi<\/a><\/noindex>, WAL). Ja k\u00f5igega selle abil saame teostada PITR-i avarii taastamiseks: alustame v\u00e4ljav\u00f5ttest, mis tehti enne viga, ja rakendame muudatused WAL arhiivist kuni t\u00f5rkeni.<\/p>\n

<\/p>\n

Mis on edasil\u00fckatud replikatsioon?<\/h3>\n

<\/p>\n

Edasil\u00fckatud replikatsioon on muudatuste rakendamine WAL-st viivitusega. See t\u00e4hendab, et tehing toimus tunni X<\/code>, kuid replikatsioonis ilmub see viivitusega d<\/code> tunni X + d<\/code>.<\/p>\n

<\/p>\n

PostgreSQL-is on kahte t\u00fc\u00fcpi f\u00fc\u00fcsilise andmebaasi replikatsiooni seadistamise viise: arhiivist taastamine ja voogedastav replikatsioon. Arhiivist taastamine<\/a><\/noindex>, sisuliselt t\u00f6\u00f6tab nagu PITR, kuid pidevalt: me ekstrakteerime pidevalt muudatusi WAL arhiivist ja rakendame neid koopiale. A voogedastamise replikatsioon<\/a><\/noindex> ekstraheerib otse WAL voogu \u00fclemalt andmebaasi hostilt. Eelistame taastamist arhiivist \u2014 sellega on lihtsam hallata ja sellel on normaalne j\u00f5udlus, mis ei j\u00e4\u00e4 j\u00e4relhaardest maha.<\/p>\n

<\/p>\n

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

<\/p>\n

Taastamise parameetrid<\/a><\/noindex> on toodud failis recovery.conf<\/code>. N\u00e4idis:<\/p>\n

<\/p>\n

standby_mode = 'on'\nrestore_command = '\u200d\/usr\/bin\/envdir \u200d\/etc\/wal-e.d\/env \u200d\/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 koopia taastamise arhiivist. Siin kasutatakse wal-e<\/a><\/noindex> WAL segmentide (restore_command<\/code>) ekstraheerimiseks arhiivist, ja muudatused rakendatakse kaheksa tunni p\u00e4rast (recovery_min_apply_delay<\/code>). Koopia j\u00e4lgib arhiivi ajaskaala muudatusi, n\u00e4iteks klasteri eba\u00f5nnestumise insidente (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
A recovery_min_apply_delay<\/code> on v\u00f5imalik seadistada viivitusega voogedastamise replikatsioon, kuid siin on paar peent n\u00fcanssi, mis on seotud replikatsiooni slotide, kuumvaru tagasiside ja muu sarnasega. WAL arhiiv v\u00f5imaldab neid v\u00e4ltida.<\/p>\n
<\/p>\n
Parameeter recovery_min_apply_delay<\/code> ilmus alles PostgreSQL 9.3. Eelmistes versioonides tuli viivitusega replikatsiooni seadistamiseks kasutada kombinatsiooni taaste haldamise funktsioonidest<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) v\u00f5i hoida WAL segmente arhiivis viivituse aja jooksul.<\/p>\n
<\/p>\n
Kuidas PostgreSQL seda teeb?<\/h3>\n
<\/p>\n
On huvitav vaadata, kuidas PostgreSQL rakendab viivitusega taastamist. Vaatame recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Seda kutsutakse v\u00e4lja peamises kordussilmuses<\/a><\/noindex> igal WAL kirjal.<\/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 \u043d\u0435 \u043d\u0443\u0436\u043d\u043e \u0434\u0435\u043b\u0430\u0442\u044c, \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 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u0430 *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * \u042d\u0442\u043e \u0437\u0430\u043f\u0438\u0441\u044c COMMIT?\n     *\n     * \u041c\u044b \u043d\u0430\u043c\u0435\u0440\u0435\u043d\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 \u043e\u0442\u043c\u0435\u0442\u043a\u0438 \u0432\u0440\u0435\u043c\u0435\u043d\u0438,\n     * \u0442\u0430\u043a \u0447\u0442\u043e \u0443\u0436\u0435 \u0435\u0441\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0432\u043e\u0437\u043d\u0438\u043a\u043d\u043e\u0432\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c, \u0432\u044b\u0437\u0432\u0430\u043d\u043d\u044b\u0445 \u043f\u0440\u0435\u0436\u0434\u0435\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c\u0438 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u0430\u043c\u0438 \u043d\u0430\n     * \u0440\u0435\u0437\u0435\u0440\u0432\u043d\u044b\u0445 \u043a\u043e\u043f\u0438\u044f\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 \u0431\u0435\u0437 \u0430\u043a\u0442\u0438\u0432\u0430\u0446\u0438\u0438 \u0444\u0438\u043a\u0441\u0430\u0446\u0438\u0438, \u0435\u0441\u043b\u0438 \u0443\u0436\u0435 \u0432\u0440\u0435\u043c\u044f \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0442\u044c \u044d\u0442\u0443\n     * \u0437\u0430\u043f\u0438\u0441\u044c\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\u0439\u0434\u0435\u043c \u0434\u043e recoveryDelayUntilTime\n        \/\/ \u0438 \u0437\u0430\u0442\u0435\u043c\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
K\u00fcsimus on selles, et viivitus p\u00f5hineb f\u00fc\u00fcsilisel ajal, mis on salvestatud tehingu commit'i ajatempli (xtime<\/code>). Nagu n\u00e4ha, kehtib viivitus ainult commit'ide puhul ja ei puutu teistesse salvestustesse \u2014 k\u00f5ik muudatused kehtivad otse ja commit l\u00fckatakse edasi, seega n\u00e4eme muudatusi alles p\u00e4rast seatud viivitust.<\/p>\n
<\/p>\n
Kuidas kasutada viivitust replikatsiooni andmete taastamiseks<\/h3>\n
<\/p>\n
Oletame, et meil on tootmisriigis andmebaasi klaster ja kaheksa tundi viivitusega replikatsioon. Vaadakem, kuidas taastada andmeid n\u00e4iteks juhuslik kustutamine j\u00e4rjenditest<\/a><\/noindex>.<\/p>\n
<\/p>\n
Kui me probleemist kuuldes, oleme peatatud taastamine arhiivist<\/a><\/noindex> viivitusega replikatsiooniks:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Pauses ei olnud meil ohtu, et replikatsioon korraks sama p\u00e4ringut. DELETE<\/code>. Kasulik asi, kui on vaja aega k\u00f5ik \u00e4ra selgitada.<\/p>\n
<\/p>\n
K\u00fcsimus on selles, et viivitusega replikatsioon peab j\u00f5udma hetke enne p\u00e4ringut. DELETE<\/code>. Me teadsime ligikaudu kustutamise f\u00fc\u00fcsilist aega. Me kustutasime recovery_min_apply_delay<\/code> ja lisasime recovery_target_time<\/code> ja recovery.conf<\/code>. Nii j\u00f5uab replikatsioon soovitud hetkeni viivitusteta:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Ajatempleid on parem maha v\u00f5tta, et mitte m\u00f6\u00f6da lasta. T\u00f5si, mida rohkem maha v\u00f5tame, seda rohkem andmeid kaotame. Taas, kui j\u00e4tame p\u00e4ringu vahele, DELETE<\/code>, k\u00f5ik kustub taas ja peame uuesti alustama (v\u00f5i v\u00f5tma k\u00fclma varukoopia PITR jaoks).<\/p>\n
<\/p>\n
Me taask\u00e4ivitame Postgresi viivitustootmise ja WAL-segmendid taastatakse m\u00e4\u00e4ratud ajani. Selle etapi edenemist saab j\u00e4lgida p\u00e4ringuga:<\/p>\n
<\/p>\n
SELECT\n  -- praegune asukoht WAL-s\n  pg_last_xlog_replay_location(),\n  -- praegune tehingu ajatemperatuur (repliika olek)\n  pg_last_xact_replay_timestamp(),\n  -- praegune f\u00fc\u00fcsiline aeg\n  now(),\n  -- ajavahemik, mis tuleb veel rakendada, 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\u00f5ppenud. Saame seadistada tegevuse recovery_target_action<\/code><\/a><\/noindex>, et sulgeda, edastada v\u00f5i peatada eksemplar p\u00e4rast kordamist (vaikimisi peatatakse).<\/p>\n
<\/p>\n
Andmebaas on j\u00f5udnud enne seda \u00f5nnetut p\u00e4ringut. N\u00fc\u00fcd saame n\u00e4iteks andmeid eksportida. Me eksportisime kustutatud andmeid sildist ja k\u00f5ik seosed \u00fclesannete ning \u00fchinemis-ettepanekutega ja kandisime need tootmisandmebaasi. Kui kadumine on ulatuslik, saame lihtsalt edastada repliika ja kasutada seda p\u00f5hina. Aga siis kaovad k\u00f5ik muudatused p\u00e4rast hetke, mil me taastuma j\u00f5udsime.<\/p>\n
<\/p>\n
Aja stampide asemel on parem kasutada tehingu ID-sid. On kasulik need ID-d \u00fcles kirjutada, n\u00e4iteks DDL-operatsioonide jaoks (t\u00fc\u00fcpi DROP TABLE<\/code>), kasutades log_statements = 'ddl'<\/code>. Kui meil oleks tehingu ID, saaksime v\u00f5tta recovery_target_xid<\/code> ja k\u00e4ivitada k\u00f5ik kuni tehinguni enne p\u00e4ringut. DELETE<\/code>.<\/p>\n
<\/p>\n
T\u00f6\u00f6tamiseks naasmine on v\u00e4ga lihtne: eemaldage k\u00f5ik muutused recovery.conf<\/code> ja taask\u00e4ivitage Postgres. Varsti on repliikas taas kaheksa tunni viivitus ja oleme valmis tulevasteks probleemideks.<\/p>\n
<\/p>\n
Taastamise eelised<\/h3>\n
<\/p>\n
Viivitustega repliikaga ei pea kogu varukohta tundideks taastama. N\u00e4iteks kulub meil veel viis tundi, et saada kogu 2 TB suurune p\u00f5hi varukohti arhiivist. Ja siis tuleb veel kogu \u00f6\u00f6p\u00e4eva WAL rakendada, et taastuda soovitud olekusse (halvimal juhul).<\/p>\n
<\/p>\n
Viivitav repliik on parem k\u00fclmavara varukohta kahes punktis:<\/p>\n
<\/p>\n
    \n
  1. Ei pea kogu p\u00f5hi varukohta arhiivist v\u00e4lja t\u00f5mbama.<\/li>\n
  2. On kindel kaheksa tunni aken WAL-segmentide jaoks, mis tuleb taastada.<\/li>\n<\/ol>\n
    <\/p>\n
    Ja me j\u00e4lgime pidevalt, kas WAL-ist saab PITR-i teha, ning m\u00e4rkaks kiiresti kahjustusi v\u00f5i muid WAL-arhiivi probleeme, j\u00e4lgides viivitava repliika mahaj\u00e4\u00e4must.<\/p>\n
    <\/p>\n
    Selles n\u00e4ites kulus meil taastamiseks 50 minutit, mis t\u00e4hendab, et kiirus oli 110 GB WAL-andmeid tunnis (arhiiv oli siis endiselt peal). AWS S3<\/a><\/noindex>). Kokku lahendasime probleemi ja taastatasime andmed 1,5 tunni jooksul.<\/p>\n
    <\/p>\n
    Kokkuv\u00f5te: kus on kasulik edasi l\u00fckatud replikatsioon (ja kus mitte)<\/h3>\n
    <\/p>\n
    Kasutage edasi l\u00fckatud replikatsiooni esmaabi vahendina, kui olete kogemata andmed kaotanud ja m\u00e4rkate seda probleemile seadistatud viivituse raames.<\/p>\n
    <\/p>\n
    Aga pidage meeles: replikatsioon ei ole varundus.<\/p><\/blockquote>\n
    Varundusel ja replikatsioonil on erinevad eesm\u00e4rgid. K\u00fclm varundus on kasulik, kui olete kogemata teinud DELETE<\/code> v\u00f5i DROP TABLE<\/code>. Me teeme varunduse k\u00fclmalt hoidmisest ja taastame tabeli v\u00f5i kogu andmebaasi eelneva oleku. Kuid selles osas p\u00e4ring DROP TABLE<\/code> peaaegu koheselt replitseeritakse k\u00f5ikidesse replikatsioonidesse t\u00f6\u00f6klusteris, seega tavap\u00e4rane replikatsioon siin ei p\u00e4\u00e4sta. Isegi replikatsioon hoiab andmebaasi kergesti k\u00e4ttesaadavana, kui eraldi serverid \u00fcle antakse ja jaotab koormust.<\/p>\n
    <\/p>\n
    Isegi edasi l\u00fckatud replikatsiooniga on meil m\u00f5nikord v\u00e4ga vajalik k\u00fclm varundus turvalises kohas, kui peaks tekkima andmekeskuse t\u00f5rge, varjatud kahjustus v\u00f5i muud olukorrad, mida kohe ei m\u00e4rka. Siin ei ole replikatsioonist abi.<\/p>\n
    <\/p>\n
    M\u00e4rkus<\/strong>. Sellel GitLab.com<\/a><\/noindex> me kaitseme praegu andmete kaotsimineku eest ainult s\u00fcsteemi tasemel ning ei taasta andmeid kasutaja tasemel.<\/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 me kasutasime edasi l\u00fckatud replikatsiooni h\u00e4daolukordadeks PostgreSQL-is | ProHoster","description":".","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":".","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}