Comment nous avons utilisé la réplication différée pour la récupération d'urgence avec PostgreSQL

La réplication n'est pas une sauvegarde. Ou peut-être que si ? Voici comment nous avons utilisé la réplication retardée pour récupérer des données après avoir accidentellement supprimé des étiquettes.

Experts en infrastructure sur GitLab sont responsables du fonctionnement de GitLab.com — le plus grand exemple de GitLab existant. Ici, il y a 3 millions d'utilisateurs et presque 7 millions de projets, ce qui en fait l'un des plus grands sites open source SaaS avec une architecture dédiée. Sans le système de bases de données PostgreSQL, l'infrastructure de GitLab.com n'irait pas loin, et nous faisons tout ce qui est en notre pouvoir pour garantir la résilience en cas de défaillances qui pourraient entraîner une perte de données. Bien qu'une telle catastrophe soit peu probable, nous sommes bien préparés et avons divers mécanismes de sauvegarde et de réplication.

La réplication n'est pas un moyen de sauvegarde de bases de données (voir ci-dessous). Mais maintenant, nous allons voir comment retrouver rapidement des données accidentellement supprimées en utilisant la réplication retardée : j'ai de GitLab.com utilisateur supprimé une étiquette pour le projet gitlab-ce et j'ai perdu le lien avec les demandes de fusion et les tâches.

Avec la réplication retardée, nous avons récupéré les données en seulement 1,5 heure. Voyez comment cela s'est passé.

Récupération à un instant donné avec PostgreSQL

PostgreSQL possède une fonction intégrée qui restaure l'état de la base de données à un moment donné. Elle s'appelle Récupération à un instant donné (PITR) et utilise les mêmes mécanismes qui maintiennent la validité de la réplique : en commençant par un instantané fiable de l'ensemble du cluster de bases de données (sauvegarde de base), nous appliquons une série d'états jusqu'à un moment précis.

Pour utiliser cette fonction pour une sauvegarde à froid, nous faisons régulièrement une sauvegarde de base de la base de données et la stockons dans un archive (les archives de GitLab résident dans le stockage cloud de Google). Nous suivons également les changements de l'état de la base de données en archivant le journal des écritures anticipées (write-ahead log, WAL). Et avec tout cela, nous pouvons effectuer un PITR pour la récupération d'urgence : nous commençons par l'instantané fait avant l'erreur et appliquons les changements à partir de l'archive WAL jusqu'à la panne.

Qu'est-ce que la réplication retardée ?

La réplication retardée consiste à appliquer des modifications du WAL avec un certain délai. Cela signifie qu'une transaction s'est produite à une heure donnée X, mais dans la réplique, elle apparaîtra avec un retard d d'une heure X + d.

PostgreSQL propose 2 méthodes pour configurer une réplication physique de la base de données : la récupération à partir d'une archive et la réplication en streaming. Récupération à partir d'une archive, en fait, fonctionne comme un PITR mais de manière continue : nous extrayons constamment les modifications de l'archive WAL et les appliquons à la réplique. A réplication continue extrait directement le flux WAL de l'hôte de base de données supérieur. Nous préférons la récupération depuis l'archive — c'est plus facile à gérer et cela possède des performances normales qui ne sont pas inférieures à celles du cluster opérationnel.

Comment configurer la récupération différée depuis l'archive

Options de récupération décrites dans le fichier recovery.conf. Exemple :

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'

Avec ces paramètres, nous avons configuré une réplique différée récupérant depuis l'archive. Il utilise wal-e pour extraire les segments WAL (restore_command) de l'archive, et les modifications seront appliquées après huit heures (recovery_min_apply_delay). La réplique suivra les changements de la chronologie dans l'archive, par exemple, en raison de la gestion des pannes dans le cluster (recovery_target_timeline).

Avec recovery_min_apply_delay il est possible de configurer une réplication continue avec retard, mais il y a quelques pièges liés aux slots de réplication, à la rétroaction de secours à chaud, etc. L'archive WAL permet de les éviter.

