{"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 nga fatkeq\u00ebsit\u00eb me PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Si
\nReplicimi \u2014 nuk \u00ebsht\u00eb nj\u00eb kopje rezerv\u00eb. Apo ndoshta \u00ebsht\u00eb? Ja se si e p\u00ebrdor\u00ebm replicimin e vonuar p\u00ebr rikuperim, duke fshir\u00eb rast\u00ebsisht ikona.<\/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 instanc\u00ebn m\u00eb t\u00eb madhe t\u00eb GitLab q\u00eb ekziston. K\u00ebtu jan\u00eb 3 milion p\u00ebrdorues dhe gati 7 milion projekte, dhe kjo \u00ebsht\u00eb nj\u00eb nga uebfaqet m\u00eb t\u00eb m\u00ebdha open-source SaaS me 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 shkonte shum\u00eb larg, dhe ne b\u00ebjm\u00eb gjith\u00e7ka p\u00ebr t\u00eb siguruar disponueshm\u00ebri n\u00eb rast t\u00eb \u00e7\u00ebshtjeve q\u00eb mund t\u00eb \u00e7ojn\u00eb n\u00eb humbjen e t\u00eb dh\u00ebnave. S\u00eb paku, nj\u00eb katastrof\u00eb e till\u00eb \u00ebsht\u00eb e pamundur, por ne kemi b\u00ebr\u00eb p\u00ebrgatitjet tona dhe kemi zbatuar mekanizma t\u00eb ndrysh\u00ebm p\u00ebr kopje rezerv\u00eb dhe replikim.<\/p>\n

<\/p>\n

Replikimi \u2014 kjo nuk \u00ebsht\u00eb nj\u00eb mjet p\u00ebr kopje rezerv\u00eb t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave (shih m\u00eb posht\u00eb<\/a><\/noindex>). Por tani do t\u00eb shohim se si t\u00eb rikuperojm\u00eb t\u00eb dh\u00ebnat e fshira rast\u00ebsisht me ndihm\u00ebn e replikimit t\u00eb vonuar: n\u00eb GitLab.com<\/a><\/noindex> p\u00ebrdorues fshiva ikon\u00ebn<\/a><\/noindex> p\u00ebr projektin gitlab-ce<\/code><\/a><\/noindex> dhe humba lidhjen me k\u00ebrkesat p\u00ebr shkrim dhe detyrat.<\/p>\n

<\/p>\n

Me replikimin e vonuar, ne rikuperuam t\u00eb dh\u00ebnat brenda 1.5 or\u00ebve. Shihni se 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 integruar q\u00eb rikthen gjendjen e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave n\u00eb nj\u00eb moment t\u00eb caktuar. Quhet Rikuperimi n\u00eb Moment-in-Time<\/a><\/noindex> (PITR) dhe p\u00ebrdor mekanizmat e nj\u00ebjt\u00eb q\u00eb mb\u00ebshtesin aktualizimin e replik\u00ebs: duke filluar nga nj\u00eb moment myslimi t\u00eb sakt\u00eb t\u00eb t\u00eb gjith\u00eb klasterit t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave (kopja baz\u00eb), ne aplikojm\u00eb nj\u00eb seri ndryshimesh deri n\u00eb nj\u00eb moment t\u00eb caktuar.<\/p>\n

<\/p>\n

P\u00ebr ta p\u00ebrdorur k\u00ebt\u00eb funksion p\u00ebr kopje rezerv\u00eb t\u00eb ftoht\u00eb, ne rregullisht b\u00ebjm\u00eb kopje 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-it Google<\/a><\/noindex>). Po ashtu, ne ndjekim ndryshimet e gjendjes s\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave, duke arkivuar regjistrin e sh\u00ebnimeve t\u00eb parakohshme (regjistri i parakohsh\u00ebm<\/a><\/noindex>, WAL). Dhe me t\u00eb gjith\u00eb k\u00ebt\u00eb, ne mund t\u00eb realizojm\u00eb PITR p\u00ebr rikuperim emergjent: fillojm\u00eb me nj\u00eb sken\u00eb q\u00eb \u00ebsht\u00eb b\u00ebr\u00eb para gabimit dhe aplikojm\u00eb ndryshimet nga arkiva WAL deri n\u00eb gabim.<\/p>\n

