Décrire la journalisation WAL

  • 3 minutes

Lorsque des modifications sont apportées à la base de données, comme des INSERTS ou des DELETES, ces modifications sont d’abord écrites dans un journal, puis seulement alors écrites dans des fichiers de données sur le disque. Cette opération est appelée le journal WAL (write-ahead log), car les modifications sont écrites dans le journal, avant leur validation dans des fichiers de données. En cas de problème, comme une perte d’alimentation, le journal contient toujours les données les plus récentes et peut être utilisé pour garantir que la base de données est dans un état cohérent.

Un deuxième avantage est que, en écrivant d’abord les modifications dans le journal, les modifications apportées aux tables et aux index peuvent être écrites par lots, plutôt qu’individuellement. Ce processus réduit le nombre d’écritures de disque requises pour maintenir les tables et les index à jour. Les écritures dans le journal sont rapides, car elles sont effectuées séquentiellement. Les écritures plus lentes dans les tables et les index peuvent être effectuées en toute sécurité dans des lots, car toutes les données peuvent être récupérées à partir du journal. Pour les charges de travail qui impliquent généralement de nombreuses petites mises à jour, les performances sont améliorées.

Remarque

Pour les implémentations locales de PostgreSQL, le fichier journal est stocké dans le répertoire pg_wal. Azure Database pour PostgreSQL ne fournit pas d’accès au système de fichiers. Vous n’avez donc pas à vous soucier du stockage physique du fichier journal.

Il existe plusieurs paramètres de serveur qui vous permettent de contrôler le fonctionnement de la journalisation WAL et de l’optimiser pour votre charge de travail :

  • commit_delay : le délai entre la validation de la transaction et le vidage du journal sur le disque.
  • wal_buffers : nombre de mémoires tampon de page de disque en mémoire partagée pour la journalisation WAL.
  • max_wal_size - définit la taille maximale de croissance du fichier WAL avant de déclencher un point de contrôle automatique.
  • wal_writer_delay - intervalle de temps entre les vidages de fichier WAL effectués par l’enregistreur WAL.
  • wal_compression : si les écritures en page complète dans le fichier WAL sont compressées.
  • wal_level : détermine la quantité d’informations écrites dans le WAL. Les valeurs autorisées sont REPLICA et LOGICAL.

Restauration dans le temps

L’objectif principal du journal WAL est de garantir la cohérence et la durabilité de la base de données en cas d’incident. La version locale de PostgreSQL permet au journal d’être utilisé en tant qu’archive, ce qui vous permet de restaurer à un moment donné à l’aide des paramètres de configuration archive_mode et archive_command.

Azure Database pour PostgreSQL est un service géré qui n’autorise pas l’accès au système de fichiers sous-jacent. Toutefois, il inclut des sauvegardes complètes automatiques du serveur, y compris toutes les bases de données. Cette sauvegarde vous permet de recréer vos données à un point dans le temps. Les sauvegardes sont planifiées automatiquement et sont effectuées une fois par jour. Si vous avez besoin de restaurer, vous pouvez restaurer jusqu’au nombre de jours spécifié pour la conservation des sauvegardes (durée maximale de 35 jours). Pour spécifier la durée pendant laquelle les sauvegardes doivent être conservées :

  1. Dans le portail Azure, accédez à votre serveur flexible Azure Database pour PostgreSQL.
  2. Dans la section Vue d’ensemble, sélectionnez votre Configuration.
  3. Sous Sauvegardes, recherchez Période de rétention de la sauvegarde (en jours). La barre de curseur vous permet de sélectionner le nombre de jours pour lequel vous souhaitez conserver les sauvegardes.
  4. Sélectionnez Enregistrer pour conserver vos modifications.