Wie wir verzögerte Replikation für die Notfallwiederherstellung mit PostgreSQL eingesetzt haben

Replikation ist kein Backup. Oder doch? So haben wir verzögerte Replikation zur Wiederherstellung genutzt, nachdem wir versehentlich Shortcuts gelöscht haben.

Infrastruktur-Spezialisten bei GitLab sind verantwortlich für den Betrieb GitLab.com — die größte Instanz von GitLab weltweit. Hier gibt es 3 Millionen Nutzer und fast 7 Millionen Projekte, und es ist eine der größten Open-Source-SaaS-Seiten mit dedizierter Architektur. Ohne das PostgreSQL-Datenbanksystem würde die Infrastruktur von GitLab.com nicht weit kommen, und wir tun alles, um die Ausfallsicherheit für den Fall von Datenverlusten zu gewährleisten. Eine solche Katastrophe ist zwar unwahrscheinlich, aber wir sind gut vorbereitet und haben verschiedene Backup- und Replikationsmechanismen eingeplant.

Replikation ist nicht das gleiche wie ein Datenbank-Backup (siehe unten). Aber jetzt werden wir sehen, wie man versehentlich gelöschte Daten schnell mit verzögerter Replikation wiederherstellt: Ich GitLab.com Benutzer habe einen Shortcut gelöscht für das Projekt gitlab-ce und habe die Verbindungen zu Merge-Requests und Aufgaben verloren.

Mit der verzögerten Replikation haben wir die Daten in nur 1,5 Stunden wiederhergestellt. Sehen Sie, wie es gemacht wurde.

Wiederherstellung zu einem bestimmten Zeitpunkt mit PostgreSQL

PostgreSQL verfügt über eine integrierte Funktion, die den Zustand der Datenbank zu einem bestimmten Zeitpunkt wiederherstellt. Diese Funktion nennt sich Point-in-Time Recovery (PITR) und nutzt die gleichen Mechanismen, die die Aktualität der Replica unterstützen: Ausgehend von einem zuverlässigen Snapshot des gesamten Datenbankclusters (Basis-Backup) wenden wir eine Reihe von Zustandsänderungen bis zu einem bestimmten Zeitpunkt an.

Um diese Funktion für ein kaltes Backup zu nutzen, führen wir regelmäßig ein Basis-Backup der Datenbank durch und speichern es im Archiv (GitLab-Archive befinden sich in Google Cloud Storage). Außerdem verfolgen wir die Änderungen am Datenbankzustand, indem wir das Write-Ahead-Log (write-ahead log, WAL) archivieren. Mit all dem können wir PITR für die Notfallwiederherstellung durchführen: Wir beginnen mit einem Snapshot, der vor dem Fehler gemacht wurde, und wenden die Änderungen aus dem WAL-Archiv bis zum Ausfall an.

Was ist verzögerte Replikation?

Verzögerte Replikation ist das Anwenden von Änderungen aus dem WAL mit Verzögerung. Das heißt, die Transaktion fand um Uhr Xstatt, wird aber in der Replik mit Verzögerung angezeigt d um Stunde X + d.

In PostgreSQL gibt es zwei Möglichkeiten, eine physische Datenbankreplikation einzurichten: die Wiederherstellung aus dem Archiv und die Streaming-Replikation. Wiederherstellung aus dem Archiv, funktioniert im Grunde wie PITR, jedoch kontinuierlich: Wir extrahieren ständig die Änderungen aus dem WAL-Archiv und wenden diese auf die Replik an. Die Streaming-Replikation extrahiert direkt den WAL-Stream vom übergeordneten Datenbankhost. Wir bevorzugen die Wiederherstellung aus dem Archiv – sie ist einfacher zu verwalten und bietet eine normale Leistung, die der des aktiven Clusters nicht nachsteht.

So richten Sie die verzögerte Wiederherstellung aus dem Archiv ein

Wiederherstellungsoptionen sind in der Datei recovery.conf. Beispiel:

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'

Mit diesen Parametern haben wir eine verzögerte Replikation mit Wiederherstellung aus dem Archiv eingerichtet. Hierbei verwenden wir wal-e zum Extrahieren der WAL-Segmente (restore_command) aus dem Archiv, und die Änderungen werden nach acht Stunden angewendet (recovery_min_apply_delay). Die Replik wird die Änderungen in der Zeitleiste im Archiv verfolgen, zum Beispiel aufgrund eines Ausfalls im Cluster (recovery_target_timeline).

