Mise en place du clonage instantané de bases de données dans PostgreSQL 18

• PostgreSQL 18 peut cloner une base de données presque instantanément en combinant la stratégie de copie de fichiers (FILE_COPY) avec les fonctionnalités de clonage du système de fichiers
• Avec le nouveau paramètre file_copy_method = clone, il est possible d’exploiter les capacités de clonage des systèmes de fichiers modernes (FICLONE) comme XFS, ZFS et APFS
• Selon les benchmarks, pour le clonage d’une base de données de 6 Go, la méthode existante WAL_LOG prend environ 67 secondes, tandis que la méthode par clonage descend à environ 0,2 seconde
• Les bases clonées partagent au départ les mêmes blocs physiques, puis se séparent via le mécanisme copy-on-write lors des écritures
• En revanche, le clonage n’est possible qu’en l’absence de connexions actives et ne fonctionne qu’au sein d’un même système de fichiers

---

Structure de clonage basée sur les templates dans PostgreSQL

• Dans PostgreSQL, la commande CREATE DATABASE dbname crée en interne une nouvelle base en clonant la base template1
  • Cela correspond au même comportement que CREATE DATABASE dbname TEMPLATE template1
• Il est possible d’indiquer une autre base à la place de template1, ce qui permet le clonage via des templates personnalisés
• Dans PostgreSQL 18, ce système de templates a été étendu vers une architecture permettant un clonage instantané

CREATE DATABASE ... STRATEGY

• Depuis PostgreSQL 15, le paramètre CREATE DATABASE ... STRATEGY permet de choisir la méthode de clonage
  • La valeur par défaut est WAL_LOG, qui effectue une réplication bloc par bloc via le Write-Ahead Log
  • Cette méthode réduit la charge I/O et améliore la prise en charge de la concurrence, mais elle reste lente pour les gros clonages
• En spécifiant STRATEGY=FILE_COPY, il est possible de revenir à la méthode traditionnelle de copie de fichiers ; PostgreSQL 18 y ajoute une nouvelle option de clonage

FILE_COPY et file_copy_method

• Le paramètre file_copy_method de PostgreSQL 18 contrôle la méthode de clonage de fichiers au niveau du système d’exploitation
  • La valeur par défaut est copy, qui lit tous les octets et les réécrit à un nouvel emplacement
  • En passant à clone, PostgreSQL utilise la fonctionnalité de clonage du système de fichiers (FICLONE) pour réaliser un clonage instantané sans consommation d’espace supplémentaire
• Systèmes de fichiers pris en charge : XFS, ZFS, APFS, FreeBSD ZFS
• Procédure de configuration
  • Déployer le cluster PostgreSQL sur l’un de ces systèmes de fichiers
  • Définir file_copy_method = clone, puis recharger la configuration

Résultats des benchmarks

• Après la création d’une base de test d’environ 6 Go (source_db), deux méthodes ont été comparées
  • Méthode WAL_LOG : 67 000 ms (environ 67 secondes)
  • Méthode FILE_COPY + clone : 212 ms
• À volume de données identique, on observe un gain de performance supérieur à 300x
• La base clonée (fast_clone) n’utilise quasiment pas d’espace disque supplémentaire

Principe de fonctionnement des données clonées

• Avec file_copy_method = clone, seules les métadonnées du système de fichiers sont dupliquées, ce qui fait que les deux bases partagent les mêmes blocs physiques
• La taille de base remontée par PostgreSQL reste la même taille logique (environ 6 Go)
• Lorsqu’une écriture survient, le mécanisme copy-on-write (COW) s’active et sépare les pages concernées
  • La page contenant les lignes modifiées
  • La page où de nouveaux tuples sont écrits
  • Les pages d’index ainsi que les pages FSM et visibility map, entre autres
• L’exécution de VACUUM provoque également des séparations de pages supplémentaires

Vérification des blocs partagés sur XFS

• La commande filefrag -v permet de vérifier si deux bases partagent les mêmes blocs physiques
  • À l’état initial, toutes les extents sont marquées shared
  • Après mise à jour de quelques lignes, les 40 premiers blocs (environ 160 Ko) sont séparés et passent à des adresses physiques différentes
  • Les autres extents restent partagées

Points d’attention et limites

• Aucune connexion active ne doit exister sur la base source au moment du clonage
  • Il s’agit d’une contrainte de PostgreSQL, et non d’un problème du système de fichiers
  • En production, il est courant d’utiliser une base template dédiée
• Le clonage n’est possible qu’au sein d’un seul système de fichiers
  • Si plusieurs tablespaces sont répartis sur différents points de montage, PostgreSQL revient à une copie classique
• Dans les services cloud managés (AWS RDS, Google Cloud SQL, etc.), l’accès au système de fichiers n’est pas possible, donc cette fonctionnalité ne peut pas être utilisée
  • En revanche, dans un environnement VM autogéré ou bare metal, un contrôle complet reste possible

Conclusion

• La fonctionnalité file_copy_method = clone de PostgreSQL 18 exploite directement les capacités de clonage au niveau du système d’exploitation pour
  réduire de façon spectaculaire le temps de clonage de bases de données volumineuses
• Elle permet de mettre en place des workflows de bases de données clonables et réinitialisables instantanément pour les environnements de test, de développement et d’apprentissage
• Il reste toutefois nécessaire de concevoir l’exploitation en tenant compte de la contrainte sur les connexions actives et de la limitation à un système de fichiers unique