{"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\/sq\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Si e p\u00ebrdor\u00ebm replikimin e vonuar p\u00ebr rikuperimin e emergjenc\u00ebs me PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\nReplikimi nuk \u00ebsht\u00eb backup. Apo ndoshta po? K\u00ebshtu e p\u00ebrdor\u00ebm replikimin e vonsh\u00ebm p\u00ebr t\u00eb rikuperuar, duke fshir\u00eb rast\u00ebsisht lidhjet.<\/p>\n

<\/p>\n

Specialist\u00ebt e Infrastruktur\u00ebs<\/a><\/noindex> n\u00eb GitLab jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr funksionimin GitLab.com<\/a><\/noindex> \u2014 instanca m\u00eb e madhe e GitLab n\u00eb bot\u00eb. K\u00ebtu ka 3 milion p\u00ebrdorues dhe pothuajse 7 milion projekte, dhe ky \u00ebsht\u00eb nj\u00eb nga sajtet m\u00eb t\u00eb m\u00ebdha open-source SaaS me nj\u00eb arkitektur\u00eb t\u00eb dedikuar. Pa sistemin e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave PostgreSQL, infrastruktura e GitLab.com nuk do t\u00eb shkoj\u00eb larg, dhe ne kemi b\u00ebr\u00eb \u00e7do gj\u00eb p\u00ebr t\u00eb siguruar q\u00eb t\u00eb jemi t\u00eb gatsh\u00ebm p\u00ebr \u00e7do d\u00ebshtim q\u00eb mund t\u00eb \u00e7oj\u00eb n\u00eb humbjen e t\u00eb dh\u00ebnave. \u00cbsht\u00eb e pamundshme q\u00eb nj\u00eb katastrof\u00eb e till\u00eb t\u00eb ndodh\u00eb, por ne jemi shum\u00eb t\u00eb p\u00ebrgatitur dhe kemi siguruar mekanizma t\u00eb ndrysh\u00ebm p\u00ebr backup dhe replikim.<\/p>\n

<\/p>\n

Replikimi nuk \u00ebsht\u00eb nj\u00eb mjet backup p\u00ebr bazat e t\u00eb dh\u00ebnave (shih m\u00eb posht\u00eb<\/a><\/noindex>). Por tani do t\u00eb shohim se si t\u00eb rikuperojm\u00eb shpejt t\u00eb dh\u00ebnat e fshir\u00eb rast\u00ebsisht me an\u00eb t\u00eb replikimit t\u00eb vonsh\u00ebm: n\u00eb GitLab.com<\/a><\/noindex> p\u00ebrdorues fshiva lidhjen<\/a><\/noindex> p\u00ebr projektin gitlab-ce<\/code><\/a><\/noindex> dhe humba lidhjet me k\u00ebrkesat p\u00ebr bashkim dhe detyrat.<\/p>\n

<\/p>\n

Me replik\u00ebn e vonshme, ne e rikuperuam t\u00eb dh\u00ebnat vet\u00ebm brenda 1.5 or\u00ebve. Shihni si ndodhi.<\/p>\n

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

Rikuperimi n\u00eb nj\u00eb moment t\u00eb caktuar me PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL ka nj\u00eb funksion t\u00eb nd\u00ebrtuar, i cili rikthen gjendjen e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave n\u00eb nj\u00eb moment t\u00eb caktuar. E quajtur Rikuperimi n\u00eb Momentin e Caktuar<\/a><\/noindex> (PITR) dhe p\u00ebrdor mekanizmat e nj\u00ebjt\u00eb q\u00eb mb\u00ebshtesin aktualitetin e replik\u00ebs: duke filluar nga nj\u00eb snapshot i besuesh\u00ebm i gjith\u00eb klasterit t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave (backup bazik), ne aplikojm\u00eb nj\u00eb s\u00ebr\u00eb ndryshimesh deri n\u00eb nj\u00eb moment t\u00eb caktuar.<\/p>\n

<\/p>\n

P\u00ebr t\u00eb p\u00ebrdorur k\u00ebt\u00eb funksion p\u00ebr backup t\u00eb ftoht\u00eb, ne rregullisht b\u00ebjm\u00eb backup bazik t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave dhe e ruajm\u00eb at\u00eb n\u00eb arkiv\u00eb (arkivat e GitLab jetojn\u00eb n\u00eb ruajtjen e cloud Google<\/a><\/noindex>). Po ashtu, monitorojm\u00eb ndryshimet e gjendjes s\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, duke arkivuar log-un e sh\u00ebnimeve t\u00eb parashikuara (logs t\u00eb sh\u00ebnimeve t\u00eb parashikueshme<\/a><\/noindex>, WAL). Dhe me gjith\u00eb k\u00ebt\u00eb ne mund t\u00eb realizojm\u00eb PITR p\u00ebr rikuperim n\u00eb rast fatkeq\u00ebsie: fillojm\u00eb me snapshot-in e b\u00ebr\u00eb para gabimit dhe aplikojm\u00eb ndryshimet nga arkiva WAL deri n\u00eb d\u00ebshtim.<\/p>\n

<\/p>\n

\u00c7far\u00eb \u00ebsht\u00eb replikimi i vonsh\u00ebm?<\/h3>\n

<\/p>\n

Replikimi i vonsh\u00ebm \u00ebsht\u00eb aplikimi i ndryshimeve nga WAL me nj\u00eb vones\u00eb. Dometh\u00ebn\u00eb transaksioni ndodhi n\u00eb or\u00ebn X<\/code>, por n\u00eb replik\u00eb do t\u00eb shfaqet me nj\u00eb vones\u00eb d<\/code> n\u00eb or\u00ebn X + d<\/code>.<\/p>\n

<\/p>\n

N\u00eb PostgreSQL ka 2 m\u00ebnyra p\u00ebr t\u00eb konfiguruar nj\u00eb replik\u00eb fizike t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave: rikuperimi nga arkiva dhe replikimi me transmetim. Rikuperimi nga arkiva<\/a><\/noindex>, n\u00eb thelb, funksionon si PITR, por n\u00eb vazhdim\u00ebsi: ne vazhdimisht nxjerrim ndryshimet nga arkivi WAL dhe i aplikojm\u00eb ato n\u00eb kopjen e dyt\u00eb. A replikimi n\u00eb rrjedh\u00eb<\/a><\/noindex> nxjerr drejtp\u00ebrdrejt rrjedh\u00ebn e WAL nga hosti m\u00eb i lart\u00eb t\u00eb databaz\u00ebs. Ne preferojm\u00eb rikthimin nga arkivi \u2014 \u00ebsht\u00eb m\u00eb e leht\u00eb t\u00eb menaxhohet dhe ka performanc\u00eb t\u00eb ndershme, e cila nuk mbetet pas klasit t\u00eb pun\u00ebs.<\/p>\n

<\/p>\n

Si t\u00eb konfiguroni rikthimin e vonuar nga arkivi<\/h3>\n

<\/p>\n

Opcioni i rikthimit<\/a><\/noindex> \u00ebsht\u00eb p\u00ebrshkruar n\u00eb skedarin recovery.conf<\/code>. Shembull:<\/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
Me k\u00ebto parametra, ne kemi konfiguruar nj\u00eb kopje t\u00eb vonuar me rikthim nga arkivi. K\u00ebtu p\u00ebrdoret wal-e<\/a><\/noindex> p\u00ebr t\u00eb nxjerr\u00eb segmente WAL (restore_command<\/code>) nga arkivi, dhe ndryshimet do t\u00eb aplikohen pas tet\u00eb or\u00ebsh (recovery_min_apply_delay<\/code>). Kopja do t\u00eb ndjek\u00eb ndryshimet n\u00eb linj\u00ebn e koh\u00ebs n\u00eb arkiv, p\u00ebr shembull, p\u00ebr shkak t\u00eb ndodhis\u00eb s\u00eb d\u00ebshtimit n\u00eb klas\u00eb (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
D recovery_min_apply_delay<\/code> mund t\u00eb konfiguroni replikimin n\u00eb rrjedh\u00eb me vones\u00eb, por k\u00ebtu ka disa mashtrime q\u00eb lidhen me slotet e replikimit, feedback-un e rezerv\u00ebs aktive etj. Arkiva WAL lejon t\u00eb shmangen ato.<\/p>\n
<\/p>\n
Parametri recovery_min_apply_delay<\/code> u prezantua vet\u00ebm n\u00eb PostgreSQL 9.3. N\u00eb versionet e m\u00ebparshme, p\u00ebr replikimin e vonuar duhej t\u00eb konfiguroni nj\u00eb kombinim t\u00eb funksioneve p\u00ebr menaxhimin e rikthimit<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) ose t\u00eb mbani segmentet WAL n\u00eb arkiv gjat\u00eb koh\u00ebs s\u00eb vones\u00ebs.<\/p>\n
<\/p>\n
Si e b\u00ebn PostgreSQL k\u00ebt\u00eb?<\/h3>\n
<\/p>\n
\u00cbsht\u00eb interesante t\u00eb shikoni si PostgreSQL implementon rikthimin e vonuar. Le t\u00eb shohim n\u00eb recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Ai thirret nga cikli kryesor i p\u00ebrs\u00ebritjes<\/a><\/noindex> p\u00ebr \u00e7do sh\u00ebnim nga WAL.<\/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    \/* nothing to do if no delay configured *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* no delay is applied on a database not yet consistent *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * Is it a COMMIT record?\n     *\n     * We deliberately choose not to delay aborts since they have no effect on\n     * MVCC. We already allow replay of records that don't have a timestamp,\n     * so there is already opportunity for issues caused by early conflicts on\n     * standbys.\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     * Exit without arming the latch if it's already past time to apply this\n     * record\n     *\/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ Shortened:\n        \/\/ Use WaitLatch until we reached recoveryDelayUntilTime\n        \/\/ and then\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
Kjo \u00ebsht\u00eb e v\u00ebrteta, se vonesa bazohet n\u00eb koh\u00ebn fizike t\u00eb regjistruar n\u00eb etiket\u00ebn e koh\u00ebs s\u00eb angazhimit t\u00eb transaksionit (xtime<\/code>). Si\u00e7 shihet, vonesa aplikohet vet\u00ebm p\u00ebr angajimet dhe nuk prek regjistrimet e tjera \u2014 t\u00eb gjitha ndryshimet aplikohen drejtp\u00ebrdrejt, dhe angazhimi vonohet, k\u00ebshtu q\u00eb ne do t'i shohim ndryshimet vet\u00ebm pas vones\u00ebs s\u00eb caktuar.<\/p>\n
<\/p>\n
Si t\u00eb p\u00ebrdorim replikimin e vonuar p\u00ebr rikuperimin e t\u00eb dh\u00ebnave<\/h3>\n
<\/p>\n
Supozoni se kemi nj\u00eb grup t\u00eb dh\u00ebnash n\u00eb prodhim dhe nj\u00eb replik\u00eb me nj\u00eb vones\u00eb prej tet\u00eb or\u00ebsh. Le t\u00eb shohim si t\u00eb rikuperojm\u00eb t\u00eb dh\u00ebnat duke marr\u00eb si shembull fshirjen e rast\u00ebsishme t\u00eb etiketave<\/a><\/noindex>.<\/p>\n
<\/p>\n
Kur m\u00ebsuam p\u00ebr problemin, ne pam\u00eb rikuperimin nga arkiva<\/a><\/noindex> p\u00ebr replik\u00ebn e vonuar:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Me pauz\u00ebn nuk kishim asnj\u00eb rrezik q\u00eb replika t\u00eb p\u00ebrs\u00ebris\u00eb k\u00ebrkes\u00ebn FSHI<\/code>. Nj\u00eb gj\u00eb e dobishme, n\u00ebse nevojitet koh\u00eb p\u00ebr t\u00eb sqaruar gjith\u00e7ka.<\/p>\n
<\/p>\n
E v\u00ebrteta \u00ebsht\u00eb, se replika e vonuar duhet t\u00eb arrij\u00eb momentin para k\u00ebrkes\u00ebs FSHI<\/code>. Ne e dinim pak a shum\u00eb koh\u00ebn fizike t\u00eb fshirjes. Ne fshim recovery_min_apply_delay<\/code> dhe shtojm\u00eb recovery_target_time<\/code> n\u00eb recovery.conf<\/code>. K\u00ebshtu replika arrin n\u00eb momentin e nevojsh\u00ebm pa vonesa:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Me etiketat e koh\u00ebs \u00ebsht\u00eb m\u00eb mir\u00eb t\u00eb tregoni m\u00eb pak, p\u00ebr t\u00eb mos humbur drejtimin. Megjithat\u00eb, sa m\u00eb shum\u00eb t\u00eb heqim, aq m\u00eb shum\u00eb t\u00eb dh\u00ebna humbasim. P\u00ebrs\u00ebri, n\u00ebse kalojm\u00eb k\u00ebrkes\u00ebn FSHI<\/code>, gjith\u00e7ka do t\u00eb fshihet p\u00ebrs\u00ebri dhe do t\u00eb duhet t\u00eb fillojm\u00eb nga e para (ose n\u00eb fakt t\u00eb marrim nj\u00eb kopje m\u00eb t\u00eb ftoht\u00eb p\u00ebr PITR).<\/p>\n
<\/p>\n
Ne shfuqiz\u00ebm instanc\u00ebn e vonuar t\u00eb Postgres dhe segmentet WAL u p\u00ebrs\u00ebrit\u00ebn deri n\u00eb koh\u00ebn e caktuar. Mund t\u00eb ndiqni progresin n\u00eb k\u00ebt\u00eb hap p\u00ebrmes pyetjes:<\/p>\n
<\/p>\n
SELECT\n  -- vendndodhja aktuelle n\u00eb WAL\n  pg_last_xlog_replay_location(),\n  -- marka e koh\u00ebs s\u00eb aktualizimit t\u00eb transaksionit (gjendja e kopjes s\u00eb dh\u00ebnash)\n  pg_last_xact_replay_timestamp(),\n  -- koha aktuale fizike\n  now(),\n  -- sasia e koh\u00ebs q\u00eb duhet t\u00eb aplikohet deri n\u00eb arritjen e koh\u00ebs s\u00eb objektivit t\u00eb rikuperimit\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() si vones\u00eb;<\/code><\/pre>\n
<\/p>\n
N\u00ebse marka e koh\u00ebs nuk ndryshon m\u00eb, rikuperimi \u00ebsht\u00eb p\u00ebrfunduar. Mund t\u00eb konfiguroni veprimin recovery_target_action<\/code><\/a><\/noindex>, p\u00ebr t\u00eb mbyllur, avancuar ose pezulluar instanc\u00ebn pas p\u00ebrs\u00ebritjes (n\u00eb m\u00ebnyr\u00eb default ajo pezullohet).<\/p>\n
<\/p>\n
Baza e t\u00eb dh\u00ebnave arriti n\u00eb gjendjen para atij k\u00ebrkese fatkeqe. Tani mund t\u00eb, p\u00ebr shembull, eksportoni t\u00eb dh\u00ebnat. Ne eksportuam t\u00eb dh\u00ebnat e fshira p\u00ebr etiket\u00ebn dhe t\u00eb gjitha lidhjet me detyrat dhe merge-request-at dhe i transferuam ato n\u00eb baz\u00ebn e t\u00eb dh\u00ebnave aktive. N\u00ebse humbjet jan\u00eb t\u00eb m\u00ebdha, mund thjesht t\u00eb avancojm\u00eb kopjen dhe ta p\u00ebrdorim si baz\u00ebn kryesore. Por at\u00ebher\u00eb do t\u00eb humbasim t\u00eb gjitha ndryshimet pas momentit deri n\u00eb t\u00eb cilin u rikuperuam.<\/p>\n
<\/p>\n
M\u00eb mir\u00eb se sa markat e koh\u00ebs \u00ebsht\u00eb t\u00eb p\u00ebrdorim ID-t\u00eb e transaksioneve. \u00cbsht\u00eb e dobishme t\u00eb regjistroni k\u00ebto ID, p\u00ebr shembull, p\u00ebr operator\u00ebt DDL (si\u00e7 \u00ebsht\u00eb DROP TABLE<\/code>) me an\u00eb t\u00eb log_statements = 'ddl'<\/code>. Sikur t\u00eb kishim ID-n\u00eb e transaksionit, do t\u00eb merrnim recovery_target_xid<\/code> dhe do t\u00eb kalonim t\u00eb gjitha deri n\u00eb transaksionin para k\u00ebrkes\u00ebs. FSHI<\/code>.<\/p>\n
<\/p>\n
T\u00eb kthehesh n\u00eb pun\u00eb \u00ebsht\u00eb shum\u00eb e thjesht\u00eb: hiqni t\u00eb gjitha ndryshimet nga recovery.conf<\/code> dhe riu aktivizoni Postgres. S\u00eb shpejti do t\u00eb rikthehet vonesa e tet\u00eb or\u00ebve n\u00eb kopjen e dh\u00ebnave, dhe ne jemi gati p\u00ebr ndodhit\u00eb e ardhshme.<\/p>\n
<\/p>\n
P\u00ebrfitimet p\u00ebr rikuperim<\/h3>\n
<\/p>\n
Me nj\u00eb kopje t\u00eb vonuar n\u00eb vend t\u00eb nj\u00eb kopje t\u00eb ftoht\u00eb, nuk \u00ebsht\u00eb e nevojshme t\u00eb rikuperoni gjith\u00eb snapshot-in nga arkiva p\u00ebr or\u00eb t\u00eb t\u00ebra. P\u00ebr ne, p\u00ebr shembull, na duhen pes\u00eb or\u00eb p\u00ebr t\u00eb nxjerr\u00eb t\u00eb gjith\u00eb kopjen e baz\u00ebs mbi 2 TB. Dhe pastaj do t\u00eb duhej t\u00eb aplikonim t\u00eb gjith\u00eb WAL-in ditor p\u00ebr t'u rikuperuar n\u00eb gjendjen e nevojshme (n\u00eb rastin m\u00eb t\u00eb keq).<\/p>\n
<\/p>\n
Kopja e vonuar \u00ebsht\u00eb m\u00eb e mir\u00eb se nj\u00eb kopje e ftoht\u00eb p\u00ebr dy arsye:<\/p>\n
<\/p>\n
    \n
  1. Nuk \u00ebsht\u00eb e nevojshme t\u00eb nxirrni t\u00eb gjith\u00eb kopjen baz\u00eb nga arkiva.<\/li>\n
  2. Ka nj\u00eb dritare t\u00eb fiksuar t\u00eb tet\u00eb or\u00ebve t\u00eb segmenteve WAL q\u00eb duhet t\u00eb p\u00ebrs\u00ebriten.<\/li>\n<\/ol>\n
    <\/p>\n
    Po ashtu, ne vazhdojm\u00eb t\u00eb kontrollojm\u00eb n\u00ebse mund t\u00eb b\u00ebjm\u00eb PITR nga WAL, dhe do ta kishim v\u00ebrejtur shpejt \u00e7do d\u00ebmtim ose probleme t\u00eb tjera me arkiv\u00ebn WAL, duke ndjekur vones\u00ebn e kopjes s\u00eb vonuar.<\/p>\n
    <\/p>\n
    N\u00eb k\u00ebt\u00eb shembull, na duhej 50 minuta p\u00ebr rikuperimin, q\u00eb do t\u00eb thot\u00eb nj\u00eb shpejt\u00ebsi prej 110 GB t\u00eb dh\u00ebnash WAL n\u00eb or\u00eb (arkiva ndodhej ende n\u00eb AWS S3<\/a><\/noindex>). N\u00eb total, ne zgjodh\u00ebm problemin dhe rikthyem t\u00eb dh\u00ebnat brenda 1.5 or\u00ebve.<\/p>\n
    <\/p>\n
    P\u00ebrfundimet: ku do t\u00eb nevojitet replikimi i vonuar (dhe ku jo)<\/h3>\n
    <\/p>\n
    P\u00ebrdorni replikimin e vonuar si nj\u00eb veg\u00ebl ndihm\u00ebs n\u00ebse keni humbur aksidentalisht t\u00eb dh\u00ebna dhe e keni v\u00ebrejtur k\u00ebt\u00eb problem brenda periudh\u00ebs s\u00eb caktuar.<\/p>\n
    <\/p>\n
    Por mbani parasysh: replikimi nuk \u00ebsht\u00eb backup.<\/p><\/blockquote>\n
    Backup-i dhe replikimi kan\u00eb q\u00ebllime t\u00eb ndryshme. Backup-i i ftoht\u00eb \u00ebsht\u00eb i dobish\u00ebm n\u00ebse keni b\u00ebr\u00eb aksidentalisht FSHI<\/code> \u0438\u043b\u0438 DROP TABLE<\/code>. Ne b\u00ebjm\u00eb backup nga depoja e ftoht\u00eb dhe rikthejm\u00eb gjendjen e m\u00ebparshme t\u00eb tabel\u00ebs ose t\u00eb gjith\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave. Por n\u00eb k\u00ebt\u00eb rast, k\u00ebrkesa DROP TABLE<\/code> palmost momentalisht riprodhohet n\u00eb t\u00eb gjitha replikat n\u00eb klastri aktiv, k\u00ebshtu q\u00eb replikimi normal k\u00ebtu nuk do t\u00eb ndihmoj\u00eb. Vet\u00eb replikimi mb\u00ebshtet baz\u00ebn e t\u00eb dh\u00ebnave n\u00eb dispozicion kur disa server\u00eb dalin jasht\u00eb funksionit dhe shp\u00ebrndan ngarkes\u00ebn.<\/p>\n
    <\/p>\n
    Edhe me replikimin e vonuar, ndonj\u00ebher\u00eb na nevojitet shum\u00eb nj\u00eb backup i ftoht\u00eb n\u00eb nj\u00eb vend t\u00eb sigurt, n\u00ebse ndodh ndonj\u00eb d\u00ebshtim n\u00eb qendr\u00ebn e t\u00eb dh\u00ebnave, d\u00ebmtim t\u00eb fshehur ose ngjarje t\u00eb tjera q\u00eb nuk i v\u00ebren menj\u00ebher\u00eb. K\u00ebtu nj\u00eb replikim i vet\u00ebm nuk \u00ebsht\u00eb i mjaftuesh\u00ebm.<\/p>\n
    <\/p>\n
    Sh\u00ebnim<\/strong>. N\u00eb GitLab.com<\/a><\/noindex> Ne aktualisht mbrojm\u00eb humbjen e t\u00eb dh\u00ebnave vet\u00ebm n\u00eb nivelin e sistemit dhe nuk rikthejm\u00eb t\u00eb dh\u00ebnat n\u00eb nivelin e p\u00ebrdoruesit.<\/p>\n
    Burimi: 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\udd47Si p\u00ebrdor\u00ebm replikimin e vonuar p\u00ebr rim\u00ebk\u00ebmbjen e fatkeq\u00ebsive me PostgreSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}