Како ја користевме Lazy Replication за враќање од катастрофи со PostgreSQL

Репликацијата не е резервна копија. Или не? Еве како користевме одложена репликација за да се опоравиме од случајно бришење кратенки.

Специјалисти за инфраструктура GitLab е одговорен за работата GitLab.com - најголемиот примерок на GitLab во природата. Со 3 милиони корисници и речиси 7 милиони проекти, таа е една од најголемите локации на SaaS со отворен код со посветена архитектура. Без системот на база на податоци PostgreSQL, инфраструктурата GitLab.com нема да оди далеку и што правиме за да обезбедиме толеранција на грешки во случај на какви било дефекти кога податоците може да се изгубат. Малку е веројатно дека ќе се случи таква катастрофа, но ние сме добро подготвени и снабдени со различни механизми за резервна копија и репликација.

Репликацијата не е средство за резервна копија на базите на податоци (Види подолу). Но, сега ќе видиме како брзо да ги вратиме случајно избришаните податоци користејќи мрзлива репликација: вклучено GitLab.com корисникот ја избриша кратенката за проектот gitlab-ce и изгубени врски со барања и задачи за спојување.

Со одложена реплика, ги вративме податоците за само 1,5 часа. Погледнете како се случи.

Наведете го времето за обновување со PostgreSQL

PostgreSQL има вградена функција која ја враќа состојбата на базата на податоци до одредена временска точка. Тоа се нарекува Точка-во-време за наплата (PITR) и ги користи истите механизми кои ја одржуваат репликата ажурирана: почнувајќи со сигурна слика на целиот кластер на базата на податоци (база резервна копија), применуваме серија промени на состојбите до одреден временски период.

За да ја користиме оваа функција за ладна резервна копија, ние редовно правиме основна резервна копија на базата на податоци и ја складираме во архива (архивите на GitLab живеат во Облак складирање на Google). Ние, исто така, ги следиме промените во состојбата на базата на податоци со архивирање на дневникот за однапред запишување (дневник за однапред запишување, ВОЛ). И со сето ова на место, можеме да направиме PITR за враќање од катастрофи: почнувајќи од снимката направена пред неуспехот и примена на промените од архивата WAL до неуспехот.

Што е одложена репликација?

Мрзлива репликација е примена на промени од WAL со задоцнување. Тоа е, трансакцијата се случи за еден час X, но ќе се појави во репликата со задоцнување d за еден час X + d.

PostgreSQL има 2 начини за поставување на реплика на физичка база на податоци: враќање на резервната копија и репликација на стриминг. Враќање од архива, во суштина работи како PITR, но континуирано: постојано ги враќаме промените од архивата WAL и ги применуваме на репликата. А стриминг репликација директно го превзема WAL потокот од домаќинот на базата на податоци нагоре. Претпочитаме обновување на архивите - полесно е да се управува и има нормални перформанси што се во чекор со производниот кластер.

Како да поставите одложено обновување од архива

Опции за обновување опишано во датотеката recovery.conf... Пример:

standby_mode = 'on'
restore_command = '/usr/bin/envdir /etc/wal-e.d/env /opt/wal-e/bin/wal-e wal-fetch -p 4 "%f" "%p"'
recovery_min_apply_delay = '8h'
recovery_target_timeline = 'latest'

Со овие параметри, конфигуриравме одложена реплика со враќање на резервната копија. Тука се користи вал-е да се извлечат WAL сегменти (restore_command) од архивата, а промените ќе се применат по осум часа (recovery_min_apply_delay). Репликата ќе ги следи промените на временската линија во архивата, на пример поради дефект на кластерот (recovery_target_timeline).

С recovery_min_apply_delay Можете да поставите репликација на стриминг со задоцнување, но тука има неколку замки кои се поврзани со слотови за репликација, жешки повратни информации во режим на подготвеност и така натаму. Архивата WAL ви овозможува да ги избегнете.

Параметар recovery_min_apply_delay се појави само во PostgreSQL 9.3. Во претходните верзии, за одложена репликација треба да ја конфигурирате комбинацијата функции за управување со обновување (pg_xlog_replay_pause(), pg_xlog_replay_resume()) или држете ги сегментите на WAL во архива додека трае доцнењето.

Како PostgreSQL го прави ова?

Интересно е да се види како PostgreSQL имплементира мрзливо закрепнување. Ајде да погледнеме recoveryApplyDelay(XlogReaderState). Се вика од главна јамка за повторување за секој влез од WAL.