Paramètre recovery_min_apply_delay est apparue seulement dans PostgreSQL 9.3. Dans les versions précédentes, pour la réplication différée, il fallait configurer une combinaison de fonctions de gestion de récupération (pg_xlog_replay_pause(), pg_xlog_replay_resume()) ou conserver les segments WAL dans l'archive pendant la durée du retard.

Comment PostgreSQL fait-il cela ?

Il est intéressant de voir comment PostgreSQL met en œuvre la récupération différée. Regardons recoveryApplyDelay(XlogReaderState). Cela est appelé depuis la boucle principale de répétition pour chaque enregistrement du WAL.

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

    /* rien à faire si aucun délai n'est configuré */
    if (recovery_min_apply_delay <= 0)
        return false;

    /* aucun délai n'est appliqué sur une base de données non encore cohérente */
    if (!reachedConsistency)
        return false;

    /*
     * Est-ce un enregistrement COMMIT ?
     *
     * Nous choisissons délibérément de ne pas retarder les aborts car ils n'ont aucun effet sur
     * le MVCC. Nous permettons déjà la relecture des enregistrements qui n'ont pas de timestamp,
     * donc il y a déjà des opportunités pour des problèmes causés par des conflits précoces sur
     * les réplicas.
     */
    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);

    /*
     * Quitter sans armer le latch si c'est déjà passé le temps d'appliquer cet
     * enregistrement
     */
    TimestampDifference(GetCurrentTimestamp(), recoveryDelayUntilTime,
                        &secs, &microsecs);
    if (secs <= 0 && microsecs <= 0)
        return false;

    while (true)
    {
        // Raccourci :
        // Utiliser WaitLatch jusqu'à ce que nous atteignions recoveryDelayUntilTime
        // puis
        break;
    }
    return true;
}

L'essentiel est que le délai est basé sur le temps physique enregistré dans l'horodatage du commit de la transaction (xtime). Comme on peut le voir, le délai ne s'applique qu'aux commits et ne touche pas d'autres enregistrements — tous les changements sont appliqués directement, et le commit est retardé, donc nous ne verrons les changements qu'après le délai configuré.

Comment utiliser une réplique retardée pour la récupération des données

Supposons que nous ayons un cluster de bases de données en production et une réplique avec un retard de huit heures. Voyons comment récupérer les données à l'aide de la suppression accidentelle de raccourcis.

Lorsque nous avons pris connaissance du problème, nous avons suspendu la récupération à partir de l'archive pour la réplique retardée :

SELECT pg_xlog_replay_pause();

Avec la pause, nous n'avions pas le risque que la réplique répète la requête SUPPRIMER. C'est utile si vous avez besoin de temps pour tout comprendre.

L'essentiel est que la réplique retardée doit atteindre le moment juste avant la requête SUPPRIMER. Nous savions à peu près le temps physique de la suppression. Nous avons supprimé recovery_min_apply_delay et ajouté recovery_target_time dans recovery.conf. Ainsi, la réplique atteint le bon moment sans retard :

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

Avec les horodatages, il est préférable de réduire, pour ne pas se tromper. Toutefois, plus vous réduisez, plus vous perdez de données. Encore une fois, si nous manquons la requête SUPPRIMER, tout sera à nouveau supprimé et il faudra recommencer (ou utiliser une sauvegarde froide pour le PITR).

Nous avons redémarré l'instance Postgres différée, et les segments WAL se répétèrent jusqu'à l'heure indiquée. Vous pouvez suivre les progrès à ce stade avec la requête :

SELECT
  -- emplacement actuel dans le WAL
  pg_last_xlog_replay_location(),
  -- horodatage de transaction actuel (état de la réplique)
  pg_last_xact_replay_timestamp(),
  -- temps physique actuel
  now(),
  -- le temps restant à appliquer jusqu'à ce que recovery_target_time soit atteint
  '2018-10-12 09:25:00+00'::timestamptz - pg_last_xact_replay_timestamp() as delay;

