Archivage continu et réplication

Introduction

les WAL (Write-Ahead Logging) est une approche conventionnelle pour l'écriture d'un journal de transactions.
Le principe des WAL est que pour toute modification :
1. celle-ci soit d'abord écrite dans un fichier de journal (le WAL),
2. puis elle soit réalisée sur les tables, les index, ...
En suivant cette procédure il n'est plus nécessaire d'écrire les pages de données vers le disque à chaque validation de transaction.
En cas de défaillance chaque changement qui n'a pas été appliqué aux pages de données peut être ré-exécuté depuis les enregistrements du journal.
On parle de récupération roll-forward connue sous le nom de REDO.

En réalité les informations stockées dans les WAL ne sont pas des directives SQL, mais des pages de mémoire de masse de longueur de 8 kio correspondant aux zones impactées dans les divers fichiers. En conséquence il est inutile d'essayer d'en interpréter le contenu car les instructions ayant provoqué la modification des pages n'y sont pas stokées.

En raison de son aptitude à restaurer la base de données en cas de crash, les systèmes de fichiers journalisés ne sont pas nécessaires et peuvent même nuire à la performance. Pour éviter cela sous Linux il est possible de configurer un système de fichier ext3 avec l'option data=writeback.

Avantages

Les avantages sont :
- réduction significative du nombre d'écritures sur le disque car seul le journal des transactions nécessite d'y être écrit au moment où la transaction est validée,
- récupération automatique de la base de données en cas de crash avec garantie de cohérence. l'état correspondra à celui du dernier WAL enregistré,
- possibilité de sauvegarde en ligne et de récupération de l'état à un moment antérieur :
  - il est possible de revenir à tout instant couvert par les données disponibles dans les WAL.
  - Il suffit de restaurer une ancienne sauvegarde puis de rejouer les WAL jusqu'au moment désiré.

Synchronisation des WAL

Suite à une écriture les fichiers ne sont pas nécessairement écrits sur les unités de stockage.
Souvent des optimisations par mémoire tampon sont réalisées.
La synchronisation consiste à s'assurer que les fichiers sont bien transférés dans la mémoire de masse.
Elle est assurée par la méthode indiquée par wal_sync_method = méthode avec comme valeurs possibles :
- open_datasync utilisation de open()
- fdatasync appel de fdatasync() à chaque COMMIT,
- fsync appel de fsync() à chaque COMMIT.
Il est possible de ne pas se soucier la synchronisation des WAL en utilisant le paramètre wal_sync_method = OFF, mais...
dans ce cas lors d'arrêt brutal il peut y avoir corruption de données !

Le mode fsync = off est très déconseillé, mais il permet un gain significatif de performances. Il existe cependant quelques contextes pertinents tels que durant les restaurations ou encore dans le cas de bases de données en read only. Dans la plupart des cas on préférera utiliser synchronous_commit = OFF qui est quasiment aussi avantageux en performances et qui supporte également les arrêts brutaux et autres crashs.

La commande système pg_test_fsync permet de déterminer quelle est la méthode la plus performante sur notre système.

La plupart des disques y compris les SSD sont pourvus de cache. Ceci est vérifiable par la commande (sous Linux) hdparm -I device. Afin de garantir l'écriture des données en cas de crash il faudra le désactiver, ce qui peut se réaliser par la commande hdparm -W 0 device.

`COMMIT` synchrone/asynchrone

Lors de l'utilisation des WAL deux modes sont possibles :
- commit asynchrone entraînera un enregistrement différé des WAL,
- commit synchrone entraînera l'attente du retour de la synchronisation des WAL sur le disque avant de poursuivre tout traitement.
Le paramètre synchronous_commit permet de choisir le comportement à adopter :
- c'est une variable utilisateur pouvant être modifiée à tout instant.

L'intérêt est de permettre une accélération significative de la performance, mais au détriment de la garantie d'écriture et donc avec risque de pertes de données en cas de crash.

`COMMIT` synchrone/asynchrone

les valeurs possibles de synchronous_commit sont :
- off mode le plus làche, pas de contrainte de réplication,
- on pour une écriture sur les wal des serveurs répliqués,
- local pour une synchronisation locale uniquement,
- remote_write pour une confirmation du transfert vers les wal des serveurs répliqués,
- remote_apply pour une confirmation de la mise à jour des serveurs répliqués.
la liste des serveurs répliqués devant confirmer la transaction est définie par synchronous_standby_names.

Un standby name se définit par le paramètre application_name indiqué dans le fichier recovery.conf exigé en mode réplication.

