Hur vi använde fördröjd replikering för katastrofåterställning med PostgreSQL

Replikering är inte en säkerhetskopia. Eller är den det? Så här använde vi fördröjd replikering för att återställa, efter att ha raderat etiketter av misstag.

Infrastruktur-specialister på GitLab ansvarar för driften GitLab.com – den största GitLab-instansen i naturen. Här finns 3 miljoner användare och nästan 7 miljoner projekt, och det är en av de största open source SaaS-webbplatserna med en dedikerad arkitektur. Utan PostgreSQL-databassystem kommer GitLab.com inte långt, och vi gör vad vi kan för att säkerställa motståndskraft mot eventuella fel där data kan gå förlorade. Sådan katastrof är osannolik, men vi är väl förberedda och har olika backup- och replikeringstekniker i beredskap.

Replikering är inte en lösning för databasbackup (se nedan). Men nu ska vi se hur snabbt vi kan återställa av misstag raderade data med hjälp av fördröjd replikering: när en GitLab.com användare raderade en etikett för projektet gitlab-ce och förlorade kopplingen till merge-förfrågningar och uppgifter.

Med den fördröjda replikationen återställde vi data på bara 1,5 timmar. Se hur det gick till.

Återställning till en specifik tid med PostgreSQL

PostgreSQL har en inbyggd funktion för att återställa databasens tillstånd till en viss tidpunkt. Det kallas Point-in-Time Recovery (PITR) och använder samma mekanismer som håller replikationen aktuell: utifrån en pålitlig ögonblicksbild av hela databasens kluster (grundbackup) tillämpar vi en serie tillståndsändringar fram till en viss tidpunkt.

För att använda denna funktion för kall backup gör vi regelbundet en grundbackup av databasen och sparar den i ett arkiv (GitLabs arkiv finns i Google Cloud Storage). Vi övervakar också förändringar av databasens tillstånd genom att arkivera loggen för förhandsinspelning (write-ahead log, WAL). Med allt detta kan vi utföra PITR för katastrofåterställning: vi börjar med en ögonblicksbild som togs före felet och tillämpar förändringar från WAL-arkivet fram till kraschen.

Vad är fördröjd replikering?

Fördröjd replikering är tillämpningen av ändringar från WAL med en fördröjning. Det vill säga transaktionen inträffade vid tidpunkt X, men i replikatet kommer den att visas med en fördröjning d vid tidpunkt X + d.

I PostgreSQL finns det 2 sätt att konfigurera en fysisk databasreplik: återställning från arkiv och strömreplikering. Återställning från arkiv, fungerar i grunden som PITR, men kontinuerligt: vi extraherar ständigt ändringar från WAL-arkivet och tillämpar dem på repliket. Och strömreplikering extraherar direkt WAL-strömmen från den överordnade databashostens. Vi föredrar återställning från arkiv - det är enklare att hantera och har en normal prestation som inte ligger efter den aktiva klustern.

Hur man konfigurerar fördröjd återställning från arkiv

Återställningsalternativ beskrivs i filen recovery.conf. Exempel:

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'

Med dessa inställningar har vi konfigurerat en fördröjd replik med återställning från arkiv. Här används wal-e för att extrahera WAL-segment (restore_command) från arkivet, och ändringarna kommer att tillämpas efter åtta timmar (recovery_min_apply_delay). Repliket kommer att övervaka tidslinjens ändringar i arkivet, till exempel på grund av ett felövergång i klustret (recovery_target_timeline).

Med recovery_min_apply_delay kan man konfigurera strömreplikering med fördröjning, men här finns ett par fällor kopplade till replikationsslotten, återkopplingen av het reserv och liknande. WAL-arkiv möjliggör att undvika dem.

Parameter recovery_min_apply_delay kom endast i PostgreSQL 9.3. I tidigare versioner var det nödvändigt att konfigurera en kombination av återställningshanteringsfunktioner (pg_xlog_replay_pause(), pg_xlog_replay_resume()) eller att hålla WAL-segment i arkivet under fördröjningstiden.

Hur gör PostgreSQL detta?