<\/p>\n

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

<\/p>\n

Replikimi i vonuar \u00ebsht\u00eb aplikimi i ndryshimeve nga WAL me nj\u00eb vones\u00eb. Pra, transaksioni u 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 dy m\u00ebnyra p\u00ebr t\u00eb konfigururar nj\u00eb replik\u00eb fizike t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave: rikuperimi nga arkiva dhe replikimi streaming. Rikuperimi nga arkiva<\/a><\/noindex>, n\u00eb thelb, funksionon si PITR, por n\u00eb m\u00ebnyr\u00eb t\u00eb vazhdueshme: ne p\u00ebrdit\u00eb gjejm\u00eb ndryshimet nga arkiva WAL dhe i aplikojm\u00eb ato n\u00eb replik\u00eb. Nd\u00ebrsa replikimi streaming<\/a><\/noindex> direkt nxjerr nj\u00eb rrjedh\u00eb WAL nga hosti i lart\u00eb t\u00eb baz\u00ebs s\u00eb t\u00eb dh\u00ebnave. Ne preferojm\u00eb rikuperimin nga arkiva \u2014 \u00ebsht\u00eb m\u00eb i leht\u00eb p\u00ebr menaxhim dhe ka performanc\u00eb normale q\u00eb nuk mbetet pas klasterit aktiv.<\/p>\n

<\/p>\n

Si t\u00eb konfigurojm\u00eb rikuperimin e vonuar nga arkiva<\/h3>\n

<\/p>\n