Pour indiquer que l'on souhaite la réponse d'au moins 2 serveurs répliqués quelconques il faudra positionner le paramètre synchronous_standby_names = '2 (*)'.

Configuration des WAL

La configuration comprends 3 sections distinctes :
- le paramétrage des WAL,
- la définition des check points qui sont les points de synchronisation mémoire vive/mémoire de masse,
- la paramétrage de l'archivage, c'est ici que se décidera si les WAL sont à activer.

la plupart des valeurs seront à positionner dans le fichier postgresql.conf.

Configuration des WAL

Exemple de paramétrage avec activation des WAL :

# la commande à utiliser pour archiver les WAL
archive_command = 'cp %p /net/rescue/var/tmp/test/%f'
# la durée maximale séparant 2 archives
archive_timeout = 60
# l'archivage des WAL est activé
archive_mode = on
# le mode d'archivage est archive
wal_level = replica

À propos des fichiers WAL

Le répertoire dédié aux WAL est data_directory/pg_wal.
Les WAL sont des fichiers de taille fixe de 16 MiB (défini à la compilation de Postgresql).
Dès que l'espace maximal est atteint le fichier courant est archivé et un nouveau fichier est commencé.
Par le paramètre archive_command il est possible d'exécuter une commande spécifique après chaque génération de fichier WAL.
Le paramètre archive_timeout force la génération d'un nouveau segment au delà du temps indiqué en secondes.

L'utilisation de archive_command et archive_timeout permet de réaliser un système d'archivage répliqué.

Un fichier WAL est pré-alloué sur le disque afin que PostgreSQL ne soit pas confronté à des problèmes d’espace.

La commande archive_command permet l'utilisation des paramètres %p et %f qui se substituent respectivement au chemin complet du fichier et au seul nom du fichier. Il est ainsi possible de transférer chaque fichier WAL dans un espace dédié à leur archivage.

À propos des fichiers WAL

L'espace virtuellement adressable par les wal est celui des LSN (Log Sequence Number).
Il est représenté par un entier non signé de 64 bits.
Il est matérialisé dans des fichiers de 16 MiB (par défaut) dont le nom représente la partie externe de l'adresse.
Soit un fichier WAL dont le nom est 00000001000000020000005A, celui-ci se décompose ainsi :
- les 8 premiers chiffres correspondent au TimeLineID (ici 00000001),
- les 10 chiffres suivants incrémentent un compteur hexadécimal réparti sur les 16 digits restants (ici 000000020000005A).
la fonction pg_current_wal_lsn() permet d'obtenir la position de l'index d'écriture dans ce fichier.
la fonction pg_walfile_name(LSN) permet d'obtenir le nom du fichier correspondent à une valeur d'adresse.

Les TimeLineID commencent à 1 au premier lancement du cluster puis s'incrémentent à chaque nouvelle restauration permettant ainsi de distinguer les différents niveaux d'archives.

À propos des fichiers WAL

Exemple de récupération de la position LSN courante :

SELECT pg_current_wal_lsn();
 pg_current_wal_lsn 
--------------------------
 2A/DC9F0880
(1 row)

Exemple de récupération du nom du fichier correspondant :

SELECT pg_walfile_name('2A/DC9F0880');
     pg_walfile_name 
--------------------------
 000000010000002A000000DC
(1 row)

la commande CHECKPOINT réalisera une synchronisation de la mémoire de masse.

Lors de l'évolution du système, des WAL deviennent inutiles. Afin d'éviter de gaspiller des ressources de traitement PostgreSQL renommera les fichiers de journaux devenu inutiles en leur donnant un nom qui sera utilisé dans le futur. C'est la raison pour laquelle il apparaîtra parfois des journaux situés au delà du journal courant, ce qui se vérifie à l'aide de la commande SELECT pg_walfile_name(pg_current_wal_lsn());.

À propos des checkpoints

Le rôle de la commande CHECKPOINT est de libérer l'espace devenu inutile dans les WALs.
Le système assurera cette opération de façon automatique.
Le comportement peut être modifié par plusieurs paramètres :
- checkpoint_timeout définit le délai à partir duquel un checkpoint sera automatiquement exécuté en cas de faible activité,
- checkpoint_completion_target définit le temps qui sera utilisé pour transférer la mémoire vers les fichiers (en fraction de checkpoint_timeout),
- max_wal_size définit l'espace maximal que devrait occuper les WALs sur le cluster, en cas de débordement un checkpoint est généré,
- min_wal_size définit l'espace à réserver, et donc le nombre de WALs à recycler,
- wal_keep_size définit l'espace à conserver dans le passé, ceci est utile pour le mode de réplication par streaming,
- checkpoint_warning définit le seuil d'alerte, temps à partir duquel il est estimé que deux checkpoints sont trop rapprochés.

