Како смо користили лењу репликацију за опоравак од катастрофе са ПостгреСКЛ-ом

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

Стручњаци за инфраструктуру ГитЛаб је одговоран за рад ГитЛаб.цом - највећа ГитЛаб инстанца у природи. Са 3 милиона корисника и скоро 7 милиона пројеката, то је једна од највећих СааС локација отвореног кода са наменском архитектуром. Без ПостгреСКЛ система базе података, ГитЛаб.цом инфраструктура неће догурати далеко, а шта радимо да обезбедимо толеранцију грешака у случају било каквих кварова када подаци могу бити изгубљени. Мало је вероватно да ће се таква катастрофа десити, али ми смо добро припремљени и опскрбљени разним механизмима резервне копије и репликације.

Репликација није средство за прављење резервних копија база података (погледајте испод). Али сада ћемо видети како брзо опоравити случајно избрисане податке користећи лењу репликацију: укључено ГитЛаб.цом корисник обрисао пречицу за пројекат gitlab-ce и изгубљене везе са захтевима за спајање и задацима.

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

Опоравак у тренутку са ПостгреСКЛ-ом

ПостгреСКЛ има уграђену функцију која враћа стање базе података у одређено време. Зове се Опоравак у тренутку (ПИТР) и користи исте механизме који одржавају реплику ажурном: почевши од поузданог снимка читавог кластера базе података (базна резервна копија), примењујемо серију промена стања до одређеног тренутка.

Да бисмо користили ову функцију за хладну резервну копију, редовно правимо основну резервну копију базе података и чувамо је у архиви (ГитЛаб архиве живе у Гоогле складиште у облаку). Такође пратимо промене у стању базе података архивирањем дневника уписивања унапред (запис унапред, ВАЛ). И са свим овим на месту, можемо да урадимо ПИТР за опоравак од катастрофе: почевши од снимка направљеног пре квара и примене промена из ВАЛ архиве до грешке.

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

Лења репликација је примена промена из ВАЛ-а са закашњењем. То јест, трансакција се догодила за сат времена X, али ће се у реплици појавити са закашњењем d за сат времена X + d.

ПостгреСКЛ има 2 начина да се подеси реплика физичке базе података: опоравак резервне копије и репликација стриминга. Враћање из архиве, у суштини ради као ПИТР, али континуирано: стално преузимамо промене из ВАЛ архиве и примењујемо их на реплику. А стреаминг репликација директно преузима ВАЛ ток из узводног хоста базе података. Више волимо опоравак архиве – њиме је лакше управљати и има нормалне перформансе које су у складу са производним кластером.

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

Опције опоравка описано у фајлу 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'

Са овим параметрима смо конфигурисали одложену реплику са опоравком резервне копије. Овде се користи вал-е да издвојите ВАЛ сегменте (restore_command) из архиве, а промене ће бити примењене након осам сати (recovery_min_apply_delay). Реплика ће пазити на промене временске линије у архиви, на пример због грешке кластера (recovery_target_timeline).

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

Параметар recovery_min_apply_delay појавио се само у ПостгреСКЛ 9.3. У претходним верзијама, за одложену репликацију морате да конфигуришете комбинацију функције управљања опоравком (pg_xlog_replay_pause(), pg_xlog_replay_resume()) или задржите ВАЛ сегменте у архиви за време трајања кашњења.

Како ПостгреСКЛ то ради?

Занимљиво је видети како ПостгреСКЛ имплементира лењи опоравак. Хајде да погледамо recoveryApplyDelay(XlogReaderState). Зове се из главна петља понављања за сваки унос из ВАЛ-а.

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, све ће бити поново избрисано и мораћете да почнете изнова (или чак направите хладну резервну копију за ПИТР).

Поново смо покренули одложену Постгрес инстанцу и ВАЛ сегменти су се понављали до одређеног времена. Можете пратити напредак у овој фази тако што ћете питати:

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да затворите, унапредите или паузирате инстанцу након поновног покушаја (подразумевано је суспендована).

База података се вратила у стање пре тог несрећног захтева. Сада можете, на пример, да извозите податке. Извезли смо избрисане податке о етикети и све везе до проблема и захтева за спајање и преместили их у производну базу података. Ако су губици великих размера, можете једноставно промовисати реплику и користити је као главну. Али тада ће све промене после тачке до које смо се опоравили бити изгубљене.

Уместо временских ознака, боље је користити ИД трансакције. Корисно је снимити ове ИД-ове, на пример, за ДДЛ изјаве (као нпр DROP TABLE), коришћењем log_statements = 'ddl'. Да имамо ИД трансакције, узели бисмо recovery_target_xid и покренуо све до трансакције пре захтева DELETE.

Повратак на посао је врло једноставан: уклоните све промене из recovery.conf и поново покрените Постгрес. Реплика ће ускоро поново имати осам сати кашњења, а ми смо спремни за будуће невоље.

Предности опоравка

Са одложеном репликом уместо хладне резервне копије, не морате да трошите сате на враћање целе слике из архиве. На пример, потребно нам је пет сати да добијемо целу основну резервну копију од 2 ТБ. А онда и даље морате да примените цео дневни ВАЛ да бисте се опоравили у жељено стање (у најгорем случају).

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

1. Нема потребе да уклањате целу основну резервну копију из архиве.
2. Постоји фиксни осмочасовни прозор ВАЛ сегмената који се морају поновити.

Такође стално проверавамо да ли је могуће направити ПИТР из ВАЛ-а и брзо бисмо приметили оштећење или друге проблеме са ВАЛ архивом праћењем кашњења одложене реплике.

У овом примеру, требало нам је 50 минута да вратимо, што значи да је брзина била 110 ГБ ВАЛ података на сат (архива је још увек била укључена АВС С3). Укупно смо решили проблем и повратили податке за 1,5 сат.

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

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

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

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

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

Приметити. Он ГитЛаб.цом Тренутно штитимо само од губитка података на нивоу система и не обнављамо податке на нивоу корисника.

Извор: ввв.хабр.цом