Si l'horodatage ne change plus, la restauration est terminée. Vous pouvez configurer l'action recovery_target_action, pour fermer, avancer ou suspendre l'instance après la répétition (par défaut, elle est suspendue).

La base de données est revenue à un état antérieur à cette demande malheureuse. Il est maintenant possible, par exemple, d'exporter des données. Nous avons exporté les données supprimées sur le marqueur et toutes les relations avec les tâches et les demandes de fusion et les avons transférées dans la base de données de travail. S'il y a une perte importante, vous pouvez simplement avancer la réplique et l'utiliser comme principale. Mais dans ce cas, toutes les modifications après le moment jusqu'où nous avons récupéré seront perdues.

Il est préférable d'utiliser des ID de transactions au lieu d'horodatages. Il est utile de noter ces ID, par exemple, pour les opérateurs DDL (comme DROP TABLE), en utilisant log_statements = 'ddl'. Si nous avions eu l'ID de transaction, nous aurions pris recovery_target_xid et l'aurions exécuté jusqu'à la transaction précédant la demande. SUPPRIMER.

Revenir au travail est très simple : retirez toutes les modifications de recovery.conf et redémarrez Postgres. La réplique aura bientôt un retard de huit heures à nouveau, et nous serons prêts pour de futures mésaventures.

Avantages de la restauration

Avec une réplique différée au lieu d'une sauvegarde à froid, il n'est pas nécessaire de restaurer l'ensemble de l'instantané depuis l'archive pendant des heures. Par exemple, nous avons besoin de cinq heures pour extraire l'ensemble de la sauvegarde de base de 2 To. Et ensuite, il faudra encore appliquer tout le WAL quotidien pour revenir à l'état souhaité (dans le pire des cas).

Une réplique différée est meilleure qu'une sauvegarde à froid pour deux raisons :

1. Il n'est pas nécessaire d'extraire l'ensemble de la sauvegarde de base depuis l'archive.
2. Il y a une fenêtre fixe de huit heures de segments WAL à répéter.

De plus, nous vérifions en permanence s'il est possible de faire un PITR depuis le WAL, et nous remarquerions rapidement des dommages ou d'autres problèmes avec l'archive WAL en surveillant le retard de la réplique différée.

Dans cet exemple, nous avons mis 50 minutes pour la restauration, soit une vitesse de 110 Go de données WAL par heure (l'archive était alors toujours sur AWS S3Nous avons résolu le problème et restauré les données en 1,5 heure.

Résumé : où la réplication différée est utile (et où elle ne l'est pas)

Utilisez la réplication différée comme un moyen de premiers secours si vous avez accidentellement perdu des données et que vous avez remarqué ce problème dans la fenêtre de délai configurée.

Mais gardez à l'esprit : la réplication n'est pas une sauvegarde.

La sauvegarde et la réplication ont des objectifs différents. Une sauvegarde à froid est utile si vous avez accidentellement effectué une SUPPRIMER ou DROP TABLE. Nous faisons une sauvegarde depuis le stockage à froid et restaurons l'état précédent de la table ou de l'ensemble de la base de données. Mais à ce stade, la requête DROP TABLE est presque instantanément reproduite dans toutes les réplicas du cluster de travail, donc la réplication habituelle ne résoudra pas le problème. La réplication elle-même maintient la base de données accessible lorsque certains serveurs échouent, et répartit la charge.

Même avec une réplication différée, nous avons parfois vraiment besoin d'une sauvegarde à froid dans un endroit sûr, au cas où un échec du centre de données se produirait, un dommage caché ou d'autres événements qui ne sont pas immédiatement visibles. Ici, une simple réplication ne suffit pas.

Remarque. À de GitLab.com nous protégeons actuellement contre la perte de données uniquement au niveau du système et ne restaurons pas les données au niveau de l'utilisateur.

Source : habr.com