La semaine dernière, j'étais au Nordic PGDay 2018 et j'ai eu pas mal de conversations sur l'outil que j'ai écrit, à savoir pglupgrade , pour automatiser les mises à niveau des versions majeures de PostgreSQL dans une configuration de cluster de réplication. J'étais assez heureux qu'il ait été entendu et que d'autres personnes de différentes communautés aient donné des conférences lors de rencontres et d'autres conférences sur les mises à niveau à temps d'arrêt quasi nuls à l'aide de la réplication logique. Étant donné qu'il y a une conférence que j'ai donnée au PGDAY'17 Russie, PGConf.EU 2017 à Varsovie et enfin au FOSDEM PGDay 2018 à Bruxelles, j'ai pensé qu'il valait mieux créer un article de blog pour garder cette présentation disponible pour les gens qui pourraient ne pas se rendre à l'une des conférences susmentionnées. Si vous souhaitez participer directement à la discussion et ignorer la lecture de cet article de blog, voici votre lien :Mises à niveau automatisées avec temps d'arrêt quasi nul des clusters PostgreSQL dans le cloud
La principale motivation derrière le développement de cet outil était de proposer une solution pour minimiser les temps d'arrêt lors des mises à jour majeures de version qui affectent malheureusement presque tous ceux qui utilisent PostgreSQL. Actuellement, nous n'avons pas d'outil permettant aux utilisateurs de PostgreSQL de mettre à niveau leurs bases de données sans temps d'arrêt et c'est clairement un problème pour de nombreux utilisateurs, en particulier les entreprises. Et, si nous voulons résoudre le problème de mise à niveau, nous devrions penser à plus d'un serveur (sera appelé cluster à partir de maintenant), simplement parce que peu de gens utilisent plus qu'un seul serveur de base de données. Le scénario le plus courant consiste à configurer la réplication physique en continu à des fins de haute disponibilité ou de mise à l'échelle des requêtes de lecture.
Mises à jour de la base de données
Avant de plonger dans la solution, discutons un peu du fonctionnement général des mises à niveau de la base de données. Il existe quatre principales approches possibles pour les mises à niveau de la base de données :
- La première approche serait que les bases de données gardent leur format de stockage identique ou au moins compatible entre les versions. Cependant, cela est difficile à garantir à long terme, car de nouvelles fonctionnalités peuvent nécessiter des changements dans la façon dont les données sont stockées ou ajouter plus d'informations de métadonnées pour fonctionner correctement. De plus, les performances sont souvent améliorées en optimisant les structures de données.
- La deuxième approche consiste à faire une copie logique (vidage) de l'ancien serveur et à la charger sur le nouveau serveur. Il s'agit de l'approche la plus traditionnelle qui nécessite que l'ancien serveur ne reçoive aucune mise à jour pendant le processus et entraîne des temps d'arrêt prolongés d'heures voire de jours sur de grandes bases de données.
- La troisième option consiste à convertir les données de l'ancien format vers le nouveau. Cela peut être fait à la volée pendant que le nouveau système est en cours d'exécution, mais entraîne une pénalité de performance difficile à prévoir car cela dépend des modèles d'accès aux données, ou cela peut être fait hors ligne pendant que les serveurs sont en panne, ce qui entraîne à nouveau prolongé temps d'arrêt (bien que souvent plus courte que la deuxième méthode).
- La quatrième méthode consiste à utiliser un vidage logique pour enregistrer et restaurer la base de données tout en capturant les modifications qui se produisent entre-temps et les répliquer logiquement dans la nouvelle base de données une fois la restauration initiale terminée. Cette méthode nécessite l'orchestration de plusieurs composants, mais réduit également la durée pendant laquelle la base de données ne peut pas répondre aux requêtes.
Méthodes de mise à jour dans PostgreSQL
Les mises à niveau PostgreSQL peuvent être associées aux quatre méthodes répertoriées ci-dessus. Par exemple, les versions mineures de PostgreSQL, qui ne contiennent pas de nouvelles fonctionnalités mais uniquement des correctifs, ne modifient pas le format de données existant et correspondent à la première approche. Pour la deuxième approche, PostgreSQL fournit des outils appelés pg_dump et pg_restore qui effectuent la sauvegarde et la restauration logiques. Il existe également l'outil pg_upgrade (c'était un module contrib et déplacé vers l'arborescence principale dans PostgreSQL 9.5) qui effectue la conversion hors ligne (les serveurs ne fonctionnent pas) de l'ancien répertoire de données vers le nouveau, qui peut s'intégrer dans la troisième option. Pour la quatrième approche, il existe des solutions tierces basées sur des déclencheurs telles que Slony pour la mise à niveau, mais elles comportent certaines mises en garde que nous aborderons plus tard.
Les méthodes traditionnelles de mise à niveau ne peuvent que mettre à niveau le serveur principal tandis que les serveurs de réplique doivent être reconstruits par la suite (conversion hors ligne) . Cela entraîne des problèmes supplémentaires de disponibilité et de capacité du cluster, augmentant ainsi efficacement le temps d'indisponibilité perçu de la base de données du point de vue des applications et des utilisateurs. La réplication logique permet la réplication pendant que le système est fonctionnel et l'effort de test peut être géré entre-temps (conversion en ligne) .
Il existe différentes méthodes de mise à niveau applicables à différents environnements. Par exemple, pg_dump permet la mise à niveau à partir de très anciennes versions (c'est-à-dire 7.0) aux versions récentes, donc si vous utilisez une ancienne version de PostgreSQL, la meilleure méthode consiste à utiliser pg_dump/restore (et mieux vaut le faire maintenant!). Si votre version de PostgreSQL est 8.4 ou ultérieure vous pouvez utiliser pg_upgrade . Si vous utilisez PostgreSQL 9.4 et versions ultérieures cela signifie que vous disposez d'un "décodage logique" intégré et vous pouvez utiliser le pglogical extension comme moyen de mise à niveau. Enfin, si vous utilisez PostgreSQL 10 , vous aurez la possibilité de mettre à niveau votre base de données vers PostgreSQL 11 et versions ultérieures (une fois qu'ils sont disponibles) en utilisant la « réplication logique » intégrée (youpi !).
Réplication logique pour les mises à niveau
Où est l'idée de mettre à niveau PostgreSQL en utilisant la réplication logique ? venant ?Clairement, pglogical ne revendique pas ouvertement le but de la mise à niveau comme pg_upgrade fait (c'était un argument contre pglogical lors de la conférence ), mais cela ne signifie pas que nous ne pouvons pas utiliser l'outil pour les mises à niveau. En fait, lors de la conception de pglogical, les mises à niveau avec des temps d'arrêt quasi nuls étaient considérées comme l'un des cas d'utilisation attendus par les développeurs de l'extension.
Contrairement à la réplication physique, qui capture les modifications apportées aux données brutes sur le disque, la réplication logique capture les modifications logiques apportées aux enregistrements individuels de la base de données et les réplique. Les enregistrements logiques fonctionnent dans toutes les versions majeures , donc la réplication logique peut être utilisée pour mettre à niveau d'une version à l'autre. L'idée d'utiliser la réplication logique comme moyen de mise à niveau de version est loin d'être nouvelle, les outils de réplication basés sur des déclencheurs ont effectué des mises à niveau de manière logique en capturant et en envoyant les modifications via des déclencheurs (car les déclencheurs peuvent également fonctionner indépendamment des versions de la base de données ! ).
Si vous pouvez utiliser des solutions de réplication basées sur des déclencheurs pour des mises à niveau avec un minimum de temps d'arrêt, pourquoi préférer la réplication logique à la place ? Dans un mécanisme basé sur des déclencheurs, toutes les modifications sont capturées à l'aide de déclencheurs et écrites dans des tables de file d'attente. Cette procédure double les opérations d'écriture, double les fichiers journaux et ralentit le système puisque toutes les modifications doivent être écrites deux fois; résultant en plus d'E/S de disque et de charge sur le serveur source. En revanche, la réplication logique interne (il en va de même pour l'extension pglogical) est construite au-dessus du décodage logique. Le décodage logique est un mécanisme qui extrait les informations des fichiers WAL en changements logiques (INSERT/UPDATE/DELETE). Étant donné que les données du mécanisme WAL sont utilisées en décodant les journaux de transactions, il n'y a aucune amplification d'écriture comme dans le cas des solutions de réplication basées sur des déclencheurs, cette méthode fonctionne mieux . Par conséquent, les solutions basées sur le décodage logique ont tout simplement un impact moindre sur le système que les solutions basées sur les déclencheurs.
Conclusion
Dans cet article d'introduction, je voulais donner une idée de la raison pour laquelle nous devrions envisager d'utiliser la réplication logique pour réduire au minimum les temps d'arrêt lors des mises à niveau de versions majeures. Nous continuerons avec les détails de l'architecture et de la mise en œuvre de l'outil dans le prochain article.