E recovery_min_apply_delay Es ist möglich, eine Streaming-Replikation mit Verzögerung einzurichten, jedoch gibt es hier ein paar Fallstricke, die mit den Replikationsslots, dem Hot-Standby-Feedback und ähnlichem zu tun haben. Das WAL-Archiv hilft, diese zu umgehen.

Parameter recovery_min_apply_delay dies wurde erst in PostgreSQL 9.3 eingeführt. In früheren Versionen musste eine Kombination für die verzögerte Replikation eingerichtet werden. Wiederherstellungsmanagement-Funktionen (pg_xlog_replay_pause(), pg_xlog_replay_resume()) oder die WAL-Segmente während der Verzögerungszeit im Archiv halten.

Wie macht PostgreSQL das?

Es ist interessant zu sehen, wie PostgreSQL die verzögerte Wiederherstellung umsetzt. Schauen wir uns an, recoveryApplyDelay(XlogReaderState). Dies wird aus dem Hauptwiederholungsschleife für jeden Eintrag im WAL aufgerufen.

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

    /* nichts zu tun, wenn keine Verzögerung konfiguriert ist */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* Keine Verzögerung bei einer Datenbank, die noch nicht konsistent ist */
    if (!reachedConsistency)
        return false;

    /*
     * Ist es ein COMMIT-Datensatz?
     *
     * Wir wählen absichtlich, keine Verzögerung für Abbrüche anzuwenden, da sie keine
     * Auswirkungen auf MVCC haben. Wir erlauben bereits die Wiedergabe von Datensätzen,
     * die keinen Zeitstempel haben,
     * daher gibt es bereits Gelegenheiten für Probleme, die durch frühe Konflikte
     * auf Standby-Systemen verursacht werden.
     */
    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);

    /*
     * Beenden, ohne den Latch zu aktivieren, falls es bereits an der Zeit
     * ist, diesen Datensatz anzuwenden
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Abgekürzt:
        // Verwenden Sie WaitLatch, bis wir die recoveryDelayUntilTime erreicht haben
        // und dann
        break;
    }
    return true;
}

Der Kernpunkt ist, dass die Verzögerung auf der physikalischen Zeit basiert, die in dem Zeitstempel der Transaktionsbestätigung aufgezeichnet ist (xtime). Wie zu sehen ist, wird die Verzögerung nur auf die Commits angewendet und betrifft keine anderen Einträge – alle Änderungen werden direkt angewendet, während der Commit verzögert wird, sodass wir die Änderungen erst nach der festgelegten Verzögerung sehen.

Wie man eine verzögerte Replikat zur Datenwiederherstellung verwendet

Angenommen, wir haben in der Produktion einen Datenbankcluster und eine Replikat mit einer achtstündigen Verzögerung. Schauen wir uns an, wie wir Daten anhand des Beispiels einer zufälligen Löschung von Verknüpfungen.

als wir von dem Problem erfuhren, haben wir die Wiederherstellung aus dem Archiv angehalten für die verzögerte Replikat:

SELECT pg_xlog_replay_pause();

Mit der Pause hatten wir kein Risiko, dass die Replikat die Anfrage wiederholt DELETE. Nützlich, wenn man Zeit benötigt, um alles zu klären.

Die Idee ist, dass die verzögerte Replikat bis zum Moment vor der Anfrage gelangen sollte DELETE. Wir wussten ungefähr, wann die Löschung stattgefunden hat. Wir haben gelöscht recovery_min_apply_delay und hinzugefügt recovery_target_time in recovery.conf. So erreicht die Replikat den gewünschten Zeitpunkt ohne Verzögerungen:

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

Bei Zeitstempeln sollte man lieber nicht zu viel abziehen, um nichts zu verpassen. Allerdings bedeutet eine größere Abziehmenge, dass mehr Daten verloren gehen. Wiederum, wenn wir die Anfrage überspringen. DELETE, alles wird wieder gelöscht und Sie müssen von vorne beginnen (oder ein kaltes Backup für PITR übernehmen).

Wir haben die verzögerte Postgres-Instanz neu gestartet, und die WAL-Segmente wiederholten sich bis zu dem angegebenen Zeitpunkt. Den Fortschritt in dieser Phase können Sie mit der Abfrage verfolgen:

SELECT
  -- aktuelle Position in WAL
  pg_last_xlog_replay_location(),
  -- aktueller Transaktionszeitstempel (Status des Replikats)
  pg_last_xact_replay_timestamp(),
  -- aktuelle physische Zeit
  now(),
  -- die Menge an Zeit, die noch angewendet werden muss, bis die recovery_target_time erreicht ist
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

Wenn der Zeitstempel nicht mehr verändert wird, ist die Wiederherstellung abgeschlossen. Sie können die Aktion recovery_target_action, um die Instanz nach der Wiederholung zu schließen, voranzutreiben oder anzuhalten (standardmäßig wird sie angehalten).

Die Datenbank ist in den Zustand vor der fehlerhaften Anfrage zurückgekehrt. Jetzt können Sie beispielsweise Daten exportieren. Wir haben die gelöschten Daten zu den Labels und alle Verbindungen zu Aufgaben und Merge-Requests exportiert und in die Produktionsdatenbank übertragen. Wenn die Verluste erheblich sind, können Sie einfach das Replikat voranbringen und als Hauptdatenbank verwenden. Aber dann gehen alle Änderungen nach dem Zeitpunkt verloren, zu dem wir wiederhergestellt haben.

Statt Zeitstempel sollten Transaktions-IDs verwendet werden. Es ist nützlich, diese IDs aufzuzeichnen, zum Beispiel für DDL-Operatoren (wie DROP TABLE), mithilfe von log_statements = 'ddl'. Hätten wir die Transaktions-ID, würden wir recovery_target_xid nehmen und alles bis zur Transaktion vor der Anfrage ausführen. DELETE.

Es ist sehr einfach, zur Arbeit zurückzukehren: Entfernen Sie alle Änderungen aus recovery.conf und starten Sie Postgres neu. Bald wird die Replikation wieder eine achtstündige Verzögerung aufweisen, und wir sind bereit für zukünftige Probleme.

Vorteile der Wiederherstellung

Mit einer verzögerten Replikation müssen wir nicht stundenlang ein vollständiges Snapshot aus dem Archiv wiederherstellen. Es dauert bei uns beispielsweise fünf Stunden, um das gesamte Basis-Backup von 2 TB abzurufen. Und dann müssen wir auch noch das gesamte tägliche WAL anwenden, um den gewünschten Zustand wiederherzustellen (im schlimmsten Fall).

Eine verzögerte Replikation ist in zwei Punkten besser als ein kaltes Backup:

1. Das gesamte Basis-Backup muss nicht aus dem Archiv entnommen werden.
2. Es gibt ein festgelegtes achtstündiges Fenster für die WAL-Segmente, die wiederholt werden müssen.

Außerdem überprüfen wir ständig, ob ein PITR aus dem WAL möglich ist, und würden schnell Schäden oder andere Probleme mit dem WAL-Archiv bemerken, während wir die Verzögerung der verzögerten Replikation im Auge behalten.

In diesem Beispiel benötigten wir 50 Minuten für die Wiederherstellung, was einer Geschwindigkeit von 110 GB WAL-Daten pro Stunde entspricht (Archiv war zu diesem Zeitpunkt noch auf AWS S3). Insgesamt haben wir das Problem gelöst und die Daten in 1,5 Stunden wiederhergestellt.

Zusammenfassung: Wo ist verzögerte Replikation sinnvoll (und wo nicht)

Nutzen Sie verzögerte Replikation als Erste-Hilfe-Maßnahme, wenn Sie versehentlich Daten verloren haben und dieses Problem innerhalb der konfigurierten Verzögerung bemerken.

Aber beachten Sie: Replikation ist kein Backup.

Backup und Replikation haben unterschiedliche Ziele. Ein Kalt-Backup ist nützlich, wenn Sie versehentlich gemacht haben DELETE oder DROP TABLE. Wir führen ein Backup aus einem kalten Speicher durch und stellen den vorherigen Zustand einer Tabelle oder der gesamten Datenbank wieder her. Aber gleichzeitig wird die Anfrage DROP TABLE fast sofort in allen Replikaten des Arbeitsclusters reproduziert, sodass die gewöhnliche Replikation hier nicht hilft. An sich sorgt Replikation dafür, dass die Datenbank verfügbar bleibt, wenn einzelne Server ausfallen, und verteilt die Last.

Selbst mit einer verzögerten Replikation benötigen wir manchmal dringend ein Kalt-Backup an einem sicheren Ort, falls es zu einem Ausfall des Rechenzentrums, einem verdeckten Schaden oder anderen Ereignissen kommt, die man nicht sofort bemerkt. Hier nützt eine reine Replikation nichts.

Hinweis. In GitLab.com Wir schützen derzeit Datenverlust nur auf Systemebene und stellen die Daten nicht auf Benutzerebene wieder her.

Quelle: habr.com