Les WAL ne peuvent être supprimés sans altérer le fonctionnement du système car il contiennent éventuellement des informations nécessaires aux tables. C'est la raison pour laquelle il est indispensable de recourir à l'utilisation de CHECKPOINT qui rendra tous les enregistrements antérieurs inutiles.

La fréquence des checkpoints peut devenir trop importante si la base de données est fortement sollicitée et que le paramètre checkpoint_warning indique un nombre trop bas de secondes entre deux checkpoints automatiquement générés, ce qui conduira à la production de messages dans les logs. Pour éviter cela il faudra :

soit augmenter max_wal_size permettant ainsi un plus grand nombre de modifications dans le temps défini par checkpoint_warning,
soit diminuer checkpoint_warning permettant ainsi d'avoir des checkpoints plus rapprochés,

Fonctions dédiées aux fichiers WAL

Parmi les fonctions permettant le traitement des WAL on notera :
- pg_start_backup('label') s'utilise avant de démarrer une sauvegarde à chaud. Elle a pour effet :
  - de lancer un checkpoint,
  - de positionner dans le fichier backup_label les informations relatives au début de la sauvegarde,
- pg_stop_backup() termine une sauvegarde à chaud. Elle a pour effet :
  - de transférer le fichier backup_label dans l'espace des archives WAL en lui donnant un nom tel que 00000001000000000000005C.00000028.backup,
  - de forcer le passage au segment de WAL suivant,
- pg_switch_wal() force le passage au segment de WAL suivant,
- pg_ls_waldir() permet d'afficher les WAL contenus dans le répertoire dédié.

Maintenance des fichiers WAL

Les fichiers WAL peuvent conduire à une consommation excessive de l'espace de travail.
En cas de saturation de cet espace le serveur s'interrompt en envoyant des messages de panique !
Pas d'affolement, il suffit de faire de la place et tout rentrera dans l'ordre.
Pour cela la commande pg_resetwal -D data_directory assurera cette mission :
- en repérant les fichiers encore utilisés dans le répertoire pg_wal,
- en supprimant ceux qui sont devenus inutiles.
La commande pg_controldata -D data_directory permet de vérifier l'état de l'espace de travail du serveur.
Ces commandes opèrent serveur arrété.
La commande pg_waldump fichier_wal permet d'analyser le contenu d'un WAL.

Depuis la version 9.5 il est possible de réduire l'espace demandé par les WALs grâce à l'utilisation de le compression de type LZ. Ceci s'active par le paramètre wal_compression=on et apporte également l'avantage de réduire les entrées-sorties, mais au détriment de consommation CPU.

Pour obtenir de l'aide

Sur le site officiel de PostgreSQL :

Une explication sur la configuration des journaux de transaction : docs.postgresql.fr/current/wal-configuration.html
La configuration serveur relative aux WAL : www.postgresql.org/docs/current/static/runtime-config-wal.html
À propos de la fiabilité en cas de crash : www.postgresql.org/docs/current/static/wal-reliability.html
Une explication sur les journaux de transaction : www.dalibo.org/glmf108_postgresql_et_ses_journaux_de_transactions
à propos du mode synchronous_commit par quadrant : blog.2ndquadrant.com/evolution-fault-tolerance-postgresql-synchronous-commit

Formation administration PostgreSQL

Les journaux WAL

Introduction

Avantages

Synchronisation des WAL

`COMMIT` synchrone/asynchrone

`COMMIT` synchrone/asynchrone

Configuration des WAL

Configuration des WAL

À propos des fichiers WAL

À propos des fichiers WAL

À propos des fichiers WAL

À propos des checkpoints

Fonctions dédiées aux fichiers WAL

Maintenance des fichiers WAL

Pour obtenir de l'aide

Sur le site officiel de PostgreSQL :

Formation administration PostgreSQL

Les journaux WAL

Introduction

Avantages

Synchronisation des WAL

COMMIT synchrone/asynchrone

COMMIT synchrone/asynchrone

Configuration des WAL

Configuration des WAL

À propos des fichiers WAL

À propos des fichiers WAL

À propos des fichiers WAL

À propos des checkpoints

Fonctions dédiées aux fichiers WAL

Maintenance des fichiers WAL

Pour obtenir de l'aide

Sur le site officiel de PostgreSQL :

`COMMIT` synchrone/asynchrone

`COMMIT` synchrone/asynchrone