PostgreSQL 9.6 vient de sortir et la plupart des utilisateurs de postgres commenceront à se demander comment passer à la nouvelle version majeure. Cet article a pour but de montrer différentes procédures de mise à niveau de votre serveur PostgreSQL.
La mise à niveau vers une nouvelle version majeure est une tâche qui a un ratio élevé de préparation sur le temps d'exécution total. Plus précisément lorsque vous sautez une version au milieu, par exemple lorsque vous passez de la version 9.3 à la version 9.5.
Versions ponctuelles
D'un autre côté, les mises à niveau ponctuelles ne nécessitent pas autant de préparation. Généralement, la seule exigence est que le service postgres soit redémarré. Il n'y a aucune modification de la structure de données sous-jacente, il n'est donc pas nécessaire de vider et de restaurer. Dans le pire des cas, vous devrez peut-être recréer certains de vos index après avoir terminé la mise à niveau de la version ponctuelle.
Il est très sage de toujours rester sur la dernière version ponctuelle, afin de ne pas tomber sur un bogue connu (et probablement corrigé). Cela signifie qu'une fois la dernière version disponible, planifiez la mise à niveau dès que possible.
Mise à jour de la version majeure
Lorsque vous effectuez des tâches complexes comme celle-ci, il est bon de considérer toutes les options possibles pour obtenir le résultat final.
Pour les mises à niveau majeures, vous pouvez emprunter trois chemins :
- Restauration de mise à niveau à partir d'un vidage logique
- Mise à niveau physique
- Mise à niveau en ligne
Laissez-moi vous expliquer chacun en détail :
1) Mettre à niveau la restauration à partir d'un vidage logique
Il s'agit de la manière la plus simple de mettre à niveau la structure de données de votre cluster.
Pour faire court, le processus ici nécessite un vidage logique utilisant pg_dump de l'ancienne version, et pg_restore sur un cluster propre créé avec la version nouvellement installée.
Les points clés en faveur de l'utilisation de ce chemin sont :
- C'est le plus testé
- La compatibilité remonte aux versions 7.0, vous pouvez donc éventuellement passer de la version 7.x à l'une des versions récentes
Raisons pour lesquelles vous devriez éviter d'utiliser cette option :
- Le temps d'arrêt total sur les grandes bases de données peut être un problème, car vous devez arrêter les connexions en écriture avant de commencer à exécuter pg_dump ;
- S'il y a beaucoup d'objets volumineux dans la base de données, pg_dump sera lent. Même en le faisant en parallèle. La restauration sera encore plus lente que pg_dump lorsque de nombreux objets volumineux sont stockés dans la base de données ;
- Cela nécessite un double espace disque ou la suppression de l'ancien cluster avant la restauration ;
Sur les serveurs avec plusieurs cœurs de processeur, il est possible d'exécuter pg_dump en parallèle en utilisant le format de répertoire. Une fois qu'il a terminé, restaurez également en parallèle, en utilisant le commutateur -j à la fois dans pg_dump et pg_restore. Mais vous ne pouvez pas démarrer le processus de restauration tant que le vidage complet n'est pas terminé.
2) Mise à niveau physique
Ce type de mises à niveau est disponible depuis la version 9.0 pour effectuer des mises à niveau sur place à partir de versions aussi anciennes que 8.3. Ils sont dits "sur place" car ils sont effectués sur le même serveur, et de préférence sur le même répertoire de données.
Avantages de ce type de mises à jour :
- Vous n'avez pas besoin d'espace pour une autre copie du cluster.
- Les temps d'arrêt sont beaucoup plus faibles par rapport à l'utilisation de pg_dump.
Il y a pas mal d'inconvénients :
- Une fois que vous démarrez la nouvelle version de PostgreSQL, il n'est plus possible de revenir à l'ancienne version (le cluster ne fonctionnera qu'avec la nouvelle version à partir de là).
- Les statistiques sont mises à zéro après la mise à niveau, donc juste après le démarrage de la nouvelle version de PostgreSQL, une analyse à l'échelle du cluster doit être exécutée.
- De nombreux bogues ont été trouvés au cours des dernières années concernant pg_upgrade, ce qui rend certains administrateurs de base de données réticents à utiliser cette méthode pour la mise à niveau.
- Certaines personnes ont rencontré des problèmes lors du saut d'une version majeure, par exemple en passant de la version 9.2 à la version 9.4.
- Avec de grands catalogues, les performances seront médiocres (clusters avec de nombreuses bases de données ou bases de données avec plusieurs milliers d'objets).
Vous pouvez également exécuter pg_upgrade sans l'option –link (dans ce cas, pg_upgrade générera une deuxième copie sur le disque de votre cluster) afin de pouvoir revenir à l'ancienne version. Mais vous perdrez les deux avantages énumérés ci-dessus.
3) Mise à niveau en ligne
La procédure à suivre pour cette méthode serait la suivante :
- Installez les deux versions afin de pouvoir les faire fonctionner en parallèle. Cela peut être fait sur le même serveur ou en utilisant deux serveurs physiques.
- Créez une copie initiale et répliquez les modifications à partir du moment où vous avez démarré la copie sur le nœud source (ceci serait similaire à un pg_dump initial).
- Continuez à répliquer logiquement les modifications jusqu'à ce que le décalage soit proche de zéro.
- Repointez les informations de connexion du serveur d'application pour vous connecter au nouveau serveur.
Ce type de mise à niveau est disponible depuis l'apparition des premières solutions de réplication basées sur des déclencheurs. En d'autres termes, depuis que Slony-I était là.
Les solutions de réplication basées sur des déclencheurs ne se soucient pas de la version que vous avez d'un côté ou de l'autre, car elles copient les modifications à l'aide des commandes SQL prises en charge.
Les outils de réplication basés sur les déclencheurs recommandés, dans l'ordre où ils apparaissent, sont :
- skytools :PgQ + londiste
- Slony-I
Cela devrait être le moyen préféré pour la mise à niveau. Voyons les avantages d'utiliser cette méthode :
- Aucun temps d'arrêt !
- Idéal également pour la mise à niveau vers du matériel plus récent.
- Test en ligne du cluster avec la nouvelle version (requêtes en lecture seule, ou vous pourriez vous retrouver avec des conflits).
- Réduit considérablement toutes les surcharges de table et d'index.
Il y a quelques inconvénients :
- Il a besoin d'un double espace de stockage, car il doit stocker une deuxième copie de vos données.
- Comme il est basé sur des déclencheurs, le système doit écrire chaque modification deux fois, ce qui signifie qu'il y aura plus d'E/S disque sur le serveur source (ancienne version du cluster).
- Toutes les tables doivent avoir une clé primaire, afin que l'outil de réplication puisse individualiser les tuples qui sont mis à jour ou supprimés
- Il ne réplique pas les tables de catalogue, il ne répliquera donc pas les objets volumineux.
- L'utilisation de base ne couvre pas les modifications de schéma. Cela peut être fait, mais pas de manière transparente.
Une nouvelle frontière avec pglogical
Depuis PostgreSQL 9.4, nous avons un décodage logique des journaux de transactions. Cela signifie que nous pouvons maintenant décoder les transactions du WAL et manipuler la sortie.
Un tout nouveau monde de possibilités est apparu dans le domaine de la réplication. Les déclencheurs ne sont plus nécessaires pour accomplir la réplication logique !
Cela signifie essentiellement que vous n'avez plus besoin d'enregistrer une copie séparée de toutes les insertions, mises à jour et suppressions à l'aide de déclencheurs. Vous pouvez simplement obtenir ces opérations de manipulation de données à partir des journaux de transactions, en les décodant. Ensuite, c'est l'outil que vous utilisez qui doit manipuler la sortie et l'envoyer au nœud abonné en aval. Dans ce cas, cet outil est pglogical.
Alors, qu'est-ce que tout cela signifie ?
Eh bien, si vous êtes sur une version 9.4 ou 9.5 de PostgreSQL et que vous souhaitez mettre à niveau vers la 9.6, vous pouvez effectuer une mise à niveau en ligne comme celle détaillée ci-dessus, mais en utilisant pglogical au lieu de l'une des solutions de réplication basées sur des déclencheurs.
Je n'irai pas plus loin dans les détails car il existe d'autres blogs sur ce sujet particulier, comme celui écrit par Petr Jelinek :PGLogical 1.1 packages for PostgreSQL 9.6beta1
Conclusion
Selon le schéma de votre base de données, la taille des données, la fenêtre de temps d'arrêt possible, la version de l'installation actuelle de PostgreSQL, vous pouvez choisir une option plutôt qu'une autre ou celle qui vous convient le mieux.
- Si votre base de données est petite et qu'il existe une fenêtre de maintenance appropriée que vous pouvez utiliser, vous pouvez opter pour l'exécution d'un pg_dump et d'un pg_restore. Selon la taille de l'ensemble de données, il y a un point où l'option n'est plus faisable.
- Si vous avez une grande base de données (plusieurs centaines de Go, voire des To de données), vous devrez rechercher d'autres options comme une mise à niveau sur place avec pg_upgrade ou une mise à niveau en ligne.
- Si vous effectuez une mise à niveau de la version 8.3 ou supérieure vers n'importe quelle version 9.x, vous pouvez utiliser pg_upgrade.
- Pour les versions antérieures à la 8.3, vous devrez opter pour l'une des solutions de réplication logique comme londiste ou slony.
- Si vous utilisez une base de données 9.4 ou 9.5, vous feriez mieux d'utiliser pglogical.
Rappelez-vous toujours que pour la réplication logique, les tables doivent avoir une clé primaire.
Avec pglogical, cette règle n'est pas si stricte :vous pouvez répliquer des tables en insertion uniquement. Mais pour les mises à jour et les suppressions, il est toujours obligatoire d'avoir une clé primaire ou une IDENTITÉ DE RÉPLIQUE sur la table.
Si vous avez besoin d'aide pour mettre à niveau votre base de données PostgreSQL, vous pouvez consulter les
services de mise à niveau 2ndQuadrant.
