Faciliter la gestion d'une base de données PostgreSQL de production

Ces dernières années ont vu l'adoption croissante de PostgreSQL. PostgreSQL est une base de données relationnelle étonnante. En termes de fonctionnalités, il est parmi les meilleurs, sinon le meilleur. Il y a beaucoup de choses que j'aime à ce sujet - PL / PG SQL, les valeurs par défaut intelligentes, la réplication (qui fonctionne réellement hors de la boîte) et une communauté open source active et dynamique. Cependant, au-delà des fonctionnalités, il existe d'autres aspects importants d'une base de données qui doivent être pris en compte. Si vous envisagez de créer une grande opération 24h/24 et 7j/7, la possibilité d'exploiter facilement la base de données une fois qu'elle est en production devient un facteur très important. Sous cet aspect, PostgreSQL ne tient pas très bien le coup. Dans cet article de blog, nous détaillerons certains de ces défis opérationnels avec PostgreSQL. Il n'y a rien de fondamentalement irréparable ici, juste une question de priorisation. Espérons que nous pourrons susciter suffisamment d'intérêt dans la communauté open source pour donner la priorité à ces fonctionnalités.

1. Aucune détection automatique du pilote client du basculement principal

Le pilote client PostgreSQL ne détecte pas automatiquement lorsqu'il y a eu un basculement de maître (et qu'un nouveau maître a été élu). Pour contourner ce problème, les administrateurs doivent déployer une couche proxy côté serveur. Les choix populaires sont le mappage DNS, le mappage IP virtuel, PgPool et HAProxy. Toutes ces options peuvent fonctionner correctement, mais un effort d'apprentissage et d'administration supplémentaire important est requis. Dans le cas où un proxy est introduit dans le chemin des données, l'impact sur les performances est également considérable. Il s'agit d'une fonctionnalité intégrée standard dans de nombreuses nouvelles bases de données NoSQL, et PostgreSQL ferait bien de s'inspirer de leurs livres en ce qui concerne les opérations.

2. Pas de basculement automatique intégré entre maître et veille

Lorsqu'un maître PostgreSQL tombe en panne, l'un des serveurs de secours doit être élu maître. Ce mécanisme n'est pas intégré à PostgreSQL. En règle générale, des outils logiciels tiers tels que Patroni, Pacemaker, etc. sont utilisés pour gérer ce scénario. Pourquoi ne pas l'avoir intégré au serveur ? Ces outils tiers semblent d'une simplicité trompeuse, mais cela nécessite des efforts, des connaissances et des tests considérables de la part de l'administrateur pour y parvenir. En intégrant cela dans la base de données, vous rendez un énorme service à votre administrateur de base de données.

3. Mise à niveau majeure sans temps d'arrêt

Il n'est pas possible de mettre à niveau votre base de données PostgreSQL d'une version majeure à une autre sans temps d'arrêt. Vous devez essentiellement arrêter tous vos serveurs et utiliser pg_upgrade pour mettre à niveau vos données vers la version la plus récente. Le temps d'arrêt n'est pas important puisqu'il n'y a pas de copie de données impliquée, cependant, il y a toujours un temps d'arrêt. Si vous exécutez une opération 24 heures sur 24, 7 jours sur 7, cela n'est peut-être pas une option pour vous.

Avec la sortie de la réplication logique, nous avons une option alternative pour la mise à niveau en ligne.

1. Créez une toute nouvelle configuration PostgreSQL Master-Standby avec la nouvelle version.
2. Configurer la réplication logique pour répliquer de l'ancienne version vers la nouvelle version.
3. Une fois que vous êtes prêt, modifiez votre chaîne de connexion pour qu'elle pointe de l'ancienne configuration vers la nouvelle configuration.

Encore une fois, cela peut fonctionner, mais les frais généraux sont énormes. Idéalement, ce qui est nécessaire ici est un moyen de mettre à niveau sur place de manière continue sur une configuration de secours principale. La mise à niveau de MySQL vous permet de mettre à niveau vos esclaves sur place vers la nouvelle version, puis de déclencher un basculement.

4. Pas de VIDE PLEIN sur place

Autovacuum/VACUUM est très utile et aide à résoudre ce problème dans une certaine mesure. Vous devez examiner régulièrement le ballonnement sur vos tables pour vous assurer que vos paramètres de vide automatique sont appropriés et fonctionnent bien pour votre table. Cependant, l'autovacuum ne va pas jusqu'au bout :il ne finit pas par fusionner et supprimer les pages. Si vous avez un grand nombre de mises à jour, d'insertions et de suppressions de charges de travail, vos pages finiront par être fragmentées, ce qui affectera vos performances. La seule façon de contourner cela est d'exécuter VACUUM FULL qui reconstruira essentiellement toutes les pages pour éliminer la fragmentation. Cependant, ce processus ne peut être effectué qu'avec un temps d'arrêt - votre table est en panne pendant la durée du VACUUM FULL. Pour les grands ensembles de données, cela peut prendre plusieurs heures et n'est pas une alternative pratique si vous souhaitez exécuter une opération 24h/24 et 7j/7.

Remarque :la communauté a déjà commencé à travailler sur le moteur de stockage zheap qui surmonte cette limitation.

S'il y a d'autres améliorations qui, selon vous, seraient utiles, n'hésitez pas à laisser un commentaire.