{"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\/sv\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","title":{"rendered":"Hur vi anv\u00e4nde f\u00f6rdr\u00f6jd replikering f\u00f6r katastrof\u00e5terst\u00e4llning med PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hur
\nReplikering \u00e4r inte en s\u00e4kerhetskopia. Eller \u00e4r den det? S\u00e5 h\u00e4r anv\u00e4nde vi f\u00f6rdr\u00f6jd replikering f\u00f6r att \u00e5terst\u00e4lla, efter att ha raderat etiketter av misstag.<\/p>\n

<\/p>\n

Infrastruktur-specialister<\/a><\/noindex> p\u00e5 GitLab ansvarar f\u00f6r driften GitLab.com<\/a><\/noindex> \u2013 den st\u00f6rsta GitLab-instansen i naturen. H\u00e4r finns 3 miljoner anv\u00e4ndare och n\u00e4stan 7 miljoner projekt, och det \u00e4r en av de st\u00f6rsta open source SaaS-webbplatserna med en dedikerad arkitektur. Utan PostgreSQL-databassystem kommer GitLab.com inte l\u00e5ngt, och vi g\u00f6r vad vi kan f\u00f6r att s\u00e4kerst\u00e4lla motst\u00e5ndskraft mot eventuella fel d\u00e4r data kan g\u00e5 f\u00f6rlorade. S\u00e5dan katastrof \u00e4r osannolik, men vi \u00e4r v\u00e4l f\u00f6rberedda och har olika backup- och replikeringstekniker i beredskap.<\/p>\n

<\/p>\n

Replikering \u00e4r inte en l\u00f6sning f\u00f6r databasbackup (se nedan<\/a><\/noindex>). Men nu ska vi se hur snabbt vi kan \u00e5terst\u00e4lla av misstag raderade data med hj\u00e4lp av f\u00f6rdr\u00f6jd replikering: n\u00e4r en GitLab.com<\/a><\/noindex> anv\u00e4ndare raderade en etikett<\/a><\/noindex> f\u00f6r projektet gitlab-ce<\/code><\/a><\/noindex> och f\u00f6rlorade kopplingen till merge-f\u00f6rfr\u00e5gningar och uppgifter.<\/p>\n

<\/p>\n

Med den f\u00f6rdr\u00f6jda replikationen \u00e5terst\u00e4llde vi data p\u00e5 bara 1,5 timmar. Se hur det gick till.<\/p>\n

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

\u00c5terst\u00e4llning till en specifik tid med PostgreSQL<\/h3>\n

<\/p>\n

PostgreSQL har en inbyggd funktion f\u00f6r att \u00e5terst\u00e4lla databasens tillst\u00e5nd till en viss tidpunkt. Det kallas Point-in-Time Recovery<\/a><\/noindex> (PITR) och anv\u00e4nder samma mekanismer som h\u00e5ller replikationen aktuell: utifr\u00e5n en p\u00e5litlig \u00f6gonblicksbild av hela databasens kluster (grundbackup) till\u00e4mpar vi en serie tillst\u00e5nds\u00e4ndringar fram till en viss tidpunkt.<\/p>\n

<\/p>\n

F\u00f6r att anv\u00e4nda denna funktion f\u00f6r kall backup g\u00f6r vi regelbundet en grundbackup av databasen och sparar den i ett arkiv (GitLabs arkiv finns i Google Cloud Storage<\/a><\/noindex>). Vi \u00f6vervakar ocks\u00e5 f\u00f6r\u00e4ndringar av databasens tillst\u00e5nd genom att arkivera loggen f\u00f6r f\u00f6rhandsinspelning (write-ahead log<\/a><\/noindex>, WAL). Med allt detta kan vi utf\u00f6ra PITR f\u00f6r katastrof\u00e5terst\u00e4llning: vi b\u00f6rjar med en \u00f6gonblicksbild som togs f\u00f6re felet och till\u00e4mpar f\u00f6r\u00e4ndringar fr\u00e5n WAL-arkivet fram till kraschen.<\/p>\n

<\/p>\n

Vad \u00e4r f\u00f6rdr\u00f6jd replikering?<\/h3>\n

<\/p>\n

F\u00f6rdr\u00f6jd replikering \u00e4r till\u00e4mpningen av \u00e4ndringar fr\u00e5n WAL med en f\u00f6rdr\u00f6jning. Det vill s\u00e4ga transaktionen intr\u00e4ffade vid tidpunkt X<\/code>, men i replikatet kommer den att visas med en f\u00f6rdr\u00f6jning d<\/code> vid tidpunkt X + d<\/code>.<\/p>\n

<\/p>\n

I PostgreSQL finns det 2 s\u00e4tt att konfigurera en fysisk databasreplik: \u00e5terst\u00e4llning fr\u00e5n arkiv och str\u00f6mreplikering. \u00c5terst\u00e4llning fr\u00e5n arkiv<\/a><\/noindex>, fungerar i grunden som PITR, men kontinuerligt: vi extraherar st\u00e4ndigt \u00e4ndringar fr\u00e5n WAL-arkivet och till\u00e4mpar dem p\u00e5 repliket. Och str\u00f6mreplikering<\/a><\/noindex> extraherar direkt WAL-str\u00f6mmen fr\u00e5n den \u00f6verordnade databashostens. Vi f\u00f6redrar \u00e5terst\u00e4llning fr\u00e5n arkiv - det \u00e4r enklare att hantera och har en normal prestation som inte ligger efter den aktiva klustern.<\/p>\n

<\/p>\n

Hur man konfigurerar f\u00f6rdr\u00f6jd \u00e5terst\u00e4llning fr\u00e5n arkiv<\/h3>\n

<\/p>\n

\u00c5terst\u00e4llningsalternativ<\/a><\/noindex> beskrivs i filen recovery.conf<\/code>. Exempel:<\/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
Med dessa inst\u00e4llningar har vi konfigurerat en f\u00f6rdr\u00f6jd replik med \u00e5terst\u00e4llning fr\u00e5n arkiv. H\u00e4r anv\u00e4nds wal-e<\/a><\/noindex> f\u00f6r att extrahera WAL-segment (restore_command<\/code>) fr\u00e5n arkivet, och \u00e4ndringarna kommer att till\u00e4mpas efter \u00e5tta timmar (recovery_min_apply_delay<\/code>). Repliket kommer att \u00f6vervaka tidslinjens \u00e4ndringar i arkivet, till exempel p\u00e5 grund av ett fel\u00f6verg\u00e5ng i klustret (recovery_target_timeline<\/code>).<\/p>\n
<\/p>\n
Med recovery_min_apply_delay<\/code> kan man konfigurera str\u00f6mreplikering med f\u00f6rdr\u00f6jning, men h\u00e4r finns ett par f\u00e4llor kopplade till replikationsslotten, \u00e5terkopplingen av het reserv och liknande. WAL-arkiv m\u00f6jligg\u00f6r att undvika dem.<\/p>\n
<\/p>\n
Parameter recovery_min_apply_delay<\/code> kom endast i PostgreSQL 9.3. I tidigare versioner var det n\u00f6dv\u00e4ndigt att konfigurera en kombination av \u00e5terst\u00e4llningshanteringsfunktioner<\/a><\/noindex> (pg_xlog_replay_pause(), pg_xlog_replay_resume()<\/code>) eller att h\u00e5lla WAL-segment i arkivet under f\u00f6rdr\u00f6jningstiden.<\/p>\n
<\/p>\n
Hur g\u00f6r PostgreSQL detta?<\/h3>\n
<\/p>\n
Det \u00e4r intressant att se hur PostgreSQL implementerar f\u00f6rdr\u00f6jd \u00e5terst\u00e4llning. L\u00e5t oss titta p\u00e5 recoveryApplyDelay(XlogReaderState)<\/code><\/a><\/noindex>. Den kallas fr\u00e5n huvud\u00e5terspelningscykeln<\/a><\/noindex> f\u00f6r varje post fr\u00e5n 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    \/* inget inget om ingen f\u00f6rdr\u00f6jning konfigurerad *\/\n    if (recovery_min_apply_delay <= 0)\n        return false;\n\n    \/* ingen f\u00f6rdr\u00f6jning till\u00e4mpas p\u00e5 en databas som inte \u00e4nnu \u00e4r konsekvent *\/\n    if (!reachedConsistency)\n        return false;\n\n    \/**\n     * \u00c4r det en COMMIT-post?\n     *\n     * Vi v\u00e4ljer medvetet att inte f\u00f6rdr\u00f6ja aborter eftersom de inte har n\u00e5gon effekt p\u00e5\n     * MVCC. Vi till\u00e5ter redan uppspelning av poster som inte har en tidsst\u00e4mpel,\n     * s\u00e5 det finns redan m\u00f6jlighet f\u00f6r problem orsakade av tidiga konflikter p\u00e5\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     * Avsluta utan att aktivera latch om det redan har passerat tid att till\u00e4mpa denna\n     * post\n     *\/\n    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,\n                        &secs, &microsecs);\n    if (secs <= 0 && microsecs <= 0)\n        return false;\n\n    while (true)\n    {\n        \/\/ F\u00f6rkortat:\n        \/\/ Anv\u00e4nd WaitLatch tills vi n\u00e5r recoveryDelayUntilTime\n        \/\/ och sedan\n        break;\n    }\n    return true;\n}<\/code><\/pre>\n
<\/p>\n
Po\u00e4ngen \u00e4r att f\u00f6rdr\u00f6jningen baseras p\u00e5 den fysiska tiden som finns i tidsst\u00e4mpeln f\u00f6r transaktionskommitt\u00e9n (xtime<\/code>). Som framg\u00e5r till\u00e4mpas f\u00f6rdr\u00f6jningen endast p\u00e5 kommitt\u00e9er och ber\u00f6r inte andra poster - alla \u00e4ndringar till\u00e4mpas direkt, medan kommitt\u00e9n f\u00f6rdr\u00f6js, s\u00e5 vi kommer att se \u00e4ndringarna f\u00f6rst efter den inst\u00e4llda f\u00f6rdr\u00f6jningen.<\/p>\n
<\/p>\n
Hur man anv\u00e4nder en f\u00f6rdr\u00f6jd replik f\u00f6r datagenerering<\/h3>\n
<\/p>\n
Anta att vi har en databas i produktion och en replik med \u00e5tta timmars f\u00f6rdr\u00f6jning. L\u00e5t oss se hur vi kan \u00e5terst\u00e4lla data med exemplet slumparbete borttagning av etiketter<\/a><\/noindex>.<\/p>\n
<\/p>\n
N\u00e4r vi fick veta problemet stannade vi \u00e5terst\u00e4llningen fr\u00e5n arkivet<\/a><\/noindex> f\u00f6r den f\u00f6rdr\u00f6jda replikationen:<\/p>\n
<\/p>\n
SELECT pg_xlog_replay_pause();<\/code><\/pre>\n
<\/p>\n
Med en paus riskerade vi inte att replikationen upprepade f\u00f6rfr\u00e5gan. TA BORT<\/code>En anv\u00e4ndbar sak att ha tid p\u00e5 oss att l\u00f6sa allt.<\/p>\n
<\/p>\n
Huvudpo\u00e4ngen \u00e4r att den f\u00f6rdr\u00f6jda replikationen m\u00e5ste n\u00e5 fram till punkt innan f\u00f6rfr\u00e5gan. TA BORT<\/code>Vi visste ungef\u00e4r den fysiska tiden f\u00f6r borttagningen. Vi tog bort recovery_min_apply_delay<\/code> och lade till recovery_target_time<\/code> p\u00e5 recovery.conf<\/code>. P\u00e5 s\u00e5 s\u00e4tt n\u00e5r replikeringen den \u00f6nskade tidspunkten utan f\u00f6rdr\u00f6jningar:<\/p>\n
<\/p>\n
recovery_target_time = '2018-10-12 09:25:00+00'<\/code><\/pre>\n
<\/p>\n
Med tidsst\u00e4mplar \u00e4r det b\u00e4st att dra av lite extra s\u00e5 att vi inte missar. Sanningen \u00e4r att ju mer vi drar av, desto mer data g\u00e5r f\u00f6rlorat. \u00c5terigen, om vi missar f\u00f6rfr\u00e5gan, TA BORT<\/code>, allt tas bort igen och vi f\u00e5r b\u00f6rja om (eller till och med ta en kall backup f\u00f6r PITR).<\/p>\n
<\/p>\n
Vi har startat om den avbrutna instansen av Postgres och WAL-segmenten upprepades fram till den angivna tiden. Du kan sp\u00e5ra framg\u00e5ngen i detta skede med f\u00f6ljande fr\u00e5ga:<\/p>\n
<\/p>\n
SELECT\n  -- nuvarande plats i WAL\n  pg_last_xlog_replay_location(),\n  -- nuvarande tidsst\u00e4mpel f\u00f6r transaktionen (status f\u00f6r replikatet)\n  pg_last_xact_replay_timestamp(),\n  -- nuvarande fysiska tid\n  now(),\n  -- m\u00e4ngden tid som fortfarande m\u00e5ste till\u00e4mpas tills recovery_target_time har uppn\u00e5tts\n  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;<\/code><\/pre>\n
<\/p>\n
Om tidsst\u00e4mpeln inte l\u00e4ngre \u00e4ndras \u00e4r \u00e5terst\u00e4llningen slutf\u00f6rd. Du kan konfigurera \u00e5tg\u00e4rden recovery_target_action<\/code><\/a><\/noindex>, f\u00f6r att st\u00e4nga, flytta fram eller pausa instansen efter upprepningen (som standard pausas den).<\/p>\n
<\/p>\n
Databasen har \u00e5terg\u00e5tt till tillst\u00e5ndet f\u00f6re den olyckliga f\u00f6rfr\u00e5gan. Nu kan du till exempel exportera data. Vi exporterade de borttagna data om etiketten och alla relationer med uppgifter och merge-f\u00f6rfr\u00e5gningar och flyttade dem till produktionsdatabasen. Om f\u00f6rlusterna \u00e4r omfattande kan man bara flytta fram replikatet och anv\u00e4nda det som grunddata. Men d\u00e5 kommer alla \u00e4ndringar efter den tidpunkt vi \u00e5terst\u00e4llde att g\u00e5 f\u00f6rlorade.<\/p>\n
<\/p>\n
Ist\u00e4llet f\u00f6r tidsst\u00e4mplar \u00e4r det b\u00e4ttre att anv\u00e4nda transaktions-ID. Det \u00e4r bra att registrera dessa ID, till exempel f\u00f6r DDL-operat\u00f6rer (typ DROP TABLE<\/code>), med hj\u00e4lp av log_statements = 'ddl'<\/code>. Om vi hade haft ett transaktions-ID skulle vi ha tagit recovery_target_xid<\/code> och k\u00f6rt allt fram till transaktionen f\u00f6re f\u00f6rfr\u00e5gan. TA BORT<\/code>.<\/p>\n
<\/p>\n
Att \u00e5terg\u00e5 till arbetet \u00e4r v\u00e4ldigt enkelt: ta bort alla \u00e4ndringar fr\u00e5n recovery.conf<\/code> och starta om Postgres. Snart kommer det igen att finnas en \u00e5ttatimmarsf\u00f6rdr\u00f6jning i replikatet, och vi \u00e4r redo f\u00f6r framtida problem.<\/p>\n
<\/p>\n
F\u00f6rdelar med \u00e5terst\u00e4llning<\/h3>\n
<\/p>\n
Med en f\u00f6rdr\u00f6jd replik beh\u00f6ver man inte \u00e5terst\u00e4lla hela bilden fr\u00e5n arkivet i timmar. Vi beh\u00f6ver till exempel fem timmar f\u00f6r att h\u00e4mta hela grundbackupen p\u00e5 2 TB. Och sen m\u00e5ste vi dessutom till\u00e4mpa hela den dagliga WAL:n f\u00f6r att \u00e5terst\u00e4lla till \u00f6nskat tillst\u00e5nd (i v\u00e4rsta fall).<\/p>\n
<\/p>\n
En f\u00f6rdr\u00f6jd replik \u00e4r b\u00e4ttre \u00e4n en kall backup p\u00e5 tv\u00e5 punkter:<\/p>\n
<\/p>\n
    \n
  1. Det finns inget behov av att h\u00e4mta hela grundbackupen fr\u00e5n arkivet.<\/li>\n
  2. Det finns ett fast \u00e5ttatimmarsf\u00f6nster f\u00f6r WAL-segment som m\u00e5ste upprepas.<\/li>\n<\/ol>\n
    <\/p>\n
    Dessutom kontrollerar vi kontinuerligt om det g\u00e5r att g\u00f6ra PITR fr\u00e5n WAL, och vi skulle snabbt m\u00e4rka skador eller andra problem med WAL-arkivet genom att \u00f6vervaka f\u00f6rdr\u00f6jningen i replikatet.<\/p>\n
    <\/p>\n
    I det h\u00e4r exemplet tog det oss 50 minuter att \u00e5terst\u00e4lla, vilket inneb\u00e4r att hastigheten var 110 GB WAL-data per timme (arkivet var fortfarande p\u00e5 AWS S3<\/a><\/noindex>). Totalt l\u00f6ste vi problemet och \u00e5terst\u00e4llde data p\u00e5 1,5 timmar.<\/p>\n
    <\/p>\n
    Sammanfattning: var avsatt replikation \u00e4r anv\u00e4ndbar (och var den inte \u00e4r det)<\/h3>\n
    <\/p>\n
    Anv\u00e4nd avsatt replikation som en f\u00f6rsta hj\u00e4lpen-l\u00f6sning om du oavsiktligt har f\u00f6rlorat data och m\u00e4rkt detta inom den inst\u00e4llda f\u00f6rdr\u00f6jningen.<\/p>\n
    <\/p>\n
    Men kom ih\u00e5g: replikation \u00e4r ingen s\u00e4kerhetskopia.<\/p><\/blockquote>\n
    S\u00e4kerhetskopiering och replikation har olika syften. En kall s\u00e4kerhetskopia \u00e4r anv\u00e4ndbar om du oavsiktligt har gjort TA BORT<\/code> eller DROP TABLE<\/code>. Vi g\u00f6r en s\u00e4kerhetskopia fr\u00e5n det kalla lagret och \u00e5terst\u00e4ller det tidigare tillst\u00e5ndet f\u00f6r tabellen eller hela databasen. Men under tiden fr\u00e5gan DROP TABLE<\/code> \u00e5terskapas n\u00e4stan omedelbart i alla repliker p\u00e5 arbetsklustret, s\u00e5 vanlig replikation hj\u00e4lper inte h\u00e4r. Sj\u00e4lva replikationen h\u00e5ller databasen tillg\u00e4nglig n\u00e4r vissa servrar g\u00e5r ner och f\u00f6rdelar belastningen.<\/p>\n
    <\/p>\n
    \u00c4ven med avsatt replikation beh\u00f6ver vi ibland en kall s\u00e4kerhetskopia p\u00e5 en s\u00e4ker plats om vi pl\u00f6tsligt skulle f\u00e5 problem i datacentret, dolda skador eller andra h\u00e4ndelser som inte m\u00e4rks direkt. H\u00e4r \u00e4r det ingen nytta av enbart replikation.<\/p>\n
    <\/p>\n
    Anm\u00e4rkning<\/strong>. Vid GitLab.com<\/a><\/noindex> skyddar vi just nu endast p\u00e5 systemniv\u00e5 mot dataf\u00f6rlust och \u00e5terst\u00e4ller inte data p\u00e5 anv\u00e4ndarniv\u00e5.<\/p>\n
    K\u00e4lla: 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\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\udd47Hur vi anv\u00e4nde avsatt replikation f\u00f6r n\u00f6ddatabaserings\u00e5terst\u00e4llning med PostgreSQL | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-my-ispolzovali-otlozhennuyu-replikatsiyu-dlya-avarijnogo-vosstanovleniya-s-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/30356","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=30356"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/30356\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/22360"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=30356"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=30356"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=30356"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}