Guide de l'utilisateur pgBackRest - Debian & Ubuntu / PostgreSQL 10

Introduction

Ce guide d'utilisateur est destiné à être suivi séquentiellement du début à la fin— chaque section dépend de la précédente. Par exemple, la section Backup repose sur la configuration qui est décrite dans la sesction Démarrage rapide. Une fois que la configuration de pgBackRest est opérationnelle, il est possible de sauter des étapes, mais il est recomandé de suivre le guide dans l'ordre la première fois.

Bien que les exemples soient destinées pour être mise en oeuvre avec le système d'exploitation Debian/Ubuntu et PostgreSQL version 10, il devrait être assez simple d'appliquer ce guide à toute autre distribution Unix et à toutes les versions de PostgreSQL. Seules les commandes spécifiques au système d'exploitation sont celle qui permettent de créer, de démarrer, d'arrêter et de détruire une instance PostgreSQL. Les commandes de pgBackRest seront les mêmes quelques soit le syst-me Unix que vous utilisez— bien entendue les emplacement d'installation des excutables peuvent varier.

Les informations et la documentation relatives à la configuration d'une instance PostgreSQL se trouvent sur les sites Manuel en Anglais officiel ou pour la version française sur le site d'association PostgreSQLfr.

Le présent guide de l'utilisateur adopte une approche assez nouvelle dans la rédaction de la documentation. En effet chaque comande est exécutée sur une machine virtuelle lorsque la documentation est rédigé de façon automatique à partir de la source au format XML. Cela signifie que vous pouvez avoir la certitude que les commandes fonctionnent correctement dans l'ordre qui vous sera présenté. Les résultats de chaque commande sont capturés et affichés sous celle-ci. Si la sortie n'est pas incluse, c'est qu'elle a été jugée non pertinente.

Toutes les commandes sont destinées à être exécutées par un utilisateur non privilégié qui dispose du droit sudo pour les utilisateurs root et postgres. Il est possible d'exécuter les commandes directement en tant que l'utilisateurs root et postgres— dans ce cas, les commandes sudo peuvent être retirées.

Concepts

La notion des concepts suivants sont définis comme étant pertients dans la compréhention de pgBackRest, PostgreSQL, et de ce guide de l'utilisateur.

2.1

Sauvegarde

Une sauvegarde est une copie cohérente d'une instance de base de données qui peut être restauré suite à une panne matérielle, pour effectuer une récupération à un instant (PITR) ou encore pour créer une nouvelle instance esclave.

Sauvegarde complète: pgBackRest copie l'intégralité du contenu de l'instance de base de données sur la sauvegarde. La première sauvegarde d'une instance est toujours une sauvegarde complète. pgBackRest sera toujours capable de restaurer directement une sauvegarde complète. Cette sauvegarde complète ne dépent d'aucun autre fichier en dehors de la sauvegarde complète, ceci pour des raisons de consistance.

Sauvegarde différentielle: pgBackRest ne copie que les fichiers de l'instance ayant changé depuis la dernière sauvegarde complète. Lors d'une restauration dfférentielle pgBackRest restaure en copiant tous les fichiers de la sauvegarde différentielle ainsi que les fichiers inchangé de la précédente sauvegarde complète. L'avantage d'une sauvegarde différentielle est qu'elle nécessite moins d'espace disque qu'une sauvegarde complète. Cependant, la sauvegarde différentielle et la sauvegarde complète doivent toutes deux être valides pour restaurer la sauvegarde différentielle.

Sauvegarde incrémentale: pgBackRest ne copie que les fichiers de l'instance de base de données qui ont été modifiés depuis la dernière sauvegarde (celle-ci peut être une autre sauvegarde incrémentale, une sauvegarde différentielle ou une sauvegarde complète). Puisqu'une sauvegarde incrémentale n'inclut que les fichiers modifiés depuis la sauvegarde précédente, ils sont généralement beaucoup plus petits que les sauvegardes complètes ou différentielles. Comme pour la sauvegarde différentielle, la sauvegarde incrémentale dépend des autres sauvegardes pour pouvoir être restaurer. Etant donné que la sauvegarde incrémentale ne comprend que les fichiers modifiés depuis la dernière sauvegarde, toutes les sauvegardes incrémentale antérieures qui ont été effectuées ainsi que la sauvegarde différentielle antérieure et la sauvegarde complète antérieure doivent toutes être valides pour pouvoir effectuer une restauration de la sauvegarde incrémentale. Si aucune sauvegarde différentielle n'existe, alors toutes les sauvegardes incrémentales antérieures doivent être valide depuis la dernière sauvegarde complète pour pouvoir restaurer la sauvegarde incrémentale.

2.2

Restoration

Une restauration est une opération qui consiste à copier une sauvegarde sur un système pour être lancer en temps qu'instance de base de données. Une restauration nécessite les fichiers de sauvegarde et un ou plusieurs segments WAL (journaux de transaction) afin de fonctionner correctement.

2.3

Journaux de transaction (Write Ahead Log : WAL)

Le WAL est le mécanisme que PostgreSQL utilise pour s'assurer qu'aucun changement confirmé n'est perdu. Les transactions sont écrites séquentiellement dans le WAL et une transaction est considérée comme confirmée lorsque ces écritures sont enregistrées sur le disque. Ensuite, un processus en arrière-plan écrit les modifications dans les fichiers principaux de l'instance de la base de données (également connu sous le nom heap). En cas de crash, le WAL est rejoué pour rendre la base de données cohérente.

Le WAL est conceptuellement infini mais en pratique, il est divisé en fichiers individuels de 16 Mo appelés segments. Les segments WAL suivent la convention de nommage suivant 0000000100000A1E000000FE où les 8 premiers chiffres hexadécimaux représentent la 'timeline' et les 16 chiffres suivants sont le numéro de séquence logique (LSN).

2.4

Chiffrement

Le chiffrement est le processus de conversion des données dans un format qui n'est pas reconnaissable à moins que le mot de passe approprié (également appelé clef) ne soit fourni.

pgBackRest chiffrera le dépôt de sauvegarde sur la base d'un mot de passe fourni par l'utilisateur, empêchant ainsi tout accès non autorisé aux données stockées dans le dépôt.

Mise à niveau de pgBackRest

3.1

Mise à niveau de pgBackRest depuis la v1 vers la v2

Le passage de la version v1 vers la version v2 est assez simple. Le format du dépôt de sauvegarde n'a pas changé et les options marqué comme dépréciées de la v1 reste acceptées de sorte que pour la plupart des installations, une simple mise à jours des binaires vers la nouvelle version suffit.

Toutefois, il y a quelques mises en garde :

L'option dépréciées thread-max n'est plus valide. Utiliser process-max à la place.
L'option dépréciées archive-max-mb n'est plus valide. Cette option a été remplacée par l'option archive-push-queue-max qui a une syntaxe différente.
La valeur par defaut pour l'option backup-user est passée de backrest à pgbackrest.
Dans la version v2.02 l'emplacement par défaut du fichier de configuration de pgBackRest a changé de /etc/pgbackrest.conf à /etc/pgbackrest/pgbackrest.conf. Si le fichier /etc/pgbackrest/pgbackrest.conf n'existe pas alors le fichier /etc/pgbackrest.conf sera chargé à la place, s'il existe.

De nombreux noms d'options ont été modifiés pour améliorer la cohérence, bien que les anciens noms de la version v1 soient toujours acceptés. De manière générale, les options db-* ont été renommées en pg-* et les options backup-*/retention-* ont été renommées en repo-* lorsque que celà été approprié.

Les options de PostgreSQL et du dépot de sauvegarde doivent être référencées lors de l'utilisation des nouveaux noms introduit par la version v2, (par exemple pour les options pg1-host, pg1-path, repo1-path, repo1-type, etc.). Un seul dépôt est autorisé actuellement mais une plus grande flexibilité est prévue pour la version v2.

Construction

Les paquets pour les distributions Debian/Ubuntu de pgBackRest sont disponible sur apt.postgresql.org. S'ils ne sont pas fournis pour votre distribution/version, il est facile de télécharger les sources et de l'installer manuellement

Lorsque l'on construit à partir des sources, il est préférable d'utiliser un système dédié à la construction plutôt que de le faire sur votre environnement de production. La plupart des outils nécessaires à la construction ne doivent généralement pas être installés sur un environnement de production. pgBackRest est composé d'un seul exécutable, il est donc facile de le copier vers votre enironnement de produition une fois construit.

build ⇒ Télécharger la version 2.27 de pgBackRest et extraire dans le répertoire de construction /build

wget -q -O - \
       https://github.com/pgbackrest/pgbackrest/archive/release/2.27.tar.gz | \
       tar zx -C /build

build ⇒ Installation et construction les dépendances

sudo apt-get install make gcc libpq-dev libssl-dev libxml2-dev pkg-config \
       liblz4-dev libzstd-dev libbz2-dev libz-dev

build ⇒ Configuration et compilation de pgBackRest

cd /build/pgbackrest-release-2.27/src && ./configure && make

Installation

Un nouvel hôte nommé pg1 est créé pour contenir l'instance de démonstration afin d'executer les exemples de pgBackRest.

pgBackRest doit être installé à partir d'un paquet ou installé manuellement comme indiqué ci-dessous.

build ⇒ Installation des dépendances

sudo apt-get install postgresql-client libxml2

pg-primary ⇒ Copiez les binaires de pgBackRest depuis la plateforme de compilation

sudo scp build:/build/pgbackrest-release-2.27/src/pgbackrest /usr/bin

sudo chmod 755 /usr/bin/pgbackrest

pgBackRest nécessite des répertoires pour les traces (logs) et pour la configuration ainsi qu'un fichier de configuration.

pg-primary ⇒ Création des répertoires et du fichier de configuration pour pgBackRest

sudo mkdir -p -m 770 /var/log/pgbackrest

sudo chown postgres:postgres /var/log/pgbackrest

sudo mkdir -p /etc/pgbackrest

sudo mkdir -p /etc/pgbackrest/conf.d

sudo touch /etc/pgbackrest/pgbackrest.conf

sudo chmod 640 /etc/pgbackrest/pgbackrest.conf

sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

pgBackRest devrait maintenant être correctement installé, mais il est préférable de le vérifier. Si des dépendances ont été omises, vous obtiendrez une erreur lorsque vous lancerez pgBackRest à partir de la ligne de commande.

pg-primary ⇒ S'assurer que l'installation a fonctionné

sudo -u postgres pgbackrest

pgBackRest 2.27 - General help

Usage:
    pgbackrest [options] [command]

Commands:
    archive-get     Get a WAL segment from the archive.
    archive-push    Push a WAL segment to the archive.
    backup          Backup a database cluster.
    check           Check the configuration.
    expire          Expire backups that exceed retention.
    help            Get help.
    info            Retrieve information about backups.
    restore         Restore a database cluster.
    stanza-create   Create the required stanza data.
    stanza-delete   Delete a stanza.
    stanza-upgrade  Upgrade a stanza.
    start           Allow pgBackRest processes to run.
    stop            Stop pgBackRest processes from running.
    version         Get version.

Use 'pgbackrest help [command]' for more information.

Démarrage rapide

La section Démarrage rapide couvre la configuration de base de pgBackRest et PostgreSQL. Elle présente les commandes backup, restore, et info.

6.1

Mise en place de l'instance de démonstration