Opsionet e rikuperimit<\/a><\/noindex> jan\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 replik\u00eb t\u00eb vonuar me rikuperim nga arkiva. K\u00ebtu p\u00ebrdoret wal-e<\/a><\/noindex> p\u00ebr t\u00eb nxjerr\u00eb segmentet e WAL (restore_command<\/code>) nga arkiva, dhe ndryshimet do t\u00eb aplikohen pas tet\u00eb or\u00ebve (recovery_min_apply_delay<\/code>). Replika do t\u00eb ndjek\u00eb ndryshimet e kronologjis\u00eb n\u00eb arkiv\u00eb, p\u00ebr shembull, p\u00ebr shkak t\u00eb daljes n\u00eb klaster (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
S recovery_min_apply_delay<\/code> mund t\u00eb konfiguroni replikimin streaming me vones\u00eb, por k\u00ebtu ka disa rreziqe q\u00eb lidhen me slotet e replikimit, rikthimin e nxeht\u00eb dhe t\u00eb tjera. Arkiva WAL lejon q\u00eb k\u00ebto t\u00eb shmangen.<\/p>\n
<\/p>\n
Parametri recovery_min_apply_delay<\/code> shfaqur 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 t\u00eb menaxhimit t\u00eb rikuperimit<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) ose t\u00eb mbash segmentet WAL n\u00eb arkiv\u00eb p\u00ebr koh\u00ebn e vones\u00ebs.<\/p>\n
<\/p>\n
Si e realizon PostgreSQL k\u00ebt\u00eb?<\/h3>\n
<\/p>\n
\u00cbsht\u00eb interesante t\u00eb shohim se si PostgreSQL implementon rikuperimin 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 secil\u00ebn regjistrim 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    \/* nuk e ka \u00e7far\u00eb p\u00ebr t\u00eb b\u00ebr\u00eb n\u00ebse nuk \u00ebsht\u00eb konfiguruar asnj\u00eb vones\u00eb *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* nuk aplikohet vones\u00eb n\u00eb nj\u00eb baz\u00eb t\u00eb dh\u00ebnash q\u00eb ende nuk \u00ebsht\u00eb e konsoliduar *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * A \u00ebsht\u00eb nj\u00eb rekord COMMIT?\n     *\n     * Q\u00ebllimisht zgjidhim t\u00eb mos shqet\u00ebsojm\u00eb abortet pasi ato nuk kan\u00eb asnj\u00eb efekt n\u00eb\n     * MVCC. Ne lejojm\u00eb tashm\u00eb rivendosjen e regjistrimeve q\u00eb nuk kan\u00eb nj\u00eb timestamp,\n     * k\u00ebshtu q\u00eb tashm\u00eb ka mund\u00ebsi p\u00ebr \u00e7\u00ebshtje t\u00eb shkaktuara nga konfliktet e hershme mbi\n     * q\u00ebndrat.\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     * Dalim pa armatur\u00ebn e latch n\u00ebse \u00ebsht\u00eb kaluar tashm\u00eb koha p\u00ebr t\u00eb aplikuar k\u00ebt\u00eb\n     * rekord\n     *\/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ e shkurtuar:\n        \/\/ P\u00ebrdorim WaitLatch derisa t\u00eb arrijm\u00eb recoveryDelayUntilTime\n        \/\/ dhe pastaj\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
The main point is that the delay is based on the physical time recorded in the transaction commit timestamp (xtime<\/code>). As seen, the delay only applies to commits and does not affect other records \u2014 all changes are applied directly, while the commit is delayed, so we see changes only after the configured delay.<\/p>\n
<\/p>\n
How to use a delayed replica for data recovery<\/h3>\n
<\/p>\n
Suppose we have a production database cluster and a replica with an eight-hour delay. Let's see how to recover data using the example of random deletion of labels<\/a><\/noindex>.<\/p>\n
<\/p>\n
When we learned about the problem, we paused the recovery from the archive<\/a><\/noindex> for the delayed replica:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
With the pause, we had no risk of the replica replaying the request DELETE<\/code>. A useful thing if you need time to sort everything out.<\/p>\n
<\/p>\n
The main point is that the delayed replica needs to reach the moment before the request DELETE<\/code>. We had a rough idea of the physical time of the deletion. We deleted recovery_min_apply_delay<\/code> and added recovery_target_time<\/code> n\u00eb recovery.conf<\/code>. Thus, the replica reaches the desired moment without delays:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
With timestamps it's better to reduce the excess to avoid missing. However, the more we reduce, the more data we lose. Again, if we skip the request DELETE<\/code>, everything will be deleted again, and we'll have to start over (or take a cold backup for PITR).<\/p>\n
<\/p>\n
We restarted the delayed Postgres instance, and the WAL segments replayed up to the specified time. Tracking the progress at this stage can be done with the query:<\/p>\n
<\/p>\n
SELECT\n  -- current location in WAL\n  pg_last_xlog_replay_location(),\n  -- current transaction timestamp (state of the replica)\n  pg_last_xact_replay_timestamp(),\n  -- current physical time\n  now(),\n  -- the amount of time still to be applied until recovery_target_time has been reached\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
If the timestamp no longer changes, the recovery is complete. You can set the action recovery_target_action<\/code><\/a><\/noindex>, to close, advance, or pause the instance after replaying (by default, it is paused).<\/p>\n
<\/p>\n
The database returned to the state before that unfortunate request. Now it\u2019s possible, for example, to export data. We exported the deleted label data and all connections to tasks and merge requests and transferred them to the working database. If the losses are extensive, we can simply advance the replica and use it as primary. But then all changes after the point we recovered will be lost.<\/p>\n
<\/p>\n
Instead of timestamps, it\u2019s better to use transaction IDs. It\u2019s useful to record these IDs, for example, for DDL operators (like DROP TABLE<\/code>), using log_statements = 'ddl'<\/code>. If we had the transaction ID, we would take recovery_target_xid<\/code> and replay everything up to the transaction before the request. DELETE<\/code>.<\/p>\n
<\/p>\n
Returning to work is very easy: remove all changes from recovery.conf<\/code> and restart Postgres. Soon the replica will have the eight-hour delay again, and we are prepared for future troubles.<\/p>\n
<\/p>\n
Advantages for recovery<\/h3>\n
<\/p>\n
With the delayed replica instead of a cold backup, there's no need to spend hours recovering the entire snapshot from the archive. For us, for example, it takes five hours to extract the entire base backup of 2 TB. And then we still have to apply all the daily WAL to recover to the desired state (in the worst case).<\/p>\n
<\/p>\n
The delayed replica is better than a cold backup for two reasons:<\/p>\n
<\/p>\n
    \n
  1. No need to retrieve the entire base backup from the archive.<\/li>\n
  2. There\u2019s a fixed eight-hour window of WAL segments that need to be replayed.<\/li>\n<\/ol>\n
    <\/p>\n
    And we constantly check if it's possible to perform PITR from WAL, and we would quickly notice any corruption or other problems with the WAL archive by monitoring the delay of the delayed replica.<\/p>\n
    <\/p>\n
    In this example, it took us 50 minutes to recover, which means a speed of 110 GB of WAL data per hour (the archive was still on AWS S3<\/a><\/noindex>). Overall, we solved the problem and recovered the data in 1.5 hours.<\/p>\n
    <\/p>\n
    P\u00ebrmbledhje: ku \u00ebsht\u00eb e dobishme replikimi i vonuar (dhe ku nuk \u00ebsht\u00eb)<\/h3>\n
    <\/p>\n
    P\u00ebrdorni replikimin e vonuar si nj\u00eb mjet emergjence n\u00ebse keni humbur t\u00eb dh\u00ebna gabimisht dhe e keni v\u00ebn\u00eb re k\u00ebt\u00eb problem brenda vones\u00ebs s\u00eb vendosur.<\/p>\n
    <\/p>\n
    Por mbani mend: replikimi nuk \u00ebsht\u00eb kopje rezerv\u00eb.<\/p><\/blockquote>\n
    Kopja rezerv\u00eb dhe replikimi kan\u00eb q\u00ebllime t\u00eb ndryshme. Nj\u00eb kopje rezerv\u00eb e ftoht\u00eb \u00ebsht\u00eb e dobishme n\u00ebse keni b\u00ebr\u00eb gabimisht DELETE<\/code> ose DROP TABLE<\/code>. Ne b\u00ebjm\u00eb kopje rezerv\u00eb nga ruajtja 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> p\u00ebrhapen thuajse menj\u00ebher\u00eb n\u00eb t\u00eb gjitha replikat n\u00eb grumbullin e pun\u00ebs, ndaj replikimi i zakonsh\u00ebm nuk ndihmon k\u00ebtu. Vet\u00eb replikimi mb\u00ebshtet baz\u00ebn e t\u00eb dh\u00ebnave t\u00eb jet\u00eb e aksesueshme, kur server\u00ebt individual jan\u00eb n\u00eb pushim, dhe shp\u00ebrndan ngarkes\u00ebn.<\/p>\n
    <\/p>\n
    Edhe me replikimin e vonuar, her\u00eb pas here na nevojitet nj\u00eb kopje rezerv\u00eb e ftoht\u00eb n\u00eb nj\u00eb vend t\u00eb sigurt, n\u00ebse ndodhin ndodhi si d\u00ebshtimi i nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave, d\u00ebmtim i fshehur ose ngjarje t\u00eb tjera q\u00eb nuk duken menj\u00ebher\u00eb. K\u00ebtu, replikimi vet\u00eb nuk \u00ebsht\u00eb i mjaftuesh\u00ebm.<\/p>\n
    <\/p>\n
    Sh\u00ebnim<\/strong>. N\u00eb GitLab.com<\/a><\/noindex> ne tani po mbrojm\u00eb nga humbja e t\u00eb dh\u00ebnave vet\u00ebm n\u00eb nivelin e sistemit dhe nuk po 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 si p\u00ebrdorim replikimin e vonuar p\u00ebr rikuperimin nga fatkeq\u00ebsit\u00eb me PostgreSQL | ProHoster","description":"Replikimi \u2014 nuk \u00ebsht\u00eb nj\u00eb rezerv\u00eb. Apo jo? K\u00ebtu \u00ebsht\u00eb se si e p\u00ebrdor\u00ebm replikimin e vonuar p\u00ebr rikuperimin, pasi fshir\u00ebm p\u00ebr aksident shkurtesat. Specialist\u00ebt e infrastruktur\u00ebs n\u00eb GitLab jan\u00eb p\u00ebrgjegj\u00ebs p\u00ebr funksionimin e GitLab.com \u2014 instanc\u00ebn m\u00eb t\u00eb madhe t\u00eb GitLab n\u00eb bot\u00eb. K\u00ebtu ka 3 milion p\u00ebrdorues dhe gati 7 milion projekte, dhe kjo \u00ebsht\u00eb nj\u00eb nga faqet m\u00eb t\u00eb m\u00ebdha SaaS me burim t\u00eb hapur me arkitektur\u00eb t\u00eb dedikuar. Pa nj\u00eb sistem","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":"\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\/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}]}}