Det är intressant att se hur PostgreSQL implementerar fördröjd återställning. Låt oss titta på recoveryApplyDelay(XlogReaderState). Den kallas från huvudåterspelningscykeln för varje post från WAL.

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

    /* inget inget om ingen fördröjning konfigurerad */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* ingen fördröjning tillämpas på en databas som inte ännu är konsekvent */
    if (!reachedConsistency)
        return false;

    /**
     * Är det en COMMIT-post?
     *
     * Vi väljer medvetet att inte fördröja aborter eftersom de inte har någon effekt på
     * MVCC. Vi tillåter redan uppspelning av poster som inte har en tidsstämpel,
     * så det finns redan möjlighet för problem orsakade av tidiga konflikter på
     * standby.
     */
    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);

    /**
     * Avsluta utan att aktivera latch om det redan har passerat tid att tillämpa denna
     * post
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Förkortat:
        // Använd WaitLatch tills vi når recoveryDelayUntilTime
        // och sedan
        break;
    }
    return true;
}

Poängen är att fördröjningen baseras på den fysiska tiden som finns i tidsstämpeln för transaktionskommittén (xtime). Som framgår tillämpas fördröjningen endast på kommittéer och berör inte andra poster - alla ändringar tillämpas direkt, medan kommittén fördröjs, så vi kommer att se ändringarna först efter den inställda fördröjningen.

Hur man använder en fördröjd replik för datagenerering

Anta att vi har en databas i produktion och en replik med åtta timmars fördröjning. Låt oss se hur vi kan återställa data med exemplet slumparbete borttagning av etiketter.

När vi fick veta problemet stannade vi återställningen från arkivet för den fördröjda replikationen:

SELECT pg_xlog_replay_pause();

Med en paus riskerade vi inte att replikationen upprepade förfrågan. TA BORTEn användbar sak att ha tid på oss att lösa allt.

Huvudpoängen är att den fördröjda replikationen måste nå fram till punkt innan förfrågan. TA BORTVi visste ungefär den fysiska tiden för borttagningen. Vi tog bort recovery_min_apply_delay och lade till recovery_target_time på recovery.conf. På så sätt når replikeringen den önskade tidspunkten utan fördröjningar:

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

Med tidsstämplar är det bäst att dra av lite extra så att vi inte missar. Sanningen är att ju mer vi drar av, desto mer data går förlorat. Återigen, om vi missar förfrågan, TA BORT, allt tas bort igen och vi får börja om (eller till och med ta en kall backup för PITR).

Vi har startat om den avbrutna instansen av Postgres och WAL-segmenten upprepades fram till den angivna tiden. Du kan spåra framgången i detta skede med följande fråga:

SELECT
  -- nuvarande plats i WAL
  pg_last_xlog_replay_location(),
  -- nuvarande tidsstämpel för transaktionen (status för replikatet)
  pg_last_xact_replay_timestamp(),
  -- nuvarande fysiska tid
  now(),
  -- mängden tid som fortfarande måste tillämpas tills recovery_target_time har uppnåtts
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

Om tidsstämpeln inte längre ändras är återställningen slutförd. Du kan konfigurera åtgärden recovery_target_action, för att stänga, flytta fram eller pausa instansen efter upprepningen (som standard pausas den).

Databasen har återgått till tillståndet före den olyckliga förfrågan. Nu kan du till exempel exportera data. Vi exporterade de borttagna data om etiketten och alla relationer med uppgifter och merge-förfrågningar och flyttade dem till produktionsdatabasen. Om förlusterna är omfattande kan man bara flytta fram replikatet och använda det som grunddata. Men då kommer alla ändringar efter den tidpunkt vi återställde att gå förlorade.

Istället för tidsstämplar är det bättre att använda transaktions-ID. Det är bra att registrera dessa ID, till exempel för DDL-operatörer (typ DROP TABLE), med hjälp av log_statements = 'ddl'. Om vi hade haft ett transaktions-ID skulle vi ha tagit recovery_target_xid och kört allt fram till transaktionen före förfrågan. TA BORT.

Att återgå till arbetet är väldigt enkelt: ta bort alla ändringar från recovery.conf och starta om Postgres. Snart kommer det igen att finnas en åttatimmarsfördröjning i replikatet, och vi är redo för framtida problem.

Fördelar med återställning

Med en fördröjd replik behöver man inte återställa hela bilden från arkivet i timmar. Vi behöver till exempel fem timmar för att hämta hela grundbackupen på 2 TB. Och sen måste vi dessutom tillämpa hela den dagliga WAL:n för att återställa till önskat tillstånd (i värsta fall).

En fördröjd replik är bättre än en kall backup på två punkter:

1. Det finns inget behov av att hämta hela grundbackupen från arkivet.
2. Det finns ett fast åttatimmarsfönster för WAL-segment som måste upprepas.

Dessutom kontrollerar vi kontinuerligt om det går att göra PITR från WAL, och vi skulle snabbt märka skador eller andra problem med WAL-arkivet genom att övervaka fördröjningen i replikatet.

I det här exemplet tog det oss 50 minuter att återställa, vilket innebär att hastigheten var 110 GB WAL-data per timme (arkivet var fortfarande på AWS S3). Totalt löste vi problemet och återställde data på 1,5 timmar.

Sammanfattning: var avsatt replikation är användbar (och var den inte är det)

Använd avsatt replikation som en första hjälpen-lösning om du oavsiktligt har förlorat data och märkt detta inom den inställda fördröjningen.

Men kom ihåg: replikation är ingen säkerhetskopia.

Säkerhetskopiering och replikation har olika syften. En kall säkerhetskopia är användbar om du oavsiktligt har gjort TA BORT eller DROP TABLE. Vi gör en säkerhetskopia från det kalla lagret och återställer det tidigare tillståndet för tabellen eller hela databasen. Men under tiden frågan DROP TABLE återskapas nästan omedelbart i alla repliker på arbetsklustret, så vanlig replikation hjälper inte här. Själva replikationen håller databasen tillgänglig när vissa servrar går ner och fördelar belastningen.

Även med avsatt replikation behöver vi ibland en kall säkerhetskopia på en säker plats om vi plötsligt skulle få problem i datacentret, dolda skador eller andra händelser som inte märks direkt. Här är det ingen nytta av enbart replikation.

Anmärkning. Vid GitLab.com skyddar vi just nu endast på systemnivå mot dataförlust och återställer inte data på användarnivå.

Källa: habr.com