La création de l'instance de démonstration est facultative mais fortement recommandée, en particulier pour les nouveaux utilisateurs. Les exemples de commande de ce guide font référence à cette instance de démonstration; les exemples sont fonctionnel sur une instance fonctionnant sur le port d'écoute par defaut (c'est-à-dire le port 5432). L'instance ne sera pas encore lancé, car il reste des actions de configuration à réaliser qui seront décrites dans la section suivante.

pg-primary ⇒ Création de l'instance de démonstation

sudo -u postgres /usr/lib/postgresql/10/bin/initdb \
       -D /var/lib/postgresql/10/demo -k -A peer

sudo pg_createcluster 10 demo

Configuring already existing cluster (configuration: /etc/postgresql/10/demo, data: /var/lib/postgresql/10/demo, owner: 106:110)
Ver Cluster Port Status Owner    Data directory              Log file
10  demo    5432 down   postgres /var/lib/postgresql/10/demo /var/log/postgresql/postgresql-10-demo.log

Par défaut, PostgreSQL n'accepte que les connexions locales. Les exemples présentés dans ce guide nécessiteront des connexions à partir d'autres serveurs ce qui implique de modifier le paramètre listen_addresses pour écouter sur toutes les interfaces. Ceci n'est peut être pas approprié pour les installations sécurisées.

pg-primary:/etc/postgresql/10/demo/postgresql.conf ⇒ Modification listen_addresses

listen_addresses = '*'

À des fins de démonstration, le paramètre log_line_prefix sera configuré au minimum. Cela permet de garder la sortie du journal aussi brève que possible pour mieux illustrer les informations importantes.

pg-primary:/etc/postgresql/10/demo/postgresql.conf ⇒ Modification de log_line_prefix

listen_addresses = '*'
log_line_prefix = ''

6.2

Configuration du dépots de sauvegarde (Stanza)

Un stanza est la configuration de la sauvegarde d'une instance PostgreSQL où est définit l'endroit où il se trouve, la façon dont il sera sauvegardé, les options d'archivage, etc... La plupart des serveurs de base de données n'auront qu'une seule instance PostgreSQL et donc un stanza alors que les serveurs de sauvegarde auront un stanza pour chaque instance de base de données qui doit être sauvegardé.

Il est tentant de nommer le stanza en référence à l'instance primaire, mais un meilleur nom décrirait les bases de données contenues dans l'instance : comme le nom du stanza sera utilisé pour le primaire et tous les secondaire, il est plus approprié de choisir un nom qui décrit la fonction réelle du groupe d'instances, comme app ou dw, plutôt que le nom local de l'instance, comme main ou prod.

Le nom 'demo' décrit assez bien l'objectif du dépot de données de sauvegarde (stanza). Ce qui en fera également un bon nom pour notre 'stanza'.

pgBackRestdoit savoir où se trouve le répertoire des données de base de l'instance PostgreSQL. Le chemin peut être directement obtenu auprès de PostgreSQL mais dans un scénario de restauration, le processus PostgreSQL ne sera pas disponible. Lors des sauvegardes, la valeur fournie à pgBackRest sera comparée au chemin sur lequel PostgreSQL est exécuté; ils doivent être égaux sinon la sauvegarde retournera une erreur. Assurez-vous que le parmaètre pg-path soit strictement égal au parmaètre data_directory du fichier postgresql.conf.

Par défaut sur Debian/Ubuntu le répertoire de l'instance est /var/lib/postgresql/[version]/[cluster] afin de déterminer facilement le chemin correct du repertoire de données.

Lors de la création du fichier /etc/pgbackrest/pgbackrest.conf le propriétaire de la base de données (généralement postgres) doit se voir accorder les privilèges de lecture.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration du réprtoire de donnée de PostgreSQL

[demo]
pg1-path=/var/lib/postgresql/10/demo

Led fichiers de configuration de pgBackRest suivent la convention Windows INI. Les sections sont indiquées par du texte entre parenthèses et des paires clé/valeur sont contenues dans chaque section. Les lignes commençant par # sont ignorées et peuvent être utilisées comme commentaires.

Les fichiers de configuration de pgBackRest peuvent être chargés de plusieurs façons :

config et config-include-path sont par défaut : le fichier de configuration par défaut sera chargé, s'il existe, et les fichiers *.conf dans le chemin d'inclusion de la configuration par défaut seront ajoutés, s'ils existent.
Lorsque l'option config est spécifiée : seul le fichier de configuration spécifié sera chargé et il devra exister.
Lorsque l'option config-include-path est spécifiée : Les fichiers *.conf dans le chemin d'inclusion de la configuration seront chargés et le chemin doit exister. Le fichier de configuration par défaut sera chargé s'il existe. Dans le cas où vous souhaitez ne charge que les fichiers du chemin d'inclusion alors l'option --no-config peut être ajoutée.
Lorsque l'option config est config-include-path sont spécifiées en utilisant les valeurs spécifiées par l'utilisateur, le fichier de configuration sera chargé et les fichiers *.conf du chemin d'inclusion de la configuration seront ajoutés. Les. Les fichiers doivent exister.
Lorsque l'option config-path est spécifié : ce paramètre remplacera le chemin de base pour l'emplacement par défaut du fichier de configuration et/ou le chemin de base du paramètre config-include-path par défaut, à moins que l'option config et/ou config-include-path ne soit explicitement définie.

Les fichiers sont concaténés comme s'il s'agissait d'un seul gros fichier ; 'ordre n'a pas d'importance, mais il y a une règle de classement basée sur les sections. is precedence based on sections. Ce classement est le suivant (du plus haut vers le plus bas) :

[stanza:command]
[stanza]
[global:command]
[global]

NOTE:

Les paramètres --config, --config-include-path et --config-path ne sont disponible qu'à partir de la ligne de commande.

pgBackRest peut également être configuré à l'aide de variables d'environnement comme décrit dans le document référentiel de commandes.

pg-primary ⇒ Configuration de log-path en utilisant les variables d'environnement

sudo -u postgres bash -c ' \
       export PGBACKREST_LOG_PATH=/path/set/by/env && \
       pgbackrest --log-level-console=error help backup log-path'

pgBackRest 2.27 - 'backup' command - 'log-path' option help

Path where log files are stored.

The log path provides a location for pgBackRest to store log files. Note that
if log-level-file=off then no log path is required.

current: /path/set/by/env

default: /var/log/pgbackrest

6.3

Création du dépot de sauvegarde

Le dépôt est l'endroit où pgBackRest stocke les sauvegardes et archive les segments des journaux de transaction (WAL).

Il peut être difficile d'estimer à l'avance l'espace dont vous aurez besoin. La meilleure chose à faire est de prendre quelques sauvegardes puis d'enregistrer la taille des différents types de sauvegardes (full/incr/diff) et de mesurer la quantité de WAL générée par jour. Cela vous donnera une idée générale de l'espace dont vous aurez besoin, même si, bien sûr, les besoins changeront probablement au fil du temps, à fur et à mesure de l'évolution de votre base de données.

Pour cette démonstration, le dépôt sera stocké sur le même hôte que le serveur de l'instance PostgreSQL. Cette configuration est la plus simple et est utile dans les cas où un logiciel de sauvegarde traditionnel est utilisé pour sauvegarder l'hôte de la base de données.

pg-primary ⇒ Création du dépot de sauvegarde pour pgBackRest

sudo mkdir -p /var/lib/pgbackrest

sudo chmod 750 /var/lib/pgbackrest

sudo chown postgres:postgres /var/lib/pgbackrest

Le chemin du dépôt doit être configuré de telle sorte pour que pgBackRest sache où le trouver.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de répertoire du dépots de sauvegarde de pgBackRest

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
repo1-path=/var/lib/pgbackrest

6.4

Configuration de l'archivage

La sauvegarde d'une instance de PostgreSQL requiert que l'archivage des journaux de transaction (WAL) soit activé. Notez qu'au moins un segment de WAL sera créé pendant le processus de sauvegarde et ceux même si aucune écriture explicite n'est effectuée sur votre instance.

pg-primary:/etc/postgresql/10/demo/postgresql.conf ⇒ Configuration des paramètres d'archivage

archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
listen_addresses = '*'
log_line_prefix = ''
max_wal_senders = 3
wal_level = replica

Régler le paramètre wal_level sur le niveau au minimum la valeur replica et augmenter la valeur de max_wal_senders est une bonne pratique, puisque celà vous permettra d'ajouter plus tard des esclaves sans pour autant devoir redémarrer votre instance principale.

L'instance PostgreSQL doit être redémarré après avoir effectué ces modifications et avant d'effectuer une sauvegarde.

pg-primary ⇒ Redémarrage de l'instance demo

sudo pg_ctlcluster 10 demo restart

Lorsque l'archivage d'un segment du journal de transaction (WAL) est censé prendre plus de 60 secondes (par défaut) pour atteindre le dépôt de sauvegarde de pgBackRest, le paramètre archive-timeout de la configuration de pgBackRest doit être augmenté. Notez bien que ce paramètre n'est pas le même que celui présent dans la configuration de PostgreSQL : archive_timeout, qui lui permet de forcer le changement d'un segment du journal de transaction (WAL) afin de forcer un archivage. Ceci est utile sur les bases de données ayant de longue périodes d'inactivité en écriture. Pour plus d'information concernant l'option archive_timeout de PostgreSQL , consultez la documentation PostgreSQL Write Ahead Log.

La commande archive-push peut être configurée avec ses propres options. Par exemple, un niveau de compression inférieur peut être défini pour accélérer l'archivage des WAL sans affecter la compression utilisée pour les sauvegardes.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de archive-push afin d'utiliser un niveau de compression inférieur

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
repo1-path=/var/lib/pgbackrest

[global:archive-push]
compress-level=3

Cette technique de configuration peut être utilisée pour n'importe quelle commande et peut même cibler un 'stanza' spécifique, exemple : demo:archive-push.

6.5

Configuration de la retention

L'expiration des sauvagarde pgBackRest se base sur les options de rétention.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurer la rétention à 2 sauvegardes complètes

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2

[global:archive-push]
compress-level=3

Pour plus d'informations sur la rétention, voir la section sur la Retention.

6.6

Configuration du chiffrement du dépôt de sauvegarde

Le dépôt de sauvegarde sera configuré avec un type de chiffrement (cipher) et une clé. Le chiffrement est toujours effectué côté client même si le type de dépôt (par exemple S3 ou autre magasin d'objets) prend en charge le chiffrement.

Il est important d'utiliser une phrase de chiffrement longue et aléatoire pour la clé de chiffrement. Une bonne façon d'en générer une est d'exécuter la commande : openssl rand -base64 48.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration du dépot de sauvegarde chiffré pgBackRest

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type=aes-256-cbc
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2

[global:archive-push]
compress-level=3

Une fois que le dépôt de sauvegarde a été configuré et que celui-ci a été créée et vérifiée, les paramètres de chiffrement du dépôt ne peuvent plus être modifiés.

6.7

Création du dépot de sauvegarde (Stanza)

La commande stanza-create doit être exécutée sur l'hôte où se trouve le dépôt pour initialiser le dépot de sauvegarde. Il est recommandé d'exécuter la commande check après avoir exécuté stanza-create pour s'assurer que l'archivage et les sauvegardes sont correctement configurés.

pg-primary ⇒ Création du dépot de sauvegarde et configuration

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create

P00   INFO: stanza-create command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo

P00   INFO: stanza-create command end: completed successfully

6.8

Vérification de la configuration

La commande check valide que pgBackRest et le paramétre archive_command sont configurés correctement pour l'archivage et les sauvegardes. Il détecte d'éventuelles erreurs de configuration, en particulier pour l'archivage. Une mauvaise configuration de l'archivage se traduit par des sauvegardes incomplètes : les segments WAL requis n'étant pas parvenus aux archives. La commande peut être exécutée sur le serveur de l'instance de la base de données ou sur le serveur du dépôt de sauvegarde. La commande peut également être exécutée sur l'hôte secondaire (standby), mais comme les commandes pg_switch_xlog()/pg_switch_wal() ne peut pas être exécuté sur une instance secondaire, la commande ne testera que la configuration du dépôt.

Notez que pg_create_restore_point('pgBackRest Archive Check') et pg_switch_xlog()/pg_switch_wal() sont appelés pour forcer PostgreSQL à archiver un segment WAL. Les points de restauration ne sont supportés que dans PostgreSQL >= 9.1; Pour les versions plus anciennes, la commande check peut échouer s'il n'y a pas eu d'activité d'écriture depuis la dernière rotation du journal, il est donc recommandé que l'activité soit générée par l'utilisateur s'il n'y a pas eu d'écriture depuis le dernier changement de WAL avant l'exécution de la commande check

pg-primary ⇒ Vérification de la configuration

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check

P00   INFO: check command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --stanza=demo

P00   INFO: WAL segment 000000010000000000000001 successfully archived to '/var/lib/pgbackrest/archive/demo/10-1/0000000100000000/000000010000000000000001-5317f0861897ba330ae8292d6d07e120f6d3263f.gz'

P00   INFO: check command end: completed successfully

6.9

Effectuer une sauvegarde

Pour effectuer une sauvegarde de l'instance PostgreSQL, lancez pgBackRest avec la commande backup.

pg-primary ⇒ sauvegarde de l'instance demo

sudo -u postgres pgbackrest --stanza=demo \
       --log-level-console=info backup

P00   INFO: backup command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

P00   WARN: no prior backup exists, incr backup has been changed to full

P00   INFO: execute non-exclusive pg_start_backup(): backup begins after the next regular checkpoint completes
P00   INFO: backup start archive = 000000010000000000000002, lsn = 0/2000028
       [filtered 941 lines of output]
P01   INFO: backup file /var/lib/postgresql/10/demo/base/1/12822 (0B, 100%)
P01   INFO: backup file /var/lib/postgresql/10/demo/base/1/12817 (0B, 100%)

P00   INFO: full backup size = 22.5MB

P00   INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
P00   INFO: backup stop archive = 000000010000000000000002, lsn = 0/2000130
       [filtered 4 lines of output]

Par défaut, pgBackRest tentera d'effectuer une sauvegarde incrémentielle. Cependant, une sauvegarde incrémentielle doit être basée sur une sauvegarde complète et comme il n'y a pas de sauvegarde complète, pgBackRest effectue une sauvegarde complète à la place.

L'option type peut être utilisée pour spécifier une sauvegarde complète ou différentielle.

pg-primary ⇒ Sauvegarde différentielle de l'instance demo

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup

       [filtered 4 lines of output]
P01   INFO: backup file /var/lib/postgresql/10/demo/global/pg_control (8KB, 99%) checksum ee410d8bc3dc0316381300064b4a6e05868fa3bd
P01   INFO: backup file /var/lib/postgresql/10/demo/pg_logical/replorigin_checkpoint (8B, 100%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532

P00   INFO: diff backup size = 8KB

P00   INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
P00   INFO: backup stop archive = 000000010000000000000003, lsn = 0/30000F8
       [filtered 4 lines of output]

Cette fois, il n'y a pas eu d'avertissement car une sauvegarde complète existait déjà. Alors que les sauvegardes incrémentielles peuvent être basées sur une sauvegarde complète ou différentielle, les sauvegardes différentielles doivent être basées sur une sauvegarde complète. Une sauvegarde complète peut être effectuée en exécutant la commande backup avec --type=full.

Vous trouverez plus d'informations sur la commande backup dans la section Sauvegarde.

6.10

Planifier une sauvegarde

Des sauvegardes peuvent être programmées avec des utilitaires tels que cron.

Dans l'exemple suivant, deux tâches 'cron' sont configurés pour fonctionner; les sauvegardes complètes sont programmées à 6h30 tous les dimanches, les sauvegardes différentielles à 6h30 du lundi au samedi. Si cette crontab est installée pour la première fois en milieu de semaine, alors pgBackRest exécutera une sauvegarde complète la première fois que le job différentiel est exécuté, suivi le lendemain par une sauvegarde différentielle.

#m h   dom mon dow   command
30 06  *   *   0     pgbackrest --type=full --stanza=demo backup
30 06  *   *   1-6   pgbackrest --type=diff --stanza=demo backup

Une fois que les sauvegardes sont programmées, il est important de configurer la conservation de manière à ce que les sauvegardes expirent selon un calendrier définit, voir la section Retention.

6.11

Informations sur les sauvegardes

Utilisez la commande info pour obtenir des informations sur les sauvegardes.

pg-primary ⇒ Obtenir des informations pour l'instance demo

sudo -u postgres pgbackrest info

stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (10-1): 000000010000000000000001/000000010000000000000003

        full backup: 20200526-001729F

            timestamp start/stop: 2020-05-26 00:17:29 / 2020-05-26 00:17:42
            wal start/stop: 000000010000000000000002 / 000000010000000000000002
            database size: 22.5MB, backup size: 22.5MB
            repository size: 2.7MB, repository backup size: 2.7MB

        diff backup: 20200526-001729F_20200526-001744D

            timestamp start/stop: 2020-05-26 00:17:44 / 2020-05-26 00:17:45
            wal start/stop: 000000010000000000000003 / 000000010000000000000003
            database size: 22.5MB, backup size: 8.2KB
            repository size: 2.7MB, repository backup size: 496B
            backup reference list: 20200526-001729F

Chaque dépôts de sauvegarde a une section séparée et il est possible de limiter la sortie à un seul dépôt avec l'option --stanza. L'indicateur status donne une brève information sur l'état de santé du dépôt. S'il est à ok, alors le pgBackRest fonctionne normalement. La ligne wal min/max indique les valeurs minimales et maximales des journaux de transaction (WAL) actuellement stockées dans le dépôt de sauvegarde. Notez qu'il peut y avoir des trous en raison des politiques de conservation des archives ou pour d'autres raisons.

Le message 'backup/expire running' apparaîtra à côté de l'information 'status' si l'une de ces commandes est en cours d'exécution sur l'hôte.

Les sauvegardes sont affichées du plus ancien au plus récent. La sauvegarde la plus ancienne sera toujours une sauvegarde complète (indiquée par un F à la fin de l'étiquette) mais la sauvegarde la plus récente peut être complète, différentielle (se termine par D), ou incrémentale (se termine par I).

La ligne 'timestamp start/stop' (horodatage de début/arrêt) définit la période pendant laquelle la sauvegarde s'est déroulée. Le paramètre timestamp stop peut être utilisé pour déterminer quelle sauvegarde serait à utiliser lors d'une restauration PITR. Vous trouverez plus d'informations sur la restauration PITR dans la section Récupération au point d'origine (PITR).

La ligne wal start/stop définit la plage de WAL qui est nécessaire pour rendre la base de données cohérente lors de la restauration. La commande backup s'assure que cette plage de WAL se trouve bien dans le dépôt de sauvegarde avant de se terminer.

L'information 'database size' (taille de la base de données) correspond à la taille totale non compressée de la base de données, tandis que l'information 'backup size' (taille de la sauvegarde) correspond à la quantité de données effectivement sauvegardées (ces informations seront les mêmes pour les sauvegardes complètes). L'information repository size inclut tous les fichiers de cette sauvegarde et toutes les sauvegardes référencées qui sont nécessaires pour restaurer la base de données, tandis que l'information repository backup size (taille du dépôt de sauvegarde) n'inclut que les fichiers de cette sauvegarde (ces informations seront également les mêmes pour les sauvegardes complètes). La taille des dépôts reflète la taille des fichiers compressés si la compression est activée dans pgBackRest ou dans le système de fichiers.

La ligne backup reference list (liste de référence des sauvegardes) contient les sauvegardes supplémentaires qui sont nécessaires pour restaurer cette sauvegarde.

6.12

Restauration d'une sauvegarde

Les sauvegardes peuvent vous protéger contre de nombre de scénarios catastrophe, dont les plus courants sont une pannes matérielles et une corruption des données. La façon la plus simple de simuler une corruption de données est de supprimer un fichier important de l'instance PostgreSQL.

pg-primary ⇒ Arrêt de l'instance demo et suppression du fichier pg_control

sudo pg_ctlcluster 10 demo stop

sudo -u postgres rm /var/lib/postgresql/10/demo/global/pg_control

Le démarrage de l'instance PostgreSQL sans ce fichier entraînera une erreur.

pg-primary ⇒ Tentative de démarrage de l'instance demo corrompue

sudo pg_ctlcluster 10 demo start

Error: /usr/lib/postgresql/10/bin/pg_ctl /usr/lib/postgresql/10/bin/pg_ctl start -D /var/lib/postgresql/10/demo -l /var/log/postgresql/postgresql-10-demo.log -s -o  -c config_file="/etc/postgresql/10/demo/postgresql.conf"  exited with status 1:

postgres: could not find the database system

Expected to find it in the directory "/var/lib/postgresql/10/demo",
but could not open file "/var/lib/postgresql/10/demo/global/pg_control": No such file or directory
Examine the log output.

Pour restaurer une sauvegarde de l'instance PostgreSQL, lancez pgBackRest avec la commande restore. L'instance doit être arrêté (dans ce cas, elle l'est déjà ) et tous les fichiers doivent être supprimés du répertoire de données PostgreSQL.

pg-primary ⇒ Suppression des anciens fichier de l'instance demo

sudo -u postgres find /var/lib/postgresql/10/demo -mindepth 1 -delete

pg-primary ⇒ Restauration et démarrage de l'instance PostgreSQL demo

sudo -u postgres pgbackrest --stanza=demo restore

sudo pg_ctlcluster 10 demo start

Cette fois, le cluster a démarré avec succès puisque la restauration a remplacé le fichier pg_control.

Vous trouverez plus d'informations sur la commande restore dans la section Restauration..

Sauvegarde

La section Sauvegarde introduit des fonctionnalités supplémentaires de la commande backup.

7.1

Option de démarrage rapide

Par défaut, pgBackRest attendra le prochain point de contrôle régulier (Checkpoint) avant de commencer une sauvegarde. En fonction des paramètres checkpoint_timeout et checkpoint_segments de PostgreSQL, il peut s'écouler un certain temps avant qu'un point de contrôle soit terminé et que la sauvegarde puisse commencer.

pg-primary ⇒ Sauvegarde incrémentale de l'instance demo avec le point de contrôle régulièrement programmé

sudo -u postgres pgbackrest --stanza=demo --type=incr \
       --log-level-console=info backup

P00   INFO: backup command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo --type=incr
P00   INFO: last backup label = 20200526-001729F_20200526-001744D, version = 2.27

P00   INFO: execute non-exclusive pg_start_backup(): backup begins after the next regular checkpoint completes

P00   INFO: backup start archive = 000000020000000000000005, lsn = 0/5000028
P00   WARN: a timeline switch has occurred since the 20200526-001729F_20200526-001744D backup, enabling delta checksum
       [filtered 8 lines of output]

Lorsque --start-fast est transmis sur la ligne de commande ou que start-fast=y est défini dans le fichier de configuration /etc/pgbackrest/pgbackrest.conf, un point de contrôle (checkpoint) immédiat est demandé sur l'instance PostgreSQL et la sauvegarde démarre plus rapidement. C'est utile pour les tests et les sauvegardes exceptionnelles. Par exemple, si une sauvegarde est effectuée avant une plage de mainteance pour mise à jours, il est inutile d'attendre le prochain point de contrôle et donc il est utile de le forcer. Comme les sauvegardes planifiées ne se font généralement qu'une fois par jour, il est improbable que l'activation de start-fast (démarrage rapide) dans /etc/pgbackrest/pgbackrest.conf affecte négativement les performances. Cependant pour les systèmes à grand volume transctionnels, vous pouvez vouloir passer --start-fast sur la ligne de commande à la place. Il est également possible d'ignorer le paramètre du fichier de configuration en utilisant le paramètre --no-start-fast de la ligne de commande.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Activation du paramètre start-fast

pg-primary ⇒ Sauvegarde incrémentale de l'instance demo avec un point de contrôle immédiat (immediat checkpoint)

sudo -u postgres pgbackrest --stanza=demo --type=incr \
       --log-level-console=info backup

P00   INFO: backup command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo --start-fast --type=incr
P00   INFO: last backup label = 20200526-001729F_20200526-001802I, version = 2.27

P00   INFO: execute non-exclusive pg_start_backup(): backup begins after the requested immediate checkpoint completes

P00   INFO: backup start archive = 000000020000000000000006, lsn = 0/6000028
P01   INFO: backup file /var/lib/postgresql/10/demo/global/pg_control (8KB, 99%) checksum d2086dddf6d84d1ed93e32900eec3ac7b988a40c
       [filtered 8 lines of output]

7.2

Timeout des archives

Lors d'une sauvegarde à chaud, pgBackRest attend que les segments WAL qui sont nécessaires à la cohérence de la sauvegarde soient archivés. Ce temps d'attente est régi par l'option pgBackRest archive-timeout dont la valeur par défaut est de 60 secondes. Si l'on sait que l'archivage d'un segment individuel prend plus de temps, cette option doit être augmentée.

Supervision

La supervision est un élément important de tout système de production. De nombreux outils sont disponibles et il est possible de contrôler n'importe lequel d'entre eux avec un peu de travail.

pgBackRest peut produire des informations sur le dépôt au format JSON qui comprend une liste de toutes les sauvegardes pour chaque dépots de sauvegardes et des informations sur les archives WAL.

8.1

Dans PostgreSQL

La commande PostgreSQL COPY permet de charger les informations pgBackRest dans un tableau. L'exemple suivant résume cette logique dans une fonction qui peut être utilisée pour effectuer des requêtes en temps réel.

pg-primary ⇒ Charger la fonction d'information de pgBackRest dans PostgreSQL

sudo -u postgres cat \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql

-- An example of monitoring pgBackRest from within PostgreSQL
--
-- Use copy to export data from the pgBackRest info command into the jsonb
-- type so it can be queried directly by PostgreSQL.

-- Create monitor schema
create schema monitor;

-- Get pgBackRest info in JSON format
create function monitor.pgbackrest_info()
    returns jsonb AS $$
declare
    data jsonb;
begin
    -- Create a temp table to hold the JSON data
    create temp table temp_pgbackrest_data (data jsonb);

    -- Copy data into the table directly from the pgBackRest info command
    copy temp_pgbackrest_data (data)
        from program
            'pgbackrest --output=json info' (format text);

    select temp_pgbackrest_data.data
      into data
      from temp_pgbackrest_data;

    drop table temp_pgbackrest_data;

    return data;
end $$ language plpgsql;

sudo -u postgres psql -f \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-info.sql

Vous pouvez à présent utiliser la fonction monitor.pgbackrest_info() pour déterminer la dernière sauvegarde réussie et les WAL archivés pour un dépots de sauvegarde.

pg-primary ⇒ Interroger la dernière sauvegarde réussie et les WAL archivés

sudo -u postgres cat \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql

-- Get last successful backup for each stanza
--
-- Requires the monitor.pgbackrest_info function.
with stanza as
(
    select data->'name' as name,
           data->'backup'->(
               jsonb_array_length(data->'backup') - 1) as last_backup,
           data->'archive'->(
               jsonb_array_length(data->'archive') - 1) as current_archive
      from jsonb_array_elements(monitor.pgbackrest_info()) as data
)
select name,
       to_timestamp(
           (last_backup->'timestamp'->>'stop')::numeric) as last_successful_backup,
       current_archive->>'max' as last_archived_wal
  from stanza;

sudo -u postgres psql -f \
       /var/lib/postgresql/pgbackrest/doc/example/pgsql-pgbackrest-query.sql

  name  | last_successful_backup |    last_archived_wal     
--------+------------------------+--------------------------
 "demo" | 2020-05-26 00:18:07+00 | 000000020000000000000006
(1 row)

8.2

Utilisez la commande jq

jq est un utilitaire en ligne de commande qui peut facilement extraire des données de JSON.

pg-primary ⇒ Installer l'utilitaire jq

sudo apt-get install jq

Vous pouvez maintenant utiliser jq pour obtenir le temps mis par la dernière sauvegarde réussit pour un dépot de sauvegarde

pg-primary ⇒ Interroger le temps pris par la denière sauvegarde réussi

sudo -u postgres pgbackrest --output=json --stanza=demo info | \
       jq '.[0] | .backup[-1] | .timestamp.stop'

1590452287

Ou pour le dernier WAL archivé.

pg-primary ⇒ Interroger pour obtenir le nom du dernier WAL archivé

sudo -u postgres pgbackrest --output=json --stanza=demo info | \
       jq '.[0] | .archive[-1] | .max'

"000000020000000000000006"

NOTE:

Cette syntaxe exige jq v1.5.

NOTE:

jq peut arrondir de grands nombres tels que les identificateurs de système. Testez vos requêtes avec soin vos requêtes avant de les mettres en production.

Rétention

En général, il est préférable de conserver autant de sauvegardes que possible afin d'offrir une plus grande fenêtre de récupération par PITR, mais il faut également tenir compte de préoccupations pratiques telles que l'espace disque. Les options de conservation permettent de supprimer les anciennes sauvegardes lorsqu'elles ne sont plus nécessaires.

9.1

Conservation de la sauvegarde complète

Le paramètre repo1-retention-full-type détermine comment l'option repo1-retention-full est interprétée ; soit le nombre de sauvegardes complètes à conserver, soit le nombre de jours de conservation des sauvegardes complètes. Les nouvelles sauvegardes doivent être effectuées avant leur expiration; Cela signifie que si repo1-retention-full-type=count et repo1-retention-full=2 alors il y aura trois sauvegardes complètes stockées avant que la plus ancienne n'expire, ou si repo1-retention-full-type=time et repo1-retention-full=20 alors il doit y avoir une sauvegarde complète datant d'au moins 20 jours avant l'expiration.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de l'option repo1-retention-full

Le paramètre est fixé à repo1-retention-full=2 mais actuellement il n'y a qu'une seule sauvegarde complète de sorte que la prochaine sauvegarde complète qui sera exécutée ne fera expirer aucune autre sauvegarde complète.

pg-primary ⇒ Effectuer une sauvegarde complète

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=detail backup

       [filtered 952 lines of output]
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.27: --log-level-console=detail --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

P00 DETAIL: archive retention on backup 20200526-001729F, archiveId = 10-1, start = 000000010000000000000002
P00 DETAIL: remove archive: archiveId = 10-1, start = 000000010000000000000001, stop = 000000010000000000000001

P00   INFO: expire command end: completed successfully

Des archives ont expiré puisque des segments WAL ont été générés avant la plus ancienne sauvegarde. Ils ne sont pas utiles pour la restauration &mdash ; seuls les segments WAL générés après une sauvegarde peuvent être utilisés lors de la restauration de cette sauvegarde.

pg-primary ⇒ Effectuer une sauvegarde complète

sudo -u postgres pgbackrest --stanza=demo --type=full \
       --log-level-console=info backup

       [filtered 951 lines of output]
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-full=2 --stanza=demo

P00   INFO: expire full backup set: 20200526-001729F, 20200526-001729F_20200526-001744D, 20200526-001729F_20200526-001802I, 20200526-001729F_20200526-001805I

P00   INFO: remove expired backup 20200526-001729F_20200526-001805I
P00   INFO: remove expired backup 20200526-001729F_20200526-001802I
       [filtered 2 lines of output]

La sauvegarde complète 20200526-001729F a expiré et la conservation des archives est basée sur la sauvegarde 20200526-001813F qui est désormais la plus ancienne sauvegarde complète.

9.2

Rétention de la sauvegarde différentielle

Modifiez repo1-retention-diff sur le nombre de sauvegardes différentielles souhaitées. Les sauvegardes différentiels ne reposent que sur la sauvegarde complète antérieure, de sorte qu'il est possible de créer un ensemble de sauvegardes différentielles pour le dernier jour ou plus. Cela permet de restaurer rapidement vers un point de sauvegarde dans le temps (points-in-time) mais diminue la quantité globale d'espace disponible.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de repo1-retention-diff

La sauvegarde effectuera repo1-retention-diff=1 donc deux différentiels devront être réalisés avant que l'un d'entre eux ne soit expiré. Une sauvegarde incrémentale est ajoutée pour illustrer l'expiration incrémentale. Les sauvegardes incrémentales ne peuvent pas expirer de façon individuelle &mdash ; elles expirent toujours avec leur sauvegarde complète ou différentielle correspondante.

pg-primary ⇒ Effectuer des sauvegardes différentielles et incrémentales

sudo -u postgres pgbackrest --stanza=demo --type=diff backup

sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Le fait de procéder maintenant à une sauvegarde différentielle fera expirer les sauvegardes différentielles et incrémentales précédentes, ne laissant qu'une seule sauvegarde différentielle.

pg-primary ⇒ Effectuer une sauvegarde différentielle

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup

       [filtered 11 lines of output]
P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-diff=1 --repo1-retention-full=2 --stanza=demo

P00   INFO: expire diff backup set: 20200526-001828F_20200526-001843D, 20200526-001828F_20200526-001846I

P00   INFO: remove expired backup 20200526-001828F_20200526-001846I
P00   INFO: remove expired backup 20200526-001828F_20200526-001843D

9.3

Rétention des archives

Bien que pgBackRest supprime automatiquement les segments WAL archivés lors de l'expiration des sauvegardes (la valeur par défaut d'expiration des WAL pour les sauvegardes complètes se base sur l'option repo1-retention-full), il peut être utile de faire expirer les archives de manière plus agressive pour économiser de l'espace disque. Notez que les sauvegardes complètes sont considérées comme des sauvegardes différentielles dans le but d'une conservation différentielle des archives.

Les archives qui expirent ne supprimeront jamais les segments de WAL qui sont nécessaires pour rendre une sauvegarde cohérente. Toutefois, étant donné que la récupération ponctuelle (PITR) ne fonctionne que sur un flux WAL continu, il convient d'être prudent en cas d'expiration agressive des archives en dehors du processus normal d'expiration des sauvegardes.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de repo1-retention-diff

pg-primary ⇒ Effectuer une sauvegarde différentielle

sudo -u postgres pgbackrest --stanza=demo --type=diff \
       --log-level-console=info backup

       [filtered 8 lines of output]
P00   INFO: backup stop archive = 000000020000000000000011, lsn = 0/110000F8
P00   INFO: check archive for segment(s) 000000020000000000000011:000000020000000000000011

P00   INFO: new backup label = 20200526-001828F_20200526-001854D

P00   INFO: backup command end: completed successfully
P00   INFO: expire command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-diff=2 --repo1-retention-full=2 --stanza=demo

pg-primary ⇒ Expire archive

sudo -u postgres pgbackrest --stanza=demo --log-level-console=detail \
       --repo1-retention-archive-type=diff --repo1-retention-archive=1 expire

P00   INFO: expire command begin 2.27: --log-level-console=detail --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/var/lib/pgbackrest --repo1-retention-archive=1 --repo1-retention-archive-type=diff --repo1-retention-diff=2 --repo1-retention-full=2 --stanza=demo
P00 DETAIL: archive retention on backup 20200526-001813F, archiveId = 10-1, start = 000000020000000000000008, stop = 000000020000000000000008
P00 DETAIL: archive retention on backup 20200526-001828F, archiveId = 10-1, start = 00000002000000000000000A, stop = 00000002000000000000000A

P00 DETAIL: archive retention on backup 20200526-001828F_20200526-001849D, archiveId = 10-1, start = 00000002000000000000000E, stop = 00000002000000000000000E

P00 DETAIL: archive retention on backup 20200526-001828F_20200526-001854D, archiveId = 10-1, start = 000000020000000000000011

P00 DETAIL: remove archive: archiveId = 10-1, start = 000000020000000000000009, stop = 000000020000000000000009
P00 DETAIL: remove archive: archiveId = 10-1, start = 00000002000000000000000B, stop = 00000002000000000000000D
P00 DETAIL: remove archive: archiveId = 10-1, start = 00000002000000000000000F, stop = 000000020000000000000010

P00   INFO: expire command end: completed successfully

La sauvegarde différentielle 20200526-001828F_20200526-001849D a archivé des segments WAL qui doivent être conservés pour rendre les anciennes sauvegardes cohérentes même si elles ne peuvent pas être jouées ultérieurement avec PITR. Les segments WAL générés après la sauvegarde 20200526-001828F_20200526-001849D mais avant 20200526-001828F_20200526-001854D sont supprimés. Les segments WAL générés après la nouvelle sauvegarde 20200526-001828F_20200526-001854D sont conservés et peuvent être utilisés pour le PITR.

Étant donné que les sauvegardes complètes sont considérées comme des sauvegardes différentielles pour la conservation différentielle des archives, si une sauvegarde complète est maintenant effectuée avec les mêmes paramètres, seule l'archive de cette sauvegarde complète est conservée pour PITR.

Restauration

La section Restauration introduit des fonctionnalités supplémentaires de la commande restore.

10.1

Propriétaire du fichier

Lorsqu'un restore est exécuté en tant qu'utilisateur non root (scénario typique), tous les fichiers restaurés appartiendront à l'utilisateur/groupe qui exécute le pgBackRest. Si les fichiers existants ne sont pas la propriété de l'utilisateur/groupe en cours d'exécution, une erreur se produira si le propriétaire ne peut pas être mise à jour pour l'utilisateur/groupe en cours d'exécution. Dans ce cas, la propriété du fichier devra être mise à jour par un utilisateur privilégié avant que la restauration ne puisse être réexécutée.

Lorsqu'un restore est exécuté en tant qu'utilisateur root, le pgBackRest tentera de recréer la propriété enregistrée dans le manifeste de la sauvegarde. Seuls les noms des utilisateurs/groupes sont stockés dans le manifeste, de sorte que les mêmes noms doivent exister sur l'hôte de restauration pour que cela fonctionne. Si le nom de l'utilisateur/groupe ne peut être trouvé localement, l'utilisateur/groupe du répertoire de données PostgreSQL sera utilisé et enfin si l'utilisateur/groupe du répertoire de données ne peut être associé à un nom, root sera utilisé.

10.2

Option de Delta

Dans la section Restauration d'une sauvegarde du Guide de démarrage rapide a exigé que le répertoire de l'instance soit vidé avant d'effectuer le restore. L'option delta permet à pgBackRest de déterminer automatiquement quels fichiers du répertoire de l'instance de base de données peuvent être préservés et lesquels doivent être restaurés à partir de la sauvegarde &mdash ; elle permet également de supprimer les fichiers non présents dans le manifeste de sauvegarde afin de se débarrasser des modifications divergeantes. Cette opération est réalisée en calculant un hachage cryptographique SHA-1 sur chacun des fichiers présents dans le répertoire de données de l'instance. Si le hachage SHA-1 ne correspond pas au hachage stocké dans la sauvegarde, le fichier sera restauré. Cette opération est très efficace lorsqu'elle est combinée avec l'option process-max. Étant donné que le serveur PostgreSQL est arrêté pendant la restauration, il est possible d'utiliser un plus grand nombre de processus que ce qui pourrait être envisagé durant une sauvegarde (lorsque l'instance PostgreSQL est en cours d'exécution).

pg-primary ⇒ Arrêt de l'instance demo, effectuer une restauration delta

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta \
       --log-level-console=detail restore

       [filtered 2 lines of output]
P00 DETAIL: check '/var/lib/postgresql/10/demo' exists
P00 DETAIL: remove 'global/pg_control' so cluster will not start if restore does not complete

P00   INFO: remove invalid files/links/paths from '/var/lib/postgresql/10/demo'

P00 DETAIL: remove invalid file '/var/lib/postgresql/10/demo/backup_label.old'
P00 DETAIL: remove invalid file '/var/lib/postgresql/10/demo/base/1/pg_internal.init'
       [filtered 755 lines of output]
P01 DETAIL: restore file /var/lib/postgresql/10/demo/base/12979/PG_VERSION - exists and matches backup (3B, 99%) checksum 4143d3a341877154d6e95211464e1df1015b74bd
P01 DETAIL: restore file /var/lib/postgresql/10/demo/base/1/PG_VERSION - exists and matches backup (3B, 99%) checksum 4143d3a341877154d6e95211464e1df1015b74bd

P01 DETAIL: restore file /var/lib/postgresql/10/demo/PG_VERSION - exists and matches backup (3B, 100%) checksum 4143d3a341877154d6e95211464e1df1015b74bd

P01 DETAIL: restore file /var/lib/postgresql/10/demo/global/6100_vm - exists and is zero size (0B, 100%)
P01 DETAIL: restore file /var/lib/postgresql/10/demo/global/6100 - exists and is zero size (0B, 100%)
       [filtered 232 lines of output]

pg-primary ⇒ Redémarrage de PostgreSQL

sudo pg_ctlcluster 10 demo start

10.3

Restaurer des bases de données sélectionnées

Dans certains cas, il peut être intéressant de restaurer de façon sélective des bases de données spécifiques à partir d'une sauvegarde d'instance. Cela peut être fait pour des raisons de performance ou pour déplacer les bases de données sélectionnées vers une machine qui n'a pas assez d'espace pour restaurer l'ensemble de la sauvegarde de l'instance

Pour illustrer cette fonctionnalité, deux bases de données sont créées : test1 et test2. Une nouvelle sauvegarde est effectuée afin que pgBackRest soit informé des nouvelles bases de données.

pg-primary ⇒ Créer deux bases de données de test et effectuer une sauvegarde

sudo -u postgres psql -c "create database test1;"

CREATE DATABASE

sudo -u postgres psql -c "create database test2;"

CREATE DATABASE

sudo -u postgres pgbackrest --stanza=demo --type=incr backup

Chaque base de données de test sera alimentée par des tables et des données pour illustrer que la restauration fonctionne avec une restauration sélective.

pg-primary ⇒ Créer une table de test dans chaque base de données

sudo -u postgres psql -c "create table test1_table (id int); \
       insert into test1_table (id) values (1);" test1

INSERT 0 1

sudo -u postgres psql -c "create table test2_table (id int); \
       insert into test2_table (id) values (2);" test2

INSERT 0 1

L'une des principales raisons de recourir à la restauration sélective est le gain d'espace. La taille de la base de données test1 est indiquée ici afin de pouvoir la comparer avec l'utilisation du disque après une restauration sélective.

pg-primary ⇒ Afficher l'espace utilisé par la base de données test1

sudo -u postgres du -sh /var/lib/postgresql/10/demo/base/24576

7.5M	/var/lib/postgresql/10/demo/base/24576

Si la base de données à restaurer n'est pas connue, utilisez l'option de commande info command set pour découvrir les bases de données qui font partie du jeu de sauvegarde.

pg-primary ⇒ Afficher la liste des bases de données de la sauvegarde

sudo -u postgres pgbackrest --stanza=demo \
       --set=20200526-001828F_20200526-001904I info

       [filtered 11 lines of output]
            repository size: 4.4MB, repository backup size: 1.8MB
            backup reference list: 20200526-001828F, 20200526-001828F_20200526-001854D

            database list: postgres (12980), test1 (24576), test2 (24577)

Arrêtez l'instance et ne restaurez que la base de données test2. Les bases de données intégrées (template0, template1, et postgres) sont toujours restaurées.

pg-primary ⇒ Restauration de la dernière sauvegarde incluant uniquement la base de données test2

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta \
       --db-include=test2 restore

sudo pg_ctlcluster 10 demo start

Une fois la récupération terminée, la base de données test2 contiendra toutes les tables et données créées précédemment.

pg-primary ⇒ Démontration que la base de données test2 a été récupérée

sudo -u postgres psql -c "select * from test2_table;" test2

 id 
----
  2
(1 row)

La base de données test1, malgré une récupération réussie, n'est pas accessible. Cela est dû au fait que la base de données entière a été restaurée sous forme de fichiers épars et mis à zéro. PostgreSQL peut appliquer des WALs avec succès sur les fichiers mis à zéro mais la base de données dans son ensemble ne sera pas valide car les fichiers clés ne contiennent pas de données. Ceci est destiné à éviter que la base de données soit accidentellement utilisée alors qu'elle pourrait contenir des données partielles qui ont été appliquées lors de la relecture de WAL.

pg-primary ⇒ Tenter de se connecter à la base de données test1 produira une erreur

sudo -u postgres psql -c "select * from test1_table;" test1

psql: FATAL:  relation mapping file "base/24576/pg_filenode.map" contains invalid data

Comme la base de données test1 est restaurée avec des fichiers épars et mis à zéro, elle ne nécessitera qu'autant d'espace que la quantité de WAL qui est écrite pendant la récupération. Bien que la quantité de WAL générée lors d'une sauvegarde et appliquée lors de la récupération puisse être importante, elle ne représentera généralement qu'une petite fraction de la taille totale de la base de données, en particulier pour les grandes bases de données où cette fonctionnalité est la plus susceptible d'être utile.

Il est clair que la base de données test1 utilise beaucoup moins d'espace disque pendant la restauration sélective qu'elle ne l'aurait fait si toute la base de données avait été restaurée.

pg-primary ⇒ Afficher l'espace utilisé par la base de données test1 après la récupération

sudo -u postgres du -sh /var/lib/postgresql/10/demo/base/24576

176K	/var/lib/postgresql/10/demo/base/24576

À ce stade, la seule action qui peut être entreprise sur la base de données de test1 invalide est drop database. pgBackRest ne supprime pas automatiquement la base de données puisque cela ne peut pas être fait tant que la récupération n'est pas terminée et que l'instance n'est pas accessible.

pg-primary ⇒ Supprimer la base de données du test1

sudo -u postgres psql -c "drop database test1;"

DROP DATABASE

Maintenant que la base de données invalide du test1 a été supprimée, il ne reste plus que le test2 et les bases de données internes.

pg-primary ⇒ Liste des bases de données restantes

sudo -u postgres psql -c "select oid, datname from pg_database order by oid;"

  oid  |  datname  
-------+-----------
     1 | template1
 12979 | template0
 12980 | postgres

 24577 | test2

(4 rows)

Point-in-Time Recovery

Restaurer une sauvegarde de la section Démarrage Rapide effectue une récupération par défaut, qui doit se poursuivre jusqu'à la fin du flux de WAL. En cas de défaillance matérielle, c'est généralement le meilleur choix, mais pour les scénarios de corruption de données (qu'elles soient d'origine machine ou humaine), la récupération ponctuelle (PITR) est souvent plus appropriée

La récupération ponctuelle (PITR) permet de lire les WAL depuis la dernière sauvegarde jusqu'à une heure, un identifiant de transaction ou un point de récupération spécifié. Pour les scénarios de récupération courants, la récupération basée sur le temps est sans doute la plus utile. Un scénario de récupération typique consiste à restaurer une table qui a été accidentellement supprimée ou des données qui ont été accidentellement effacées. La récupération d'une table supprimée est plus spectaculaire, c'est donc l'exemple donné ici, mais des données supprimées seraient récupérées exactement de la même manière.

pg-primary ⇒ Sauvegarder l'instance demo et créer une table avec des données très importantes

sudo -u postgres pgbackrest --stanza=demo --type=diff backup

sudo -u postgres psql -c "begin; \
       create table important_table (message text); \
       insert into important_table values ('Important Data'); \
       commit; \
       select * from important_table;"

    message     
----------------

 Important Data

(1 row)

Il est important de faire correspondre l'heure à celle calculée par PostgreSQL et d'inclure les décalages de fuseau horaire. Cela réduit la possibilité de conversions involontaires de fuseau horaire et d'un résultat de récupération inattendu.

pg-primary ⇒ Obtenez l'heure à partir de PostgreSQL

sudo -u postgres psql -Atc "select current_timestamp"

2020-05-26 00:19:31.244816+00

Maintenant que l'heure a été enregistrée, le tableau est supprimé. En pratique, il est beaucoup plus difficile de trouver l'heure exacte à laquelle la table a été supprimée que dans cet exemple. Il n'est peut-être pas possible de trouver l'heure exacte, mais un travail de recherche devrait vous permettre de vous en rapprocher.

pg-primary ⇒ Supprimer la table importante

sudo -u postgres psql -c "begin; \
       drop table important_table; \
       commit; \
       select * from important_table;"

ERROR:  relation "important_table" does not exist

LINE 1: ...le important_table;     commit;     select * from important_...
                                                             ^

Maintenant, la restauration peut être effectuée avec une récupération basée sur le temps pour récupérer la table perdue.

pg-primary ⇒ Arrêtez PostgreSQL, restaurez l'instance demo à 2020-05-26 00:19:31.244816+00, et affichez le fichier recovery.conf

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta \
       --type=time "--target=2020-05-26 00:19:31.244816+00" \
       --target-action=promote restore

sudo -u postgres cat /var/lib/postgresql/10/demo/recovery.conf

# Recovery settings generated by pgBackRest restore on 2020-05-26 00:19:34
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'

recovery_target_time = '2020-05-26 00:19:31.244816+00'

recovery_target_action = 'promote'

Le fichier recovery.conf a été généré automatiquement par pgBackRest, de sorte que PostgreSQL peut être lancé immédiatement. Une fois que PostgreSQL a terminé la récupération, la table existera de nouveau et pourra être interrogée.

pg-primary ⇒ Démarrez PostgreSQL et vérifiez que la table important existe

sudo pg_ctlcluster 10 demo start

sudo -u postgres psql -c "select * from important_table"

    message     
----------------

 Important Data

(1 row)

Les traces de PostgreSQL contiennent également des informations précieuses. Ils indiqueront l'heure et la transaction où la récupération s'est arrêtée et donnera également l'heure de la dernière transaction appliquée.

pg-primary ⇒ Examiner la sortie des traces PostgreSQL

sudo -u postgres cat /var/log/postgresql/postgresql-10-demo.log

       [filtered 2 lines of output]
LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG:  database system was interrupted; last known up at 2020-05-26 00:19:24 UTC

LOG:  starting point-in-time recovery to 2020-05-26 00:19:31.244816+00

LOG:  restored log file "00000004.history" from archive
LOG:  restored log file "000000040000000000000016" from archive
       [filtered 2 lines of output]
LOG:  database system is ready to accept read only connections
LOG:  restored log file "000000040000000000000017" from archive

LOG:  recovery stopping before commit of transaction 564, time 2020-05-26 00:19:32.883449+00

LOG:  redo done at 0/17020A80

LOG:  last completed transaction was at log time 2020-05-26 00:19:29.664696+00

LOG:  selected new timeline ID: 5
LOG:  archive recovery complete
       [filtered 3 lines of output]

Cet exemple a été truqué pour donner le bon résultat. Si une sauvegarde après le temps requis est choisie, alors PostgreSQL ne pourra pas récupérer la table perdue. PostgreSQL ne peut jouer que vers l'avant, pas vers l'arrière. Pour le démontrer, la table importante doit être abandonnée (de nouveau).

pg-primary ⇒ Supprimer la table importante (de nouveau)

sudo -u postgres psql -c "begin; \
       drop table important_table; \
       commit; \
       select * from important_table;"

ERROR:  relation "important_table" does not exist

LINE 1: ...le important_table;     commit;     select * from important_...
                                                             ^

Prenez maintenant une nouvelle sauvegarde et essayez de récupérer à partir de la nouvelle sauvegarde en spécifiant l'option {--set. La commande info peut être utilisée pour trouver le nouveau label de la sauvegarde.

pg-primary ⇒ Effectuer une sauvegarde et obtenir des informations sur la sauvegarde

sudo -u postgres pgbackrest --stanza=demo --type=incr backup

sudo -u postgres pgbackrest info

stanza: demo
    status: ok
    cipher: aes-256-cbc

    db (current)
        wal archive min/max (10-1): 000000020000000000000008/000000050000000000000018

        full backup: 20200526-001813F
            timestamp start/stop: 2020-05-26 00:18:13 / 2020-05-26 00:18:26
            wal start/stop: 000000020000000000000008 / 000000020000000000000008
            database size: 22.5MB, backup size: 22.5MB
            repository size: 2.7MB, repository backup size: 2.7MB

        full backup: 20200526-001828F
            timestamp start/stop: 2020-05-26 00:18:28 / 2020-05-26 00:18:41
            wal start/stop: 00000002000000000000000A / 00000002000000000000000A
            database size: 22.5MB, backup size: 22.5MB
            repository size: 2.7MB, repository backup size: 2.7MB

        diff backup: 20200526-001828F_20200526-001854D
            timestamp start/stop: 2020-05-26 00:18:54 / 2020-05-26 00:18:55
            wal start/stop: 000000020000000000000011 / 000000020000000000000011
            database size: 22.5MB, backup size: 8.2KB
            repository size: 2.7MB, repository backup size: 496B
            backup reference list: 20200526-001828F

        incr backup: 20200526-001828F_20200526-001904I
            timestamp start/stop: 2020-05-26 00:19:04 / 2020-05-26 00:19:12
            wal start/stop: 000000030000000000000013 / 000000030000000000000013
            database size: 37MB, backup size: 15.1MB
            repository size: 4.4MB, repository backup size: 1.8MB
            backup reference list: 20200526-001828F, 20200526-001828F_20200526-001854D

        diff backup: 20200526-001828F_20200526-001923D
            timestamp start/stop: 2020-05-26 00:19:23 / 2020-05-26 00:19:29
            wal start/stop: 000000040000000000000016 / 000000040000000000000016
            database size: 29.8MB, backup size: 7.8MB
            repository size: 3.5MB, repository backup size: 948.7KB
            backup reference list: 20200526-001828F

        incr backup: 20200526-001828F_20200526-001941I

            timestamp start/stop: 2020-05-26 00:19:41 / 2020-05-26 00:19:43
            wal start/stop: 000000050000000000000018 / 000000050000000000000018
            database size: 29.8MB, backup size: 2.1MB
            repository size: 3.5MB, repository backup size: 218.1KB
            backup reference list: 20200526-001828F, 20200526-001828F_20200526-001923D

pg-primary ⇒ Tentative de récupération à partir de la sauvegarde spécifiée

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta \
       --set=20200526-001828F_20200526-001941I \
       --type=time "--target=2020-05-26 00:19:31.244816+00" --target-action=promote restore

sudo pg_ctlcluster 10 demo start

sudo -u postgres psql -c "select * from important_table"

ERROR:  relation "important_table" does not exist

LINE 1: select * from important_table
                      ^

En regardant le journal de sortie, il n'est pas évident que la récupération n'a pas réussi à restaurer la table. La solution consiste à rechercher la présence des messages de journal recovery stopping before... (arrêt de la récupération avant...) et last completed transaction.. (dernière transaction effectuée...). S'ils ne sont pas présents, alors la récupération au point spécifié dans le temps n'a pas réussi.

pg-primary ⇒ Examiner la sortie du journal PostgreSQL pour constater que la récupération n'a pas réussi

sudo -u postgres cat /var/log/postgresql/postgresql-10-demo.log

       [filtered 2 lines of output]
LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG:  database system was interrupted; last known up at 2020-05-26 00:19:41 UTC

LOG:  starting point-in-time recovery to 2020-05-26 00:19:31.244816+00

LOG:  restored log file "00000005.history" from archive
LOG:  restored log file "000000050000000000000018" from archive
LOG:  redo starts at 0/18000028

LOG:  consistent recovery state reached at 0/180000F8

LOG:  database system is ready to accept read only connections
LOG:  redo done at 0/180000F8
       [filtered 8 lines of output]

Le comportement par défaut pour la restauration basée sur le temps, si l'option --set n'est pas spécifiée, est de tenter de découvrir une sauvegarde antérieure pour la rejouer. Si un jeu de sauvegarde ne peut pas être trouvé, alors la restauration se fera par défaut sur la dernière sauvegarde qui, comme indiqué précédemment, peut ne pas donner le résultat souhaité.

pg-primary ⇒ Arrêter PostgreSQL, restaurer à partir de la sauvegarde sélectionnée automatiquement, et démarrez PostgreSQL

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta \
       --type=time "--target=2020-05-26 00:19:31.244816+00" \
       --target-action=promote restore

sudo pg_ctlcluster 10 demo start

sudo -u postgres psql -c "select * from important_table"

    message     
----------------

 Important Data

(1 row)

Maintenant, la sortie du journal (traces) contiendra les messages attendus recovery stopping before... (arrêt de la récupération avant...) et last completed transaction... (dernière transaction terminée...) indiquant que la récupération a réussi.

pg-primary ⇒ Examiner la sortie du journal (traces) de PostgreSQL pour les messages indiquant le succès

sudo -u postgres cat /var/log/postgresql/postgresql-10-demo.log

       [filtered 2 lines of output]
LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG:  database system was interrupted; last known up at 2020-05-26 00:19:24 UTC

LOG:  starting point-in-time recovery to 2020-05-26 00:19:31.244816+00

LOG:  restored log file "00000004.history" from archive
LOG:  restored log file "000000040000000000000016" from archive
       [filtered 2 lines of output]
LOG:  database system is ready to accept read only connections
LOG:  restored log file "000000040000000000000017" from archive

LOG:  recovery stopping before commit of transaction 564, time 2020-05-26 00:19:32.883449+00

LOG:  redo done at 0/17020A80

LOG:  last completed transaction was at log time 2020-05-26 00:19:29.664696+00

LOG:  restored log file "00000005.history" from archive
LOG:  restored log file "00000006.history" from archive
       [filtered 5 lines of output]

Support de S3-Compatible Object Store

pgBackRest prend en charge l'emplacement du dépot de sauvegarde dans le magasin d'objet compatible-S3. Le conteneur utilisé pour stocker le dépôt doit être crée à l'avance — pgBackRest il ne se créera donc pas automatiquement. Le dépôt peut être situé à la racine du conteneur (/) mais il est préférable de le pacer dans un sous-chemin afin d'éviter des conflit lors du sockage des traces ou d'autres donnée.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de S3

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
process-max=4
repo1-cipher-pass=zWaf6XtpjIVZC5444yXB+cgFDFl7MxGlgkZSaoPvTGirhPygu4jOKOXf9LO4vjfO
repo1-cipher-type=aes-256-cbc
repo1-path=/demo-repo
repo1-retention-diff=2
repo1-retention-full=2
repo1-s3-bucket=demo-bucket
repo1-s3-endpoint=s3.us-east-1.amazonaws.com
repo1-s3-key=accessKey1
repo1-s3-key-secret=verySecretKey1
repo1-s3-region=us-east-1
repo1-type=s3
start-fast=y

[global:archive-push]
compress-level=3

NOTE:

La region et le endpoint devront être configurés en fonction de l'endroit où se trouve le conteneur. Les valeurs données ici sont pour la région us-east-1.

Un rôle doit être créé pour exécuter pgBackRest et les permissions du bucket doivent être définies de manière aussi restrictive que possible. Cet exemple de politique Amazon S3 restreindra toutes les lectures et écritures dans la zone de stockage et le chemin du dépôt.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "demo-repo"
                    ],
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "demo-repo/*"
                    ]
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::demo-bucket/demo-repo/*"
            ]
        }
    ]
}

Les commandes sont exécutées exactement comme si le dépôt était stocké sur un disque local.

pg-primary ⇒ Create the stanza

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-create

P00   INFO: stanza-create command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/demo-repo --repo1-s3-bucket=demo-bucket --repo1-s3-endpoint=s3.us-east-1.amazonaws.com --repo1-s3-key= --repo1-s3-key-secret= --repo1-s3-region=us-east-1 --repo1-type=s3 --stanza=demo
P00   INFO: http statistics: objects 2, sessions 2, requests 12, retries 0, closes 0

P00   INFO: stanza-create command end: completed successfully

Le temps de création des fichiers dans les magasins d'objets est relativement lent, les commandes bénéficient donc d'une augmentation de process-max pour paralléliser la création des fichiers.

pg-primary ⇒ Sauvegarder l'instance demo

sudo -u postgres pgbackrest --stanza=demo \
       --log-level-console=info backup

P00   INFO: backup command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=4 --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/demo-repo --repo1-retention-diff=2 --repo1-retention-full=2 --repo1-s3-bucket=demo-bucket --repo1-s3-endpoint=s3.us-east-1.amazonaws.com --repo1-s3-key= --repo1-s3-key-secret= --repo1-s3-region=us-east-1 --repo1-type=s3 --stanza=demo --start-fast

P00   WARN: no prior backup exists, incr backup has been changed to full

P00   INFO: execute non-exclusive pg_start_backup(): backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 000000070000000000000018, lsn = 0/18000028
       [filtered 1238 lines of output]
P03   INFO: backup file /var/lib/postgresql/10/demo/base/1/12827 (0B, 100%)
P04   INFO: backup file /var/lib/postgresql/10/demo/base/1/12817 (0B, 100%)

P00   INFO: full backup size = 29.8MB

P00   INFO: execute non-exclusive pg_stop_backup() and wait for all WAL segments to archive
P00   INFO: backup stop archive = 000000070000000000000018, lsn = 0/180000F8
       [filtered 6 lines of output]

Supprimer un stanza

La commande stanza-delete supprime les données du dépôt associé au stanza.

WARNING:

Utilisez cette commande avec précaution — elle supprimera définitivement toutes les sauvegardes et archives du dépôt pgBackRest pour la stanza spécifiée.

Pour supprimer un stanza:

Arrêter l'instance PostgreSQL associé au stanza (ou utiliser l'option --force pour passer outre).
Exécuter la commande stop sur l'hôte du dépôt.
Exécuter la commande stanza-delete sur l'hôte du dépôt.

Une fois la commande terminée avec succès, il incombe à l'utilisateur de supprimer de la configuration pgBackRest le stanza.

pg-primary ⇒ Stopper l'instance PostgreSQL à supprimer

sudo pg_ctlcluster 10 demo stop

pg-primary ⇒ Stopper pgBackRest pour le stanza

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stop

P00   INFO: stop command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/demo-repo --repo1-s3-bucket=demo-bucket --repo1-s3-endpoint=s3.us-east-1.amazonaws.com --repo1-s3-key= --repo1-s3-key-secret= --repo1-s3-region=us-east-1 --repo1-type=s3 --stanza=demo

P00   INFO: stop command end: completed successfully

pg-primary ⇒ Supprimer le stanza

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info stanza-delete

P00   INFO: stanza-delete command begin 2.27: --log-level-console=info --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-cipher-pass= --repo1-cipher-type=aes-256-cbc --repo1-path=/demo-repo --repo1-s3-bucket=demo-bucket --repo1-s3-endpoint=s3.us-east-1.amazonaws.com --repo1-s3-key= --repo1-s3-key-secret= --repo1-s3-region=us-east-1 --repo1-type=s3 --stanza=demo
P00   INFO: http statistics: objects 2, sessions 2, requests 14, retries 0, closes 0

P00   INFO: stanza-delete command end: completed successfully

Hote de référentiel de sauvegarde dédié

La configuration décrite dans section Déamarrage Rapide convient aux installations simples, mais pour les configurations d'entreprise, il est plus courant d'avoir un hôte repository dédié où sont stockés les sauvegardes et les fichiers d'archive WAL. Cela permet de séparer les sauvegardes et les archives WAL du serveur de base de données, de sorte que les défaillances de l'hôte database ont moins d'impact. Il est toujours judicieux d'utiliser un logiciel de sauvegarde traditionnel pour sauvegarder l'hôte dédié au sauvegarde repository.

Sur l'hôte PostgreSQL, l'option pg1-path doit être le chemin de la grappe PostgreSQL locale et aucune option pg1-host ne doit être configurée. Lors de la configuration d'un hôte de dépôt, le fichier de configuration pgBackRest doit avoir l'option pg-host configurée pour se connecter aux instances primaire et de secours (le cas échéant). L'hôte de dépôt a la seule configuration pgBackRest qui doit connaître plus d'un hôte PostgreSQL. L'ordre n'a pas d'importance, par exemple pg1-path/pg1-host, pg2-path/pg2-host peut être le primaire ou le secondaire.

14.1

Installation

Un nouvel hôte nommé repository est créé pour stocker les sauvegardes du cluster.

L'utilisateur pgbackrest est créé pour détenir le référentiel pgBackRest. Tout utilisateur peut être propriétaire du référentiel mais il est préférable de ne pas utiliser postgres (s'il existe) pour éviter toute confusion.

repository ⇒ Create pgbackrest user

sudo adduser --disabled-password --gecos "" pgbackrest

pgBackRest doit être installé à partir d'un paquet ou installé manuellement comme indiqué ci-dessous.

build ⇒ Installation des dépendances

sudo apt-get install postgresql-client libxml2

repository ⇒ Copiez les binaires de pgBackRest depuis la plateforme de compilation

sudo scp build:/build/pgbackrest-release-2.27/src/pgbackrest /usr/bin

sudo chmod 755 /usr/bin/pgbackrest

pgBackRest nécessite des répertoires pour les traces (logs) et pour la configuration ainsi qu'un fichier de configuration.

repository ⇒ Création des répertoires et du fichier de configuration pour pgBackRest

sudo mkdir -p -m 770 /var/log/pgbackrest

sudo chown pgbackrest:pgbackrest /var/log/pgbackrest

sudo mkdir -p /etc/pgbackrest

sudo mkdir -p /etc/pgbackrest/conf.d

sudo touch /etc/pgbackrest/pgbackrest.conf

sudo chmod 640 /etc/pgbackrest/pgbackrest.conf

sudo chown pgbackrest:pgbackrest /etc/pgbackrest/pgbackrest.conf

repository ⇒ Création du dépot de sauvegarde pour pgBackRest

sudo mkdir -p /var/lib/pgbackrest

sudo chmod 750 /var/lib/pgbackrest

sudo chown pgbackrest:pgbackrest /var/lib/pgbackrest

14.2

Configuration de SSH par échange de clés

pgBackRest nécessite un configuration de SSH sans mot de passe (par échange de clef) pour permettre la communication entre les hôtes.

repository ⇒ Create repository host key pair

sudo -u pgbackrest mkdir -m 750 /home/pgbackrest/.ssh

sudo -u pgbackrest ssh-keygen -f /home/pgbackrest/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

pg-primary ⇒ Créer sur pg-primary une paire de clef

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh

sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

Echange de clef entre repository et pg-primary.

repository ⇒ Copiez la clef public de pg-primary sur repository

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@pg-primary cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

pg-primary ⇒ Copiez la clef publique de repository sur pg-primary

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
       sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys

Testez que la connexion SSH fonctionne entre repository et pg-primary et vice versa.

repository ⇒ Testez la connexon depuis repository vers pg-primary

sudo -u pgbackrest ssh postgres@pg-primary

pg-primary ⇒ Teste de la connexion depuis pg-primary vers repository

sudo -u postgres ssh pgbackrest@repository

NOTE:

ssh a été configuré pour permettre uniquement l'exécution de pgBackRest via ssh sans mot de passe. Cela renforce la sécurité en cas de détournement de l'un des comptes de service.

14.3

Configuration

L'hôte repository doit être configuré avec {[hôte-pg1]} hôte/utilisateur et base de données. Le primaire sera configuré comme pg1 pour permettre l'ajout d'une instance secondaire plus tard.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de pg1-host/pg1-host-user et pg1-path

[demo]
pg1-host=pg-primary
pg1-path=/var/lib/postgresql/10/demo

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

L'hôte de la base de données doit être configuré avec l'hôte/utilisateur du référentiel de sauvegarde repository. La valeur par défaut de l'option repo1-host-user est pgbackrest. Si l'utilisateur postgres effectue des restaurations, il est préférable de ne pas l'autoriser à effectuer des sauvegardes. Toutefois, l'utilisateur postgres peut lire directement le dépôt s'il est dans le même groupe que l'utilisateur pgbackrest.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-host/repo1-host-user

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
log-level-file=detail
repo1-host=repository

Les commandes sont exécutées de la même manière que sur une configuration à hôte unique, sauf que certaines commandes telles que backup et expire sont exécutées à partir de l'hôte repository au lieu de l'hôte database.

Créer le Stanza dans le nouveau dépôt.

repository ⇒ Création du stanza

sudo -u pgbackrest pgbackrest --stanza=demo stanza-create

Vérifiez que la configuration est correcte sur les deux hôtes database et repository. Vous trouverez plus d'informations sur la commande check dans la section Contrôle de la configuration.

pg-primary ⇒ Contrôler la configuration

sudo -u postgres pgbackrest --stanza=demo check

repository ⇒ Check the configuration

sudo -u pgbackrest pgbackrest --stanza=demo check

14.4

Effectuer une sauvegarde

Pour effectuer une sauvegarde de l'instance PostgreSQL, lancez pgBackRest avec la commande backup sur l'hôte repository.

repository ⇒ Sauvegarde du cluster demo

sudo -u pgbackrest pgbackrest --stanza=demo backup

P00   WARN: no prior backup exists, incr backup has been changed to full

Depuis qu'un nouveau dépôt a été créé sur l'hôte repository, un avertissement concernant le passage de la sauvegarde incrémentalle à une sauvegarde complète a été émis.

14.5

Restauration d'une sauvegarde

Pour effectuer une restauration de l'instance PostgreSQL, lancez pgBackRest avec la commande restore sur l'hôte database.

pg-primary ⇒ Arrêter l'instance demo, restaurer et redémarrer PostgreSQL

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta restore

sudo pg_ctlcluster 10 demo start

Sauvegarde / Restauration en parallèle

pgBackRest offre un traitement parallèle pour améliorer les performances de la compression et du transfert. Le nombre de processus à utiliser pour cette fonction est défini à l'aide de l'option --process-max.

Il est généralement préférable de ne pas utiliser plus de 25 % des processeurs disponibles pour la commande backup. Les sauvegardes n'ont pas besoin de s'exécuter aussi rapidement dans la mesure où elles sont effectuées régulièrement; le processus de sauvegarde ne doit pas avoir d'impact, si possible, sur les performances de la base de données.

La commande de restauration peut et doit utiliser toutes les processeurs (CPU) disponibles car pendant une restauration, l'instance PostgreSQL est arrêté et il n'y a généralement pas d'autre travail important effectué sur le serveur. Si le serveur contient plusieurs instances PostgreSQL, cela doit être pris en compte dans le paramétrage du parallélisme de la restauration.

repository ⇒ Effectuer une sauvegarde avec un seul processus

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Configurer pgBackRest pour utiliser plusieurs processus backup

[demo]
pg1-host=pg-primary
pg1-path=/var/lib/postgresql/10/demo

[global]
process-max=3
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

repository ⇒ Effectuer une sauvegarde avec plusieurs processus

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

repository ⇒ Obtenir des informations de sauvegarde pour l'instance demo.

sudo -u pgbackrest pgbackrest info

stanza: demo
    status: ok
    cipher: none

    db (current)
        wal archive min/max (10-1): 00000008000000000000001D/00000008000000000000001E

        full backup: 20200526-002056F

            timestamp start/stop: 2020-05-26 00:20:56 / 2020-05-26 00:21:13

            wal start/stop: 00000008000000000000001D / 00000008000000000000001D
            database size: 29.8MB, backup size: 29.8MB
            repository size: 3.5MB, repository backup size: 3.5MB

        full backup: 20200526-002115F

            timestamp start/stop: 2020-05-26 00:21:15 / 2020-05-26 00:21:22

            wal start/stop: 00000008000000000000001E / 00000008000000000000001E
            database size: 29.8MB, backup size: 29.8MB
            repository size: 3.5MB, repository backup size: 3.5MB

La performance de la dernière sauvegarde devrait être améliorée en utilisant des processus multiples. Pour les très petites sauvegardes, la différence ne sera peut-être pas très visible, mais plus la taille de la base de données augmente, plus le gain en temps est important.

Démarrer et arrêter

Il est parfois utile d'éviter que pgBackRest ne fonctionne sur un système. Par exemple, lors du passage d'un système primaire à un système de secours, il est préférable d'empêcher pgBackRest de fonctionner sur l'ancien système primaire au cas où PostgreSQL serait redémarré ou ne pourrait pas être complètement détruit. Cela empêchera également pgBackRest de fonctionner avec un lancement par le cron.

pg-primary ⇒ Stop the pgBackRest services

sudo -u postgres pgbackrest stop

Les nouveaux processus pgBackRest ne fonctionneront plus.

repository ⇒ Tentative de sauvegarde

sudo -u pgbackrest pgbackrest --stanza=demo backup

P00   WARN: unable to check pg-1: [StopError] raised from remote-0 protocol on 'pg-primary': stop file exists for all stanzas

P00  ERROR: [056]: unable to find primary cluster - cannot proceed

Précisez l'option --force pour mettre fin à tout processus pgBackRest en cours. Si pgBackRest est déjà arrêté, un avertissement sera généré si vous l'arrêtez à nouveau.

pg-primary ⇒ Arrêter à nouveau les services de pgBackRest

sudo -u postgres pgbackrest stop

P00   WARN: stop file already exists for all stanzas

Démarrer le processus pgBackRest à nouveau avec la commande start.

pg-primary ⇒ Démarrer les services pgBackRest

sudo -u postgres pgbackrest start

Il est également possible de stopper pgBackRest pour une seule stanza.

pg-primary ⇒ Stoper le services pgBackRest pour le stanza demo

sudo -u postgres pgbackrest --stanza=demo stop

Les nouveaux processus pgBackRest pour le stanza spécifiée ne fonctionneront plus.

repository ⇒ Tentative de sauvegarde

sudo -u pgbackrest pgbackrest --stanza=demo backup

P00   WARN: unable to check pg-1: [StopError] raised from remote-0 protocol on 'pg-primary': stop file exists for stanza demo

P00  ERROR: [056]: unable to find primary cluster - cannot proceed

Le stanza doit également être spécifiée lors du lancement des processus pgBackRest pour un stanza unique.

pg-primary ⇒ Start the pgBackRest services for the demo stanza

sudo -u postgres pgbackrest --stanza=demo start

Replication

La réplication permet de créer plusieurs copies d'une instance PostgreSQL (appelé esclave ou standbys) à partir d'une seule primaire. Les standbys sont utiles pour équilibrer les lectures et pour fournir une redondance en cas de défaillance de l'hôte primaire.

17.1

Installation

Un nouvel hôte nommé pg-standby est créé pour ce rôle de standby (esclave).

pgBackRest doit être installé à partir d'un paquet ou installé manuellement comme indiqué ci-dessous.

build ⇒ Installation des dépendances

sudo apt-get install postgresql-client libxml2

pg-standby ⇒ Copiez les binaires de pgBackRest depuis la plateforme de compilation

sudo scp build:/build/pgbackrest-release-2.27/src/pgbackrest /usr/bin

sudo chmod 755 /usr/bin/pgbackrest

pgBackRest nécessite des répertoires pour les traces (logs) et pour la configuration ainsi qu'un fichier de configuration.

pg-standby ⇒ Création des répertoires et du fichier de configuration pour pgBackRest

sudo mkdir -p -m 770 /var/log/pgbackrest

sudo chown postgres:postgres /var/log/pgbackrest

sudo mkdir -p /etc/pgbackrest

sudo mkdir -p /etc/pgbackrest/conf.d

sudo touch /etc/pgbackrest/pgbackrest.conf

sudo chmod 640 /etc/pgbackrest/pgbackrest.conf

sudo chown postgres:postgres /etc/pgbackrest/pgbackrest.conf

17.2

Configurer un accès SSH sans mot de passe

pgBackRest nécessite un configuration de SSH sans mot de passe (par échange de clef) pour permettre la communication entre les hôtes.

pg-standby ⇒ Créer sur pg-standby une paire de clef

sudo -u postgres mkdir -m 750 -p /var/lib/postgresql/.ssh

sudo -u postgres ssh-keygen -f /var/lib/postgresql/.ssh/id_rsa \
       -t rsa -b 4096 -N ""

Echange de clef entre repository et pg-standby.

repository ⇒ Copiez la clef public de pg-standby sur repository

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@pg-standby cat /var/lib/postgresql/.ssh/id_rsa.pub) | \
       sudo -u pgbackrest tee -a /home/pgbackrest/.ssh/authorized_keys

pg-standby ⇒ Copiez la clef publique de repository sur pg-standby

(echo -n 'no-agent-forwarding,no-X11-forwarding,no-port-forwarding,' && \
       echo -n 'command="/usr/bin/pgbackrest ${SSH_ORIGINAL_COMMAND#* }" ' && \
       sudo ssh root@repository cat /home/pgbackrest/.ssh/id_rsa.pub) | \
       sudo -u postgres tee -a /var/lib/postgresql/.ssh/authorized_keys

Testez que la connexion SSH fonctionne entre repository et pg-standby et vice versa.

repository ⇒ Testez la connexon depuis repository vers pg-standby

sudo -u pgbackrest ssh postgres@pg-standby

pg-standby ⇒ Teste de la connexion depuis pg-standby vers repository

sudo -u postgres ssh pgbackrest@repository

17.3

Hot Standby

Un hot standby effectue la réplication en utilisant l'archive WAL et permet des requêtes en lecture seule.

La configuration de pgBackRest est très similaire à celle de pg-primary sauf que le type de récupération standby sera utilisé pour maintenir l'instance en mode de récupération lorsque la fin du flux WAL aura été atteinte.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de pgBackRest sur l'escalve (standby)

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
log-level-file=detail
repo1-host=repository

L'instance de démonstration doit être créée (même si elle sera écrasée lors de la restauration) afin de créer les fichiers de configuration PostgreSQL.

pg-standby ⇒ Création de l'instance de démonstration

sudo pg_createcluster 10 demo

Maintenant, l'escalve (standby) peut être créée avec la commande restore.

pg-standby ⇒ Restaurer le demo l'instance esclave (standby)

sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore

sudo -u postgres cat /var/lib/postgresql/10/demo/recovery.conf

# Recovery settings generated by pgBackRest restore on 2020-05-26 00:21:50
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
standby_mode = 'on'

Le paramètre hot_standby doit être activé avant de lancer PostgreSQL pour autoriser les connexions en lecture seule sur pg-standby. Dans le cas contraire, les tentatives de connexion seront refusées. Le reste de la configuration concerne le cas où l'instance esclave (standby) est promue comme primaire.

pg-standby:/etc/postgresql/10/demo/postgresql.conf ⇒ Configuration de PostgreSQL

archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
hot_standby = on
log_filename = 'postgresql.log'
log_line_prefix = ''
max_wal_senders = 3
wal_level = replica

pg-standby ⇒ Démarrage de PostgreSQL

sudo pg_ctlcluster 10 demo start

Le journal des traces PostgreSQL donne des informations précieuses sur la récupération. Notez en particulier que l'instance est entré en mode veille et est prête à accepter des connexions en lecture seule.

pg-standby ⇒ Examiner la sortie du journal de traces PostgreSQL à la recherche des messages indiquant le succès

sudo -u postgres cat /var/log/postgresql/postgresql-10-demo.log

       [filtered 3 lines of output]
LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
LOG:  database system was interrupted; last known up at 2020-05-26 00:21:15 UTC

LOG:  entering standby mode

LOG:  restored log file "00000008.history" from archive
LOG:  restored log file "00000008000000000000001E" from archive
LOG:  redo starts at 0/1E000028
LOG:  consistent recovery state reached at 0/1E000130

LOG:  database system is ready to accept read only connections

LOG:  incomplete startup packet

Une façon simple de vérifier que la réplication est correctement configurée est de créer une table sur pg-primary.

pg-primary ⇒ Créer une nouvelle table sur l'instance primaire

sudo -u postgres psql -c " \
       begin; \
       create table replicated_table (message text); \
       insert into replicated_table values ('Important Data'); \
       commit; \
       select * from replicated_table";

    message     
----------------

 Important Data

(1 row)

Puis interrogez la même table sur pg-standby.

pg-standby ⇒ Intérroger la nouvelle table sur l'esclave (standby)

sudo -u postgres psql -c "select * from replicated_table;"

ERROR:  relation "replicated_table" does not exist

LINE 1: select * from replicated_table;
                      ^

Alors, qu'est-ce qui a mal tourné ? Puisque PostgreSQL extrait des segments WAL de l'archive pour effectuer la réplication, les changements ne seront pas visibles en attente jusqu'à ce que le segment WAL qui contient ces changements soit poussé de pg-primary.

Cela peut être fait manuellement en appelant pg_switch_wal() qui pousse le segment WAL actuel vers l'archive (un nouveau segment WAL est créé pour contenir les nouveaux changements).

pg-primary ⇒ Executer pg_switch_wal()

sudo -u postgres psql -c "select *, current_timestamp from pg_switch_wal()";

 pg_switch_wal |       current_timestamp       
---------------+-------------------------------
 0/1F02ABF8    | 2020-05-26 00:21:58.568809+00
(1 row)

Maintenant, après un court délai, la table apparaîtra sur pg-standby.

pg-standby ⇒ La nouvelle table existe maintenant sur l'esclave (standby) (peut nécessiter quelques essais)

sudo -u postgres psql -c " \
       select *, current_timestamp from replicated_table"

    message     |       current_timestamp       
----------------+-------------------------------

 Important Data | 2020-05-26 00:22:03.551304+00

(1 row)

Vérifiez la configuration de l'esclave pour l'accès au dépôt de sauvegarde.

pg-standby ⇒ Contrôle de la configuration

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check

P00   INFO: check command begin 2.27: --log-level-console=info --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-host=repository --stanza=demo

P00   INFO: switch wal not performed because this is a standby

P00   INFO: check command end: completed successfully

17.4

Réplication en flux contrinu flux (streaming replication)

Au lieu de s'appuyer uniquement sur les archives de la WAL, la réplication en continu établit une connexion directe avec l'instance primaire et applique les modifications dès qu'elles sont effectuées sur la primaire. Il en résulte un délai beaucoup plus court entre le primaire et le secondaire (standby).

La réplication en continu nécessite un utilisateur disposant du privilège de réplication.

pg-primary ⇒ Création d'un utilisateur de réplication

sudo -u postgres psql -c " \
       create user replicator password 'jw8s0F4' replication";

CREATE ROLE

Le fichier pg_hba.conf doit être mis à jour afin de permettre à l'utilisateur de réplication utilisé sur l'instance esclave (standby) de se connecter. Veillez à remplacer l'adresse IP ci-dessous par l'adresse IP réelle de votre pg-primary. Un rechargement (reload) sera nécessaire après la modification du fichier pg_hba.conf.

pg-primary ⇒ Création de l'entrée pour l'utilisateur de réplication dans pg_hba.conf

sudo -u postgres sh -c 'echo \
       "host    replication     replicator      172.17.0.6/32           md5" \
       >> /etc/postgresql/10/demo/pg_hba.conf'

sudo pg_ctlcluster 10 demo reload

L'instance esclave (standby) doit savoir comment se connecter à l'instance primaire, pour ce faire, il faut configurer le paramètre primary_conninfo dans pgBackRest.

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Paramètrage de primary_conninfo

[demo]
pg1-path=/var/lib/postgresql/10/demo
recovery-option=primary_conninfo=host=172.17.0.4 port=5432 user=replicator

[global]
log-level-file=detail
repo1-host=repository

Il est possible de configurer un mot de passe pour le paramètre primary_conninfo mais l'utilisation d'un fichier .pgpass est plus souple et plus sûre.

pg-standby ⇒ Configurez le mot de passe de réplication dans le fichier .pgpass.

sudo -u postgres sh -c 'echo \
       "172.17.0.4:*:replication:replicator:jw8s0F4" \
       >> /var/lib/postgresql/.pgpass'

sudo -u postgres chmod 600 /var/lib/postgresql/.pgpass

Maintenant, l'instance esclave (standby) peut être créée avec la commande restore.

pg-standby ⇒ Arrêter PostgreSQL et restaurer l'instance demo esclave (standby)

sudo pg_ctlcluster 10 demo stop

sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore

sudo -u postgres cat /var/lib/postgresql/10/demo/recovery.conf

# Recovery settings generated by pgBackRest restore on 2020-05-26 00:22:08
primary_conninfo = 'host=172.17.0.4 port=5432 user=replicator'
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
standby_mode = 'on'

NOTE:

Le paramètre primary_conninfo a été écrit dans le fichier recovery.conf. La configuration des paramètres de récupération dans pgBackRest signifie que le fichier recovery.conf n'a pas besoin d'être stocké ailleurs puisqu'il sera correctement recréé à chaque restauration. L'option --type=preserve peut être utilisée avec le restore pour laisser le fichier recovery.conf existant en place si ce comportement est préféré.

pg-standby ⇒ Démarrage de PostgreSQL

sudo pg_ctlcluster 10 demo start

Le journal de traces PostgreSQL confirmera que la réplication en mode flux continue (streaming réplication) a commencé.

pg-standby ⇒ Examen de la sortie des traces PostgreSQL à la recherche des messages indiquant le succès

sudo -u postgres cat /var/log/postgresql/postgresql-10-demo.log

       [filtered 11 lines of output]
LOG:  restored log file "00000008000000000000001F" from archive
LOG:  incomplete startup packet

LOG:  started streaming WAL from primary at 0/20000000 on timeline 8

Désormais, lorsqu'une table est créé esur pg-primary, il apparaîtra sur pg-standby rapidement et sans qu'il soit nécessaire d'appeler la fonction SQL pg_switch_wal().

pg-primary ⇒ Création d'une nouvelle table sur le primaire

sudo -u postgres psql -c " \
       begin; \
       create table stream_table (message text); \
       insert into stream_table values ('Important Data'); \
       commit; \
       select *, current_timestamp from stream_table";

    message     |       current_timestamp       
----------------+-------------------------------

 Important Data | 2020-05-26 00:22:15.468818+00

(1 row)

pg-standby ⇒ Intéroger la table sur l'esclave (standby)

sudo -u postgres psql -c " \
       select *, current_timestamp from stream_table"

    message     |       current_timestamp       
----------------+-------------------------------

 Important Data | 2020-05-26 00:22:16.016248+00

(1 row)

Archivage asynchrone

L'archivage asynchrone est activé avec l'option archive-async. Cette option permet un fonctionnement asynchrone pour les commandes archive-push et archive-get.

Un chemin de file d'attente (spool) est nécessaire. Les commandes stockent les données transitoires ici, mais chaque commande fonctionne de manière distincte, de sorte que l'utilisation du chemin d'accès à la file d'attente (spool) est décrite en détail dans chaque section.

pg-primary ⇒ Créer le répertoire de file d'attente (spool)

sudo mkdir -p -m 750 /var/spool/pgbackrest

sudo chown postgres:postgres /var/spool/pgbackrest

pg-standby ⇒ Créer le répertoire de file d'attente (spool)

sudo mkdir -p -m 750 /var/spool/pgbackrest

sudo chown postgres:postgres /var/spool/pgbackrest

Le chemin de la file d'attente (spool) doit être configuré et l'archivage asynchrone activé. L'archivage asynchrone apporte automatiquement un intérêt en réduisant le nombre de connexions au stockage distant, mais le réglage de process-max peut permettre d'améliorer considérablement les performances en parallélisant les opérations. Assurez-vous de ne pas régler process-max à un niveau si élevé qu'il affecte les opérations normales de la base de données.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurer le chemin du spool et l'archivage asynchrone

[demo]
pg1-path=/var/lib/postgresql/10/demo

[global]
archive-async=y
log-level-file=detail
repo1-host=repository
spool-path=/var/spool/pgbackrest

[global:archive-get]
process-max=2

[global:archive-push]
process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Configurer le chemin du spool et l'archivage asynchrone

[demo]
pg1-path=/var/lib/postgresql/10/demo
recovery-option=primary_conninfo=host=172.17.0.4 port=5432 user=replicator

[global]
archive-async=y
log-level-file=detail
repo1-host=repository
spool-path=/var/spool/pgbackrest

[global:archive-get]
process-max=2

[global:archive-push]
process-max=2

NOTE:

process-max est configuré à l'aide de sections de commande de sorte que l'option ne soit pas utilisée par la sauvegarde et la restauration. Cela permet également d'utiliser des valeurs différentes pour archive-push et archive-get.

A des fins de démonstration, la réplication du streaming sera interrompue pour forcer PostgreSQL à obtenir le WAL en utilisant la restore_command.

pg-primary ⇒ Interrompre la réplication du streaming en changeant le mot de passe de la réplication

sudo -u postgres psql -c "alter user replicator password 'bogus'"

ALTER ROLE

pg-standby ⇒ Redémarrer l'esclave (standby) pour interrompre la connexion

sudo pg_ctlcluster 10 demo restart

18.1

Poussez les archives (Archive Push)

La commande asynchrone archive-push décharge l'archivage WAL vers un (ou plusieurs) processus séparé(s) pour améliorer le débit. Elle fonctionne en regardant vers l'avenir pour voir quels segments WAL sont prêts à être archivés au-delà de la demande que PostgreSQL fait actuellement via la commande archive_command. Les segments WAL sont transférés vers archivage directement depuis le répertoire pg_xlog/pg_wal et le retour de succès n'est renvoyé par l' archive_command que lorsque le segment WAL est réelement stocké en toute sécurité dans l'archivage.

La file d'attente (spool) contient l'état actuel de l'archivage des WAL. Les fichiers d'état écrits dans le répertoire de spool sont généralement de longueur zéro et devraient consommer un minimum d'espace (quelques Mo au maximum) et très peu d'E/S. Toutes les informations contenues dans ce répertoire peuvent être recréées, il n'est donc pas nécessaire de le préserver si l'instance est déplacé vers un nouveau matériel.

IMPORTANT:

Dans l'implémentation initiale de l'archivage asynchrone, les segments WAL étaient copiés dans le répertoire spool avant la compression et le transfert. La nouvelle implémentation copie le WAL directement à partir du répertoire pg_xlog. Si l'archivage asynchrone était utilisé dans v1.12 ou antérieur, lisez attentivement les notes de mise à jour de v1.13 avant de procéder à la mise à niveau.

Le fichier [stanza]-archive-push-async.log peut être utilisé pour surveiller l'activité du processus asynchrone. Une bonne façon de tester cela est de pousser rapidement un certain nombre de segments WAL.

pg-primary ⇒ Tester l'archivage asynchrone parallèle

sudo -u postgres psql -c " \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal(); \
       select pg_create_restore_point('test async push'); select pg_switch_wal();"

sudo -u postgres pgbackrest --stanza=demo --log-level-console=info check

P00   INFO: check command begin 2.27: --log-level-console=info --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --repo1-host=repository --stanza=demo

P00   INFO: WAL segment 000000080000000000000025 successfully archived to '/var/lib/pgbackrest/archive/demo/10-1/0000000800000000/000000080000000000000025-ee8159736996d216d36a736baa9a79804845e750.gz'

P00   INFO: check command end: completed successfully

Le fichier journal (traces) contiendra désormais les activités parallèles et asynchrones.

pg-primary ⇒ Vérifier les résultats dans les traces.

sudo -u postgres cat /var/log/pgbackrest/demo-archive-push-async.log

-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.27: [/var/lib/postgresql/10/demo/pg_wal] --archive-async --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo

P00   INFO: push 1 WAL file(s) to archive: 000000080000000000000020
P01 DETAIL: pushed WAL file '000000080000000000000020' to the archive

P00   INFO: archive-push:async command end: completed successfully

-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.27: [/var/lib/postgresql/10/demo/pg_wal] --archive-async --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo

P00   INFO: push 4 WAL file(s) to archive: 000000080000000000000021...000000080000000000000024
P01 DETAIL: pushed WAL file '000000080000000000000021' to the archive
P02 DETAIL: pushed WAL file '000000080000000000000022' to the archive
P01 DETAIL: pushed WAL file '000000080000000000000023' to the archive
P02 DETAIL: pushed WAL file '000000080000000000000024' to the archive

P00   INFO: archive-push:async command end: completed successfully

-------------------PROCESS START-------------------
P00   INFO: archive-push:async command begin 2.27: [/var/lib/postgresql/10/demo/pg_wal] --archive-async --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo

P00   INFO: push 1 WAL file(s) to archive: 000000080000000000000025
P01 DETAIL: pushed WAL file '000000080000000000000025' to the archive

P00   INFO: archive-push:async command end: completed successfully

18.2

Obtention des archives (archive-get)

La commande asynchrone archive-get maintient une file d'attente locale de WAL pour améliorer le débit. Si un segment de WAL n'est pas trouvé dans la file d'attente, il est récupéré dans le dépôt avec suffisamment de WAL consécutifs pour remplir la file d'attente. La taille maximale de la file d'attente est définie par la commande archive-get-queue-max. Lorsque la file d'attente est moins de la moitié de sa capacité, un nombre plus important de WAL sera récupéré pour la remplir.

Ce fonctionnement asynchrone est utile dans les environnements qui génèrent beaucoup de WAL ou qui ont une connexion à haute latence avec le stockage du dépôt (par exemple S3 ou d'autres magasins d'objets). Dans le cas d'une connexion à forte latence, il peut être judicieux d'augmenter process-max.

Le fichier [stanza]-archive-get-async.log est utilisé pour surveiller l'activité du processus asynchrone.

pg-standby ⇒ Vérifier les résultats dans le journal des traces

sudo -u postgres cat /var/log/pgbackrest/demo-archive-get-async.log

-------------------PROCESS START-------------------
P00   INFO: archive-get:async command begin 2.27: [00000008000000000000001E, 00000008000000000000001F, 000000080000000000000020, 000000080000000000000021, 000000080000000000000022, 000000080000000000000023, 000000080000000000000024, 000000080000000000000025] --archive-async --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 00000008000000000000001E...000000080000000000000025

P01 DETAIL: found 00000008000000000000001E in the archive
P02 DETAIL: found 00000008000000000000001F in the archive

P01 DETAIL: unable to find 000000080000000000000020 in the archive
P02 DETAIL: unable to find 000000080000000000000021 in the archive
       [filtered 20 lines of output]
P00   INFO: archive-get:async command begin 2.27: [000000080000000000000020, 000000080000000000000021, 000000080000000000000022, 000000080000000000000023, 000000080000000000000024, 000000080000000000000025, 000000080000000000000026, 000000080000000000000027] --archive-async --log-level-console=off --log-level-file=detail --log-level-stderr=off --no-log-timestamp --pg1-path=/var/lib/postgresql/10/demo --process-max=2 --repo1-host=repository --spool-path=/var/spool/pgbackrest --stanza=demo
P00   INFO: get 8 WAL file(s) from archive: 000000080000000000000020...000000080000000000000027

P01 DETAIL: found 000000080000000000000020 in the archive
P02 DETAIL: found 000000080000000000000021 in the archive
P01 DETAIL: found 000000080000000000000022 in the archive
P02 DETAIL: found 000000080000000000000023 in the archive

P02 DETAIL: unable to find 000000080000000000000025 in the archive
P02 DETAIL: unable to find 000000080000000000000026 in the archive
P02 DETAIL: unable to find 000000080000000000000027 in the archive

P01 DETAIL: found 000000080000000000000024 in the archive

P00   INFO: archive-get:async command end: completed successfully

       [filtered 8 lines of output]
P02 DETAIL: unable to find 00000008000000000000002B in the archive
P02 DETAIL: unable to find 00000008000000000000002C in the archive

P01 DETAIL: found 000000080000000000000025 in the archive

P00   INFO: archive-get:async command end: completed successfully

pg-primary ⇒ Régler le problème de la réplication par flux (streaming replication) en rechangeant le mot de passe de la réplication

sudo -u postgres psql -c "alter user replicator password 'jw8s0F4'"

ALTER ROLE

Sauvegarde depuis l'esclave (standby)

pgBackRest peut effectuer des sauvegardes depuis l'esclave (standby) au lieu de la sauvegarde depuis le primaire. Les sauvegardes en attente nécessitent que l'hôte pg-standby soit configuré et que l'option backup-standby soit activée. Si plus d'une instance esclave (standby) est configuré, c'est le premier en cours d'exécution trouvé qui sera utilisé pour la sauvegarde.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Configuration de pg2-host/pg2-host-user et pg2-path

[demo]
pg1-host=pg-primary
pg1-path=/var/lib/postgresql/10/demo
pg2-host=pg-standby
pg2-path=/var/lib/postgresql/10/demo

[global]
backup-standby=y
process-max=3
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

L'instance primaire et esclave (standby) sont toutes les deux nécessaires pour effectuer la sauvegarde, bien que la grande majorité des fichiers soient copiés à partir d'instance esclave afin de réduire la charge sur l'instance primaire. Les instances de la base de données peuvent être configurés dans n'importe quel ordre. pgBackRest déterminera automatiquement quelle est l'instance primaire et quelle est l'instance secondaire (standby).

repository ⇒ Sauvegarde de l'instance demo depuis pg2

sudo -u pgbackrest pgbackrest --stanza=demo --log-level-console=detail backup

       [filtered 2 lines of output]
P00   INFO: execute non-exclusive pg_start_backup(): backup begins after the requested immediate checkpoint completes
P00   INFO: backup start archive = 000000080000000000000027, lsn = 0/27000028

P00   INFO: wait for replay on the standby to reach 0/27000028
P00   INFO: replay on the standby reached 0/27000028

P03   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/1249 (392KB, 17%) checksum fc14d2d8c4f576b165b1a5efc3b8e04baa461960
P02   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/2608 (440KB, 36%) checksum 23f25ba1c0443cb54da86aa8d32d4649c2bdbb30
       [filtered 10 lines of output]
P04   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/2610 (32KB, 89%) checksum 85827e08f2e389b58c351bf439a5cd7a7f66af4c
P03   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/2610_fsm (24KB, 90%) checksum 3cd92093fa77b32dc52a3006591bbf1956744830

P01   INFO: backup file pg-primary:/var/lib/postgresql/10/demo/global/pg_control (8KB, 91%) checksum 888db6cbaf077f9dc8d86e786df7192e14cc61af

P02   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/2608_fsm (24KB, 92%) checksum f65c3ce590879dc6e62ab2be8a95bc3f2687eaf7
P04   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/1249_fsm (24KB, 93%) checksum d57bfa9b0fc456b1c0c99cfb0f2e3f35da083a88
P03   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/global/2677 (16KB, 94%) checksum 8dcb6419b0168ead5ee45af5c10b4bf7052a8327

P01   INFO: backup file pg-primary:/var/lib/postgresql/10/demo/pg_logical/replorigin_checkpoint (8B, 94%) checksum 347fc8f2df71bd4436e38bd1516ccd7ea0d46532

P02   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/global/2676 (16KB, 94%) checksum 8c43b660f01c2f48cdf53176989f3c2376ee5e7a
P04   INFO: backup file pg-standby:/var/lib/postgresql/10/demo/base/12980/2703 (16KB, 95%) checksum 71663782627811bd502e8a4b17200f3d2c6fac0d
       [filtered 1235 lines of output]

Cette sauvegarde incrémentale montre que la plupart des fichiers sont copiés depuis pg-standby et que seuls quelques-uns sont copiés depuis pg-primary.

pgBackRest crée une sauvegarde depuis l'instance esclave qui est identique à une sauvegarde effectuée sur l'instance primaire. Pour ce faire, il lance/arrête la sauvegarde sur l'hôte {[hôte-pg1]}, en copiant uniquement les fichiers qui sont répliqués à partir de l'hôte {[hôte-pg2]}, puis en copiant les quelques fichiers restants à partir de l'hôte {[hôte-pg1]}. Cela signifie que les journaux et les statistiques de la base de données principale seront inclus dans la sauvegarde.

Mise à niveau de PostgreSQL

Immédiatement après la mise à niveau de PostgreSQL vers une nouvelle version majeure, le chemin pg-path pour toute la configuration de pgBackRest doit être défini sur le nouvel emplacement de la base de données et la commande stanza-upgrade doit être exécuté sur l'hôte du dépôt. Si l'instance PostgreSQL est hors ligne, utilisez l'option --no-online.

Les instructions suivantes ne se veulent pas un guide complet pour la mise à niveau de PostgreSQL, mais elles décrivent plutôt le processus général de mise à niveau d'une instance PostgreSQL primaire et d'une instance PostgreSQL esclave (standb) dans le but de présenter les étapes nécessaires dans la reconfiguration de PostgreSQL. Il est recommandé d'effectuer une sauvegarde avant la mise à niveau.

pg-primary ⇒ Arrêter la vieille instance

sudo pg_ctlcluster 10 demo stop

Arrêtez l'instance esclave (standb), car elle sera restaurée à partir de la l'instance nouvellement mise à niveau.

pg-standby ⇒ Arrêter la vieille instance

sudo pg_ctlcluster 10 demo stop

Créer une nouvelle instance et effectuer la mise à niveau.

pg-primary ⇒ Créer une nouvelle instance et effectuer la mise à niveau

sudo -u postgres /usr/lib/postgresql/11/bin/initdb \
       -D /var/lib/postgresql/11/demo -k -A peer

sudo pg_createcluster 11 demo

sudo -u postgres sh -c 'cd /var/lib/postgresql && \
       /usr/lib/postgresql/11/bin/pg_upgrade \
       --old-bindir=/usr/lib/postgresql/10/bin \
       --new-bindir=/usr/lib/postgresql/11/bin \
       --old-datadir=/var/lib/postgresql/10/demo \
       --new-datadir=/var/lib/postgresql/11/demo \
       --old-options=" -c config_file=/etc/postgresql/10/demo/postgresql.conf" \
       --new-options=" -c config_file=/etc/postgresql/11/demo/postgresql.conf"'

       [filtered 68 lines of output]
Creating script to delete old cluster                       ok

Upgrade Complete

----------------
Optimizer statistics are not transferred by pg_upgrade so,
       [filtered 4 lines of output]

Configuration des paramètres et du port de la nouvelle instance.

pg-primary:/etc/postgresql/11/demo/postgresql.conf ⇒ Configuration de PostgreSQL

archive_command = 'pgbackrest --stanza=demo archive-push %p'
archive_mode = on
listen_addresses = '*'
log_line_prefix = ''
max_wal_senders = 3
port = 5432
wal_level = replica

Mettez à jour la configuration pgBackRest sur tous les systèmes pour pointer vers la nouvelle instance.

pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Mise à jour de pg1-path

[demo]
pg1-path=/var/lib/postgresql/11/demo

[global]
archive-async=y
log-level-file=detail
repo1-host=repository
spool-path=/var/spool/pgbackrest

[global:archive-get]
process-max=2

[global:archive-push]
process-max=2

pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Mise à jour de pg-path

[demo]
pg1-path=/var/lib/postgresql/11/demo
recovery-option=primary_conninfo=host=172.17.0.4 port=5432 user=replicator

[global]
archive-async=y
log-level-file=detail
repo1-host=repository
spool-path=/var/spool/pgbackrest

[global:archive-get]
process-max=2

[global:archive-push]
process-max=2

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Upgrade pg1-path and pg2-path, disable backup from standby

[demo]
pg1-host=pg-primary
pg1-path=/var/lib/postgresql/11/demo
pg2-host=pg-standby
pg2-path=/var/lib/postgresql/11/demo

[global]
backup-standby=n
process-max=3
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

pg-primary ⇒ Copie de la configuration hba

sudo cp /etc/postgresql/10/demo/pg_hba.conf \
       /etc/postgresql/11/demo/pg_hba.conf

Avant de lancer la nouvelle instance, la commande stanza-upgrade doit être exécutée sur le serveur où se trouve le dépôt pgBackRest.

repository ⇒ Mise à niveau du stanza

sudo -u pgbackrest pgbackrest --stanza=demo --no-online \
       --log-level-console=info stanza-upgrade

P00   INFO: stanza-upgrade command begin 2.27: --no-backup-standby --log-level-console=info --log-level-stderr=off --no-log-timestamp --no-online --pg1-host=pg-primary --pg2-host=pg-standby --pg1-path=/var/lib/postgresql/11/demo --pg2-path=/var/lib/postgresql/11/demo --repo1-path=/var/lib/pgbackrest --stanza=demo

P00   INFO: stanza-upgrade command end: completed successfully

Démarrer la nouvelle instance et confirmer qu'il est installé avec succès.

pg-primary ⇒ Démarrage de la nouvelle instance

sudo pg_ctlcluster 11 demo start

Controler la configuration en utilisant la commande check.

pg-primary ⇒ Controle de la configuration

sudo -u postgres pg_lsclusters

Ver Cluster Port Status Owner    Data directory              Log file
10  demo    5432 down   postgres /var/lib/postgresql/10/demo /var/log/postgresql/postgresql-10-demo.log
11  demo    5432 online postgres /var/lib/postgresql/11/demo /var/log/postgresql/postgresql-11-demo.log

sudo -u postgres pgbackrest --stanza=demo check

Supprimer l'ancienne instance.

pg-primary ⇒ Suppression de l'ancienne instance

sudo pg_dropcluster 10 demo

Installer la nouvelle version des binaire de PostgreSQL sur l'esclave (standby) et créer l'instance.

pg-standby ⇒ Supprimer l'ancienne instance et créer une nouvelle instance

sudo pg_dropcluster 10 demo

sudo pg_createcluster 11 demo

Exécuter la commande check sur l'hôte du dépôt. L'avertissement concernant l'instance esclave est attendu puisque l'instance est en panne. L'exécution de cette commande permet de démontrer que le serveur de dépôt est conscient de l'existance d'un serveur esclave et que pgBackRest est bien configuré pour l'instance primaire.

repository ⇒ Controle de la configuration

sudo -u pgbackrest pgbackrest --stanza=demo check

P00   WARN: unable to check pg-2: [DbConnectError] raised from remote-0 protocol on 'pg-standby': unable to connect to 'dbname='postgres' port=5432': could not connect to server: No such file or directory
            	Is the server running locally and accepting
            	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Effectuez une sauvegarde complète sur la nouvelle instance, puis restaurez la sur l'instance secondaire (standby) à partir de cette sauvegarde. Le type de sauvegarde sera automatiquement changé en full si incr ou diff est demandé.

repository ⇒ Démarrage d'une sauvegarde complète

sudo -u pgbackrest pgbackrest --stanza=demo --type=full backup

pg-standby ⇒ Restauration de demo sur l'instance esclave

sudo -u postgres pgbackrest --stanza=demo --delta --type=standby restore

pg-standby:/etc/postgresql/11/demo/postgresql.conf ⇒ Configuration de PostgreSQL

hot_standby = on

pg-standby ⇒ Démarrer PostgreSQL et controler la configuration de pgBackRest

sudo pg_ctlcluster 11 demo start

sudo -u postgres pgbackrest --stanza=demo check

La sauvegarde à partir de l'esclave peut être activée maintenant que cette esclave a été remis en place.

repository:/etc/pgbackrest/pgbackrest.conf ⇒ Réactivation de la sauvegarde depuis l'esclave

[demo]
pg1-host=pg-primary
pg1-path=/var/lib/postgresql/11/demo
pg2-host=pg-standby
pg2-path=/var/lib/postgresql/11/demo

[global]
backup-standby=y
process-max=3
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y