Au cours des deux derniers mois, j'ai travaillé sur la mise à niveau en ligne de très grandes bases de données dans le cadre du projet AXLE et j'aimerais partager mes réflexions sur le sujet et les progrès que nous avons réalisés récemment.
Avant de rejoindre 2ndQuadrant, je travaillais sur Skype où l'entreprise n'autorisait pas de fenêtre de maintenance pour nos bases de données. Cela signifiait qu'aucun temps d'arrêt n'était autorisé pour les déploiements, les mises à niveau, etc. Ce type de règle vous oblige à changer votre façon de faire les choses. La plupart des changements sont petits, vous ne faites pas de gros verrous, vous avez des répliques pour permettre un basculement rapide. Mais alors que vous pouvez rendre vos versions petites et non bloquantes, que se passe-t-il lorsque vous devez effectuer une mise à niveau majeure de la version de la base de données PostgreSQL ?
Vous pourriez être dans une situation différente, car la plupart des entreprises ont une fenêtre de mise à niveau, et vous pourriez donc vous permettre un certain temps d'arrêt pendant la mise à niveau. Cela pose cependant deux problèmes. D'une part, aucune entreprise n'aime réellement les temps d'arrêt, même s'ils sont autorisés. Et plus important encore, une fois que la taille de votre base de données dépasse les gigaoctets pour atteindre des téraoctets ou des centaines de téraoctets, le temps d'arrêt peut prendre des jours, voire des semaines, et personne ne peut se permettre d'arrêter ses opérations aussi longtemps. Le résultat est que de nombreuses entreprises sautent souvent des mises à niveau importantes, ce qui rend la suivante encore plus pénible. Et les développeurs manquent de nouvelles fonctionnalités, d'améliorations des performances. Elles (les entreprises) risquent même parfois d'exécuter une version de PostgreSQL qui n'est plus prise en charge et qui présente des problèmes connus de corruption de données ou de sécurité. Dans les paragraphes suivants, je parlerai un peu de mon travail pour rendre les mises à niveau moins longues et, par conséquent, moins douloureuses et, espérons-le, plus fréquentes.
Permettez-moi de commencer par un peu d'histoire d'abord. Avant PostgreSQL 9.0, la seule façon d'effectuer une mise à niveau majeure de version était d'exécuter pg_dump et de restaurer le vidage dans une instance exécutant une version plus récente de PostgreSQL. Cette méthode nécessitait que la structure et toutes les données soient lues à partir de la base de données et écrites dans un fichier. Ensuite, lisez le fichier et insérez-le dans une nouvelle base de données, les index doivent être reconstruits, etc.
Comme vous pouvez l'imaginer, ce processus peut prendre un certain temps. Des améliorations des performances ont été apportées dans la version 8.4 pour pg_restore avec l'option -j ajoutée où vous pouvez spécifier le nombre de tâches parallèles à exécuter. Cela permet de restaurer plusieurs tables (index, etc.) en parallèle, ce qui accélère le processus de restauration pour les vidages au format personnalisé. La version 9.3 a ajouté une option similaire à pg_dump, améliorant encore les performances. Mais étant donné la vitesse à laquelle les volumes de données augmentent, la parallélisation elle-même n'est pas suffisante pour faire un gain sérieux dans le temps nécessaire à la mise à niveau.
Ensuite, dans PostgreSQL 9.0, un utilitaire appelé pg_upgrade est arrivé. Pg_upgrade vide uniquement les structures et les restaure dans le nouveau cluster. Mais il copie les fichiers de données tels qu'ils sont sur le disque, ce qui est beaucoup plus rapide que de les vider au format logique puis de les réinsérer. C'est assez bon pour les petites bases de données car cela signifie un temps d'arrêt en quelques minutes ou heures, un temps acceptable pour de nombreux scénarios. Il existe également le mode lien qui crée simplement des liens physiques (points de jonction sous Windows) ce qui rend ce processus encore plus rapide. Mais de mon point de vue personnel, il est trop dangereux d'exécuter une telle configuration sur un serveur maître de production. Je vais expliquer brièvement pourquoi. Si quelque chose ne va pas, une fois que vous démarrez votre nouveau serveur qui a été mis à niveau en utilisant le mode lien, vous êtes soudainement sans base de données de production et devez basculer, ou pire, vous devez restaurer à partir d'une sauvegarde. Cela signifie non seulement que vous n'avez pas réussi à mettre à niveau, mais que vous avez causé des temps d'arrêt supplémentaires ! Bonne chance pour obtenir l'approbation la prochaine fois.
Aujourd'hui, de nombreuses personnes qui ne peuvent pas se permettre de longs temps d'arrêt pour les mises à niveau utilisent les solutions de réplication basées sur des déclencheurs comme Slony ou Londiste pour effectuer la mise à niveau. C'est une bonne solution car vous pouvez répliquer vos données pendant que le serveur d'origine est en cours d'exécution, puis basculer avec un temps d'arrêt minimal. En pratique, plusieurs problèmes se posent cependant. L'un d'eux est que les solutions basées sur les déclencheurs sont souvent difficiles à configurer, surtout si vous ne le faites qu'une fois tous les deux ans et uniquement pour effectuer la mise à niveau. Il est également facile de manquer une table ou d'ajouter des tables dans le mauvais ordre et donc de ne pas obtenir la copie complète. J'ai été témoin de cela dans la pratique et les personnes effectuant la mise à niveau travaillaient quotidiennement avec la réplication basée sur les déclencheurs . Un autre problème est que les solutions basées sur des déclencheurs ajoutent une charge considérable sur la base de données source, rendant parfois la mise à niveau impossible en raison de la surcharge du serveur de base de données une fois la réplication activée. Enfin et surtout, la réplication basée sur les déclencheurs peut prendre très longtemps pour déplacer les données vers le nouveau serveur. La dernière fois que j'ai été impliqué dans un projet de mise à niveau, la solution basée sur des déclencheurs a pris environ un mois pour copier la base de données et rattraper les changements. Oui, un mois.
Avec PostgreSQL 9.4 arrive la fonctionnalité de décodage logique qui offre un nouveau départ pour concevoir une nouvelle et meilleure solution de problème de mise à niveau en ligne. Ce que nous avons fait, dans le cadre du projet AXLE, est de créer un outil qui combine le décodage logique avec les techniques décrites ci-dessus. La solution résout la plupart des problèmes des approches précédentes. L'extension PostgreSQL de réplication unidirectionnelle (UDR en abrégé) effectue une réplication logique en utilisant le décodage logique du journal d'écriture anticipée (WAL). Grâce à cela, l'impact sur le serveur maître est presque équivalent à la réplication physique en continu, de sorte que la charge supplémentaire causée par la mise à niveau en cours est minime sur le système en cours d'exécution. Il fournit également des outils pour initialiser de nouveaux nœuds, à la fois en utilisant une sauvegarde physique et logique. Vous pouvez même transformer la veille physique existante en veille UDR. Et comme il s'agit d'un système de réplication logique, il est possible de le concevoir de manière à prendre en charge la réplication entre versions.
Tout cela signifie que nous pouvons désormais utiliser UDR en combinaison avec pg_upgrade pour effectuer une mise à niveau en ligne de la version majeure de PostgreSQL avec un temps d'arrêt minimal, en peu de temps absolu et avec un impact minimal sur le système en cours d'exécution.
Un exemple de ce à quoi cela peut ressembler dans la pratique :
- Effectuez pg_basebackup de l'instance existante.
- Configurez la réplication UDR entre l'instance d'origine et celle créée par basebackup.
- Pg_upgrade la nouvelle instance.
- Laissez UDR relire les modifications qui se sont produites entre-temps.
- Faites basculer le trafic vers la nouvelle instance.
Pour savoir comment faire avec des instructions plus détaillées, consultez le guide de mise à niveau en ligne UDR sur le wiki PostgreSQL. Les sources UDR sont disponibles dans le dépôt 2ndquadrant_bdr sur le serveur git PostgreSQL (bdr-plugin/next branch).
Enfin, comme UDR n'est pas seulement un outil de mise à niveau en ligne mais aussi une solution de réplication, il peut être utilisé pour vos besoins de réplication normaux, au lieu de la réplication physique en continu. En outre, il offre plusieurs avantages, tels que la possibilité de créer des tables temporaires, la réplication de plusieurs bases de données OLTP dans une seule base de données d'entrepôt de données volumineuses ou la réplication d'une partie seulement de la base de données.
J'espère que cet effort signifiera que les considérations de temps d'arrêt ne sont plus un problème lorsqu'il s'agit de mettre à niveau PostgreSQL 9.4 et supérieur vers une nouvelle version majeure.
La recherche menant à ces résultats a reçu un financement du septième programme-cadre de l'Union européenne (FP7/2007-2013) au titre de la convention de subvention n° 318633.