static bool
recoveryApplyDelay(XLogReaderState *record)
{
    uint8       xact_info;
    TimestampTz xtime;
    long        secs;
    int         microsecs;

    /* nothing to do if no delay configured */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* no delay is applied on a database not yet consistent */
    if (!reachedConsistency)
        return false;

    /*
     * Is it a COMMIT record?
     *
     * We deliberately choose not to delay aborts since they have no effect on
     * MVCC. We already allow replay of records that don't have a timestamp,
     * so there is already opportunity for issues caused by early conflicts on
     * standbys.
     */
    if (XLogRecGetRmid(record) != RM_XACT_ID)
        return false;

    xact_info = XLogRecGetInfo(record) & XLOG_XACT_OPMASK;

    if (xact_info != XLOG_XACT_COMMIT &&
        xact_info != XLOG_XACT_COMMIT_PREPARED)
        return false;

    if (!getRecordTimestamp(record, &xtime))
        return false;

    recoveryDelayUntilTime =
        TimestampTzPlusMilliseconds(xtime, recovery_min_apply_delay);

    /*
     * Exit without arming the latch if it's already past time to apply this
     * record
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Shortened:
        // Use WaitLatch until we reached recoveryDelayUntilTime
        // and then
        break;
    }
    return true;
}

Во крајна линија е дека доцнењето се заснова на физичкото време запишано во временскиот печат за извршување на трансакцијата (xtime). Како што можете да видите, доцнењето важи само за обврзувања и не влијае на другите записи - сите промени се применуваат директно, а извршувањето е одложено, така што промените ќе ги видиме само по конфигурираното одложување.

Како да користите одложена реплика за враќање на податоците

Да речеме дека имаме кластер на база на податоци и реплика со осумчасовно доцнење во производството. Ајде да видиме како да ги вратиме податоците користејќи пример случајно бришење кратенки.

Кога дознавме за проблемот, ние реставрацијата на архивата е паузирана за одложена реплика:

SELECT pg_xlog_replay_pause();

Со пауза, немавме ризик дека репликата ќе го повтори барањето DELETE. Корисна работа ако ви треба време да сфатите сè.

Поентата е дека одложената реплика мора да стигне до моментот пред барањето DELETE. Приближно го знаевме физичкото време на отстранување. Избришавме recovery_min_apply_delay и додаде recovery_target_time в recovery.conf. Еве како репликата стигнува во вистинскиот момент без одлагање:

recovery_target_time = '2018-10-12 09:25:00+00'

Со временски печати, подобро е да се намали вишокот за да не се пропушти. Точно, колку е поголемо намалувањето, толку повеќе податоци губиме. Повторно, ако го пропуштиме барањето DELETE, сè ќе биде избришано повторно и ќе мора да започнете одново (или дури и да направите ладна резервна копија за PITR).

Го рестартиравме одложениот примерок на Postgres и сегментите WAL се повторуваа до одреденото време. Можете да го следите напредокот во оваа фаза прашувајќи:

SELECT
  -- current location in WAL
  pg_last_xlog_replay_location(),
  -- current transaction timestamp (state of the replica)
  pg_last_xact_replay_timestamp(),
  -- current physical time
  now(),
  -- the amount of time still to be applied until recovery_target_time has been reached
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

Ако временскиот печат повеќе не се менува, обновувањето е завршено. Акцијата може да се прилагоди recovery_target_actionза затворање, промовирање или паузирање на примерокот по повторното обид (стандардно е суспендиран).

Базата на податоци се врати во својата состојба пред тоа несреќно барање. Сега можете, на пример, да извезувате податоци. Ги извезовме избришаните податоци за етикетата и сите врски до проблеми и барања за спојување и ги преместивме во базата на податоци за производство. Ако загубите се големи, можете едноставно да ја промовирате репликата и да ја користите како главна. Но, тогаш сите промени по точката до која се опоравивме ќе бидат изгубени.

Наместо временски печати, подобро е да користите ID на трансакции. Корисно е да се снимаат овие ID, на пример, за DDL изјави (како на пр DROP TABLE), со користење на log_statements = 'ddl'. Да имавме лична карта за трансакција, ќе земевме recovery_target_xid и истрча сè до трансакцијата пред барањето DELETE.

Враќањето на работа е многу едноставно: отстранете ги сите промени од recovery.conf и рестартирајте го Postgres. Репликата наскоро ќе има повторно доцнење од осум часа, а ние сме подготвени за идни неволји.

Придобивки за закрепнување

Со одложена реплика наместо ладна резервна копија, не мора да трошите часови за да ја вратите целата слика од архивата. На пример, ни требаат пет часа за да ја добиеме целата основна резервна копија од 2 TB. И тогаш сè уште треба да го примените целиот дневен WAL за да се вратите во посакуваната состојба (во најлош случај).

Одложената реплика е подобра од ладна резервна копија на два начина:

1. Нема потреба да се отстрани целата основна резервна копија од архивата.
2. Има фиксен осумчасовен прозорец на WAL сегменти кој мора да се повтори.

Исто така, постојано проверуваме дали е можно да се направи PITR од WAL и брзо би забележале корупција или други проблеми со архивата на WAL со следење на задоцнувањето на одложената реплика.

Во овој пример, ни требаа 50 минути за враќање, што значи дека брзината беше 110 GB WAL податоци на час (архивата сè уште беше вклучена AWS S3). Севкупно, го решивме проблемот и ги вративме податоците за 1,5 часа.

Резултати: каде е корисна одложената реплика (а каде не е)

Користете задоцнета репликација како прва помош ако случајно сте изгубиле податоци и сте го забележале овој проблем во рамките на конфигурираното доцнење.

Но, имајте на ум: репликацијата не е резервна копија.

Резервната копија и репликацијата имаат различни цели. Ладна резервна копија ќе ви помогне ако случајно сте ја направиле DELETE или DROP TABLE. Правиме резервна копија од ладилникот и ја враќаме претходната состојба на табелата или целата база на податоци. Но во исто време и барањето DROP TABLE Речиси веднаш се репродуцира во сите реплики на работниот кластер, така што обичната репликација нема да помогне овде. Самата репликација ја одржува базата на податоци достапна кога се издаваат поединечни сервери и го дистрибуира товарот.

Дури и со одложена реплика, понекогаш навистина ни треба ладна резервна копија на безбедно место ако се појави дефект на центарот за податоци, скриено оштетување или други настани што не се веднаш забележливи. Само репликацијата нема никаква корист овде.

Имајте на ум. На GitLab.com Во моментов заштитуваме од губење податоци само на системско ниво и не ги обновуваме податоците на корисничко ниво.

Извор: www.habr.com