{"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\/it\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Come abbiamo utilizzato la replica latente per il ripristino di emergenza con PostgreSQL.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\nLa replica non \u00e8 un backup. O no? Ecco come abbiamo utilizzato la replica ritardata per il ripristino, dopo aver eliminato accidentalmente i collegamenti.<\/p>\n

<\/p>\n

Esperti di infrastruttura<\/a><\/noindex> su GitLab sono responsabili del funzionamento GitLab.com<\/a><\/noindex> \u2014 del pi\u00f9 grande esemplare di GitLab esistente. Qui ci sono 3 milioni di utenti e quasi 7 milioni di progetti, ed \u00e8 uno dei pi\u00f9 grandi siti open source SaaS con architettura dedicata. Senza PostgreSQL, l'infrastruttura di GitLab.com non andrebbe molto lontano, e facciamo di tutto per garantire la resilienza in caso di guasti, quando potrebbero verificarsi perdite di dati. \u00c8 improbabile che un disastro del genere accada, ma ci siamo preparati bene e abbiamo vari meccanismi di backup e replica.<\/p>\n

<\/p>\n

La replica non \u00e8 un mezzo per il backup dei database (vedi sotto<\/a><\/noindex>). Ma ora vedremo quanto sia facile ripristinare dati eliminati accidentalmente utilizzando la replica ritardata: ho GitLab.com<\/a><\/noindex> utente eliminato il collegamento<\/a><\/noindex> per il progetto gitlab-ce<\/code><\/a><\/noindex> e ho perso i collegamenti con le richieste di fusione e le attivit\u00e0.<\/p>\n

<\/p>\n

Con la replica tardiva, abbiamo ripristinato i dati in sole 1,5 ore. Guarda come \u00e8 stato.<\/p>\n

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

Ripristino a un momento preciso con PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL dispone di una funzione integrata che ripristina lo stato del database a un determinato momento. Si chiama Ripristino a un punto nel tempo<\/a><\/noindex> (PITR) e utilizza gli stessi meccanismi che mantengono la replica aggiornata: partendo da un'immagine affidabile dell'intero cluster di database (backup di base), applichiamo una serie di modifiche di stato fino a un certo momento.<\/p>\n

<\/p>\n

Per utilizzare questa funzione per un backup a freddo, eseguiamo regolarmente un backup di base del database e lo conserviamo in archivio (gli archivi di GitLab vivono in Google Cloud Storage<\/a><\/noindex>). Inoltre, monitoriamo le modifiche allo stato del database archiviate nel log delle scritture anticipate (write-ahead log<\/a><\/noindex>, WAL). Con tutto questo, possiamo eseguire il PITR per il ripristino di emergenza: iniziamo con l'immagine scattata prima dell'errore e applichiamo le modifiche dall'archivio WAL fino al guasto.<\/p>\n

<\/p>\n

Che cos'\u00e8 la replica ritardata?<\/h3>\n

<\/p>\n

La replica ritardata \u00e8 l'applicazione delle modifiche dal WAL con un ritardo. In altre parole, la transazione \u00e8 avvenuta un'ora X<\/code>, ma nella replica apparir\u00e0 con un ritardo d<\/code> di un'ora X + d<\/code>.<\/p>\n

<\/p>\n

In PostgreSQL ci sono 2 modi per configurare una replica fisica del database: il ripristino da archivio e la replica streaming. Ripristino da archivio<\/a><\/noindex>, essenzialmente funziona come PITR, ma in modo continuo: estraiamo costantemente le modifiche dall'archivio WAL e le applichiamo alla replica. A replica streaming<\/a><\/noindex> estrae direttamente il flusso WAL dall'host del database superiore. Preferiamo il ripristino da archivio: \u00e8 pi\u00f9 facile da gestire e offre prestazioni normali che non sono inferiori a quelle del cluster attivo.<\/p>\n

<\/p>\n

Come configurare il ripristino ritardato da archivio<\/h3>\n

<\/p>\n

Le opzioni di ripristino<\/a><\/noindex> sono descritte nel file recovery.conf<\/code>. Esempio:<\/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
Con queste impostazioni abbiamo configurato una replica ritardata con ripristino da archivio. Qui si utilizza wal-e<\/a><\/noindex> per estrarre i segmenti WAL (restore_command<\/code>) dall'archivio, e le modifiche saranno applicate dopo otto ore (recovery_min_apply_delay<\/code>). La replica seguir\u00e0 le modifiche nella timeline dell'archivio, ad esempio, a causa di un failover nel cluster (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
C recovery_min_apply_delay<\/code> \u00e8 possibile configurare la replica streaming con un ritardo, ma ci sono alcuni inconvenienti legati agli slot di replica, al feedback del backup attivo, e altro. L'archivio WAL permette di evitarli.<\/p>\n
<\/p>\n
Caratteristica recovery_min_apply_delay<\/code> \u00e8 stato introdotto solo in PostgreSQL 9.3. Nelle versioni precedenti, per la replica ritardata, \u00e8 necessario configurare una combinazione di funzioni di gestione del ripristino<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) o mantenere i segmenti WAL in archivio durante il periodo di ritardo.<\/p>\n
<\/p>\n
Come fa PostgreSQL a farlo?<\/h3>\n
<\/p>\n
\u00c8 interessante vedere come PostgreSQL implementa il ripristino ritardato. Diamo un'occhiata a recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Viene chiamato dal ciclo principale di ripetizione<\/a><\/noindex> per ogni record del 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    \/* non c'\u00e8 nulla da fare se non \u00e8 configurato alcun ritardo *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* non viene applicato alcun ritardo su un database non ancora consistente *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/*\n     * \u00c8 un record di COMMIT?\n     *\n     * Scegliamo deliberatamente di non ritardare gli aborti poich\u00e9 non hanno effetto su\n     * MVCC. Consentiamo gi\u00e0 la riproduzione di record che non hanno un timestamp,\n     * quindi ci sono gi\u00e0 opportunit\u00e0 per problemi causati da conflitti precoci su\n     * standby.\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     * Esci senza armare la serratura se \u00e8 gi\u00e0 passato il tempo per applicare questo\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        \/\/ Accorciato:\n        \/\/ Usa WaitLatch fino a raggiungere recoveryDelayUntilTime\n        \/\/ e poi\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
La questione \u00e8 che il ritardo \u00e8 basato sul tempo fisico, registrato nel timestamp del commit della transazione (xtime<\/code>). Come si pu\u00f2 vedere, il ritardo si applica solo ai commit e non tocca altre registrazioni: tutte le modifiche vengono applicate direttamente, mentre il commit viene posticipato, quindi vedremo le modifiche solo dopo il ritardo impostato.<\/p>\n
<\/p>\n
Come usare una replica ritardata per il ripristino dei dati<\/h3>\n
<\/p>\n
Supponiamo di avere un cluster di database in produzione e una replica con un ritardo di otto ore. Vediamo come ripristinare i dati utilizzando l'esempio di una cancellazione accidentale di collegamenti<\/a><\/noindex>.<\/p>\n
<\/p>\n
Quando siamo venuti a conoscenza del problema, abbiamo sospeso il ripristino dall'archivio<\/a><\/noindex> per la replica ritardata:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Con la pausa non c'era rischio che la replica ripetesse la query DELETE<\/code>. Utile, se abbiamo bisogno di tempo per capire tutto.<\/p>\n
<\/p>\n
La questione \u00e8 che la replica ritardata deve arrivare al momento prima della query DELETE<\/code>. Sapevamo pi\u00f9 o meno l'orario esatto della cancellazione. Abbiamo eliminato recovery_min_apply_delay<\/code> e aggiunto recovery_target_time<\/code> in recovery.conf<\/code>. Cos\u00ec la replica arriva al momento desiderato senza ritardi:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Con i timestamp \u00e8 meglio togliere il superfluo per non sbagliare. Ovviamente, quanto pi\u00f9 togliamo, tanto pi\u00f9 dati perdiamo. Ancora una volta, se saltiamo la query DELETE<\/code>, tutto verr\u00e0 nuovamente cancellato e sar\u00e0 necessario ricominciare da capo (o prendere un backup a freddo per il PITR).<\/p>\n
<\/p>\n
Abbiamo riavviato l'istanza posticipata di Postgres e i segmenti WAL sono stati ripetuti fino al tempo specificato. \u00c8 possibile monitorare i progressi a questo stadio eseguendo la seguente query:<\/p>\n
<\/p>\n
SELECT\n  -- posizione attuale in WAL\n  pg_last_xlog_replay_location(),\n  -- timestamp della transazione attuale (stato della replica)\n  pg_last_xact_replay_timestamp(),\n  -- ora fisica attuale\n  now(),\n  -- quantit\u00e0 di tempo che deve ancora essere applicata fino al raggiungimento di recovery_target_time\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Se il timestamp non cambia pi\u00f9, il recupero \u00e8 completato. \u00c8 possibile configurare l'azione recovery_target_action<\/code><\/a><\/noindex>, per chiudere, avanzare o sospendere l'istanza dopo la riproduzione (di default viene sospesa).<\/p>\n
<\/p>\n
Il database \u00e8 tornato allo stato prima di quella sfortunata query. Ora \u00e8 possibile, ad esempio, esportare i dati. Abbiamo esportato i dati eliminati relativi ai collegamenti e tutte le associazioni con le attivit\u00e0 e le merge request e li abbiamo trasferiti nel database di lavoro. Se le perdite sono massicce, \u00e8 possibile semplicemente avanzare la replica e utilizzarla come principale. Ma in tal caso si perderanno tutte le modifiche apportate dopo il momento fino al quale siamo stati in grado di recuperare.<\/p>\n
<\/p>\n
\u00c8 meglio utilizzare gli ID delle transazioni invece dei timestamp. \u00c8 utile annotare questi ID, ad esempio, per gli operatori DDL (di tipo DROP TABLE<\/code>), utilizzando log_statements = 'ddl'<\/code>. Se avessimo avuto l'ID della transazione, avremmo preso recovery_target_xid<\/code> e saremmo tornati a tutto fino alla transazione prima della richiesta DELETE<\/code>.<\/p>\n
<\/p>\n
Riprendere a lavorare \u00e8 molto semplice: rimuovi tutte le modifiche da recovery.conf<\/code> e riavvia Postgres. Presto si ripresenter\u00e0 un ritardo di otto ore nella replica, e saremo pronti per future problematiche.<\/p>\n
<\/p>\n
Vantaggi del ripristino<\/h3>\n
<\/p>\n
Con la replica ritardata, invece di un backup freddo, non \u00e8 necessario ripristinare l'intero snapshot dall'archivio in ore. Noi, ad esempio, impieghiamo cinque ore per recuperare l'intero backup di base da 2 TB. E poi bisogna applicare tutto il WAL giornaliero per ripristinare allo stato desiderato (nel peggiore dei casi).<\/p>\n
<\/p>\n
La replica ritardata \u00e8 superiore al backup freddo per due motivi:<\/p>\n
<\/p>\n
    \n
  1. Non \u00e8 necessario recuperare l'intero backup di base dall'archivio.<\/li>\n
  2. C'\u00e8 una finestra di otto ore fissa di segmenti WAL da ripetere.<\/li>\n<\/ol>\n
    <\/p>\n
    Inoltre, controlliamo costantemente se possiamo eseguire PITR dal WAL, e ci accorgeremmo rapidamente di eventuali danni o altri problemi con l'archivio WAL, monitorando il ritardo della replica ritardata.<\/p>\n
    <\/p>\n
    In questo esempio abbiamo impiegato 50 minuti per il ripristino, il che significa che la velocit\u00e0 era di 110 GB di dati WAL all'ora (l'archivio era ancora su AWS S3<\/a><\/noindex>). In totale, abbiamo risolto il problema e ripristinato i dati in 1,5 ore.<\/p>\n
    <\/p>\n
    Conclusioni: dove pu\u00f2 essere utile la replica ritardata (e dove no)<\/h3>\n
    <\/p>\n
    Utilizzate la replica ritardata come un primo soccorso se avete accidentalmente perso dei dati e vi siete accorti del problema entro il limite di ritardo impostato.<\/p>\n
    <\/p>\n
    Ma tenete presente: la replica non \u00e8 un backup.<\/p><\/blockquote>\n
    Backup e replica hanno obiettivi differenti. Un backup a freddo \u00e8 utile se avete accidentalmente creato DELETE<\/code> o DROP TABLE<\/code>. Effettuiamo il backup dallo storage a freddo e ripristiniamo lo stato precedente della tabella o dell'intero database. Tuttavia, la richiesta DROP TABLE<\/code> viene riprodotta quasi istantaneamente su tutte le repliche nel cluster operativo, quindi la normale replica non aiuter\u00e0 in questo caso. La replica stessa rende il database accessibile quando cadono singoli server e distribuisce il carico.<\/p>\n
    <\/p>\n
    Anche con una replica ritardata, a volte abbiamo davvero bisogno di un backup a freddo in un luogo sicuro, nel caso in cui si verifichi un guasto del data center, un danneggiamento nascosto o altri eventi che non vengono notati immediatamente. In questo caso, la sola replica non \u00e8 sufficiente.<\/p>\n
    <\/p>\n
    Nota<\/strong>. Su GitLab.com<\/a><\/noindex> Al momento proteggiamo i dati solo a livello di sistema e non recuperiamo i dati a livello utente.<\/p>\n
    Fonte: 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\udd47 Come abbiamo utilizzato la replicazione differita per il ripristino di emergenza con PostgreSQL | ProHoster","description":"La replicazione non \u00e8 un backup. O forse s\u00ec? Ecco come abbiamo utilizzato la replicazione differita per il ripristino dopo aver eliminato accidentalmente i collegamenti. Gli specialisti dell'infrastruttura su GitLab sono responsabili del funzionamento di GitLab.com, il pi\u00f9 grande esempio di GitLab esistente. Qui ci sono 3 milioni di utenti e quasi 7 milioni di progetti, ed \u00e8 uno dei pi\u00f9 grandi siti open source SaaS con un'architettura dedicata. Senza sistema.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}