Décrire la journalisation en écriture anticipée

  • 3 minutes

Lorsque des modifications sont apportées dans la base de données, telles que INSERTS ou DELETES, ces modifications sont d’abord écrites dans un journal, puis écrites uniquement dans des fichiers de données sur le disque. Cette opération est appelée journal en écriture anticipée, car les modifications sont écrites dans le journal, avant de les valider dans des fichiers de données. En cas de problème, comme une panne d'électricité, le journal conserve 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 qu’en écrivant d’abord des modifications dans le journal, les modifications apportées aux tables et aux index peuvent être écrites par lots, plutôt que 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 de manière séquentielle. Des écritures plus lentes dans des tables et des 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.

Note

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 en écriture anticipée et de l’optimiser pour votre charge de travail :

  • commit_delay : délai entre la validation de transaction et l'écriture du log sur le disque.
  • wal_buffers : nombre de mémoires tampons de page de disque dans la mémoire partagée pour la journalisation en écriture anticipée (WAL).
  • max_wal_size : taille maximale pour laisser le wal croître avant de déclencher le point de contrôle automatique.
  • wal_writer_delay : intervalle de temps entre les purges WAL effectuées par l'écrivain WAL.
  • wal_compression : indique si les écritures de pages complètes 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 ou LOGICAL.

Restauration à un point dans le temps

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

Azure Database pour PostgreSQL est un service managé, qui n’autorise pas l’accès au système de fichiers sous-jacent. Toutefois, elle 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 que vous avez spécifiés pour conserver les sauvegardes, jusqu’à 35 jours maximum. Pour spécifier la durée pendant laquelle les sauvegardes doivent être conservées pour :

  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 sauvegarde (en jours). La barre de curseurs vous permet de sélectionner le nombre de jours pendant lesquels vous souhaitez que les sauvegardes soient conservées.
  4. Sélectionnez Enregistrer pour conserver vos modifications.