Как използвахме мързелива репликация за възстановяване след срив с PostgreSQL

Репликацията не е резервно копие. Или не? Ето как използвахме отложена репликация за възстановяване от случайно изтрити преки пътища.

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

Репликацията не е средство за архивиране на бази данни (виж отдолу). Но сега ще видим как бързо да възстановим случайно изтрити данни с помощта на мързелива репликация: on GitLab.com потребител изтри прекия път за проекта gitlab-ce и загубени връзки със заявки за сливане и задачи.

С отложена реплика възстановихме данните само за 1,5 часа. Вижте как стана.

Възстановяване във времето с PostgreSQL

PostgreSQL има вградена функция, която възстановява състоянието на база данни до определен момент от време. Нарича се Възстановяване в даден момент (PITR) и използва същите механизми, които поддържат репликата актуална: започвайки с надеждна моментна снимка на целия клъстер на базата данни (базов архив), ние прилагаме поредица от промени в състоянието до определен момент във времето.

За да използваме тази функция за студено архивиране, ние редовно правим основно архивиране на база данни и го съхраняваме в архив (архивите на GitLab живеят в Облачно хранилище на Google). Ние също така наблюдаваме промените в състоянието на базата данни, като архивираме дневника за предварителен запис (дневник за предварително записване, WAL). И с всичко това на място, можем да направим 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за затваряне, повишаване или пауза на екземпляра след повторен опит (той е спрян по подразбиране).

Базата данни се върна в състоянието си преди тази злополучна заявка. Сега можете например да експортирате данни. Експортирахме изтритите данни за етикети и всички връзки към проблеми и заявки за сливане и ги преместихме в производствената база данни. Ако загубите са големи, можете просто да рекламирате репликата и да я използвате като основна. Но тогава всички промени след точката, до която сме се възстановили, ще бъдат загубени.

Вместо времеви отпечатъци е по-добре да използвате идентификатори на транзакции. Полезно е да записвате тези идентификатори, например, за 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