Postgresql : compte-rendu du PGDay Paris 2017

de | 2017-03-24

Un post interminable mais hier, à Paris, se tenait le PG Day 2017. C’est une série de conférences en anglais, souvent assez pointues, avec des invités intéressants. Les présentations projetées lors des séances seront disponibles sur le site de l’évènement. Cet article sera complété dès que le lien sera connu.

Un mot rapide avant de vous laisser à votre lecture : ce qui suit est la transcription de mes notes, prises soigneusement sur du papier, avec un stylo, en tirant légèrement la langue pour bien tracer les lettres. Elles ont été ensuite saisies et relues, complétées par les liens quand c’était possible.

Il y a probablement des coquilles , des erreurs et des manques car le contenu était très riche. Pour rester dans l’actualité, je publie tout de suite : cela devrait vous permettre de vous faire une idée. Les conférences n’étaient pas filmées et je ne crois pas qu’elles aient été enregistrées, donc c’est un verbatim pour la postérité.

EDIT : les documents complémentaires commencent à arriver sur le wiki de l’événement.

C’était en tout cas une bonne et belle journée.  Merci de votre attention.

 

Introduction

« DBA Toolbelt » (Kaarel Moppel, Cybertec)

« Corruption Wars » (Christopher Pettus, PostgreSQL Experts, Inc.)

« Ce qu’un débutant peut faire en un mois avec PostgreSQL » (Sylvie Aune, SA Infoconsulting).

« Mesurer et réduire les latences » (Fabien Coelho, ParisTech)

« PostgreSQL 10 : regardez moi ça ! » (Magnus Hagander, Redpill Linpro et membre de la Core Team)

« Infrastructure Monitoring » (Steven Simpson, StackHPC)
« Row Level Security » (Joe Conway, Crunchy Data)
« Réplication et récupération » (Simon Riggs, 2nd Quadrant)


Introduction

Journée européenne de conférences en anglais.
Le lieu :  Institut Relations Internationales et Stratégiques (http://www.iris-france.org/), dans le XIeme. Murs en briques et poutrelles métalliques apparentes. Un peu trop petit compte tenu du nombres de participants. Mais ça rentre. Sauf pour le déjeuner où c’était vraiment juste.L’amphithéâtre était neuf, fonctionnel. Un bon point pour la sonorisation, ce n’est pas toujours le cas.Mais qu’importe tout cela puisque nous sommes venus pour les conférences et, chers amis, conférences il y eu.
Je vous fais un résumé des éléments à retenir.

 « DBA Toolbelt » (Kaarel Moppel, Cybertec)

Note : il faisait aussi une démonstration de haute dispo dans le hall, avec des Raspberry Pi. Faut que j’essaie ça.)

Premier conseil : connaissez les concepts derrière les outils. Utilisez le wiki officiel (http://wiki.postgresql.org) comme première source de code et d’information.

1) Configuration :
– pgtune (http://pgtune.leopard.in.ua/): prendre les conseils avec précaution mais donne une idée, évite les erreurs grossières.
– pgbench (https://www.postgresql.org/docs/devel/static/pgbench.html) : inclus dans les contributions. Régulièrement amélioré, par exemple le support des charges définies par l’utilisateur. pg_bench tools (https://github.com/gregs1104/pgbench-tools) : complémentaire, avec génération de graphiques.

2) Sauvegarde :
– Wal-e (https://github.com/wal-e/wal-e) : archivage continu. Orienté Cloud.
– pgbarman (http://www.pgbarman.org/) : populaire et toujours amélioré. De nombreuses personnes dans la salle s’en servent.
– pgbackrest (https://github.com/pgbackrest/pgbackrest) : sauvegardes incrémentales, parallélisables.

3) Surveillance sur le moment (ad-hoc) :
Les habituels « top », « atop », « iotop », « dstat ».
– pg_activity (https://github.com/julmon/pg_activity) : suivi des sessions, interruption, charge, le tout en mode console.
– pg_view (https://github.com/zalando/pg_view) : regroupe indicateurs PostgreSQL et système.
– pgcenter (https://github.com/lesovsky/pgcenter) : suivi d’activité. Particularité : affiche des deltas / secondes là où les autres affichent des cumuls.
– pg_stat_statements (https://www.postgresql.org/docs/9.4/static/pgstatstatements.html) : shared librairy à activer et configurer.

4) Surveillance avec historique :
– Nagios (supervision, https://www.nagios.org/),  Munin (analyse et graphes, http://munin-monitoring.org/)...
– Check_postgres pour Nagios : ensemble de scripts pour sonde. Le conférencier dit les lancer parfois à la main, quand il en a besoin. Pourquoi pas.
– Check_pg_activity pour Nagios : moins de fonctionnalités mais mieux maintenu.
– pg_observer (http://zalando.github.io/PGObserver/) : focus sur les procédures stockées mais inclu le reste. Pas d’extension : un démon de collecte et une WebApp.
– pg_watch2 (http://www.cybertec.at/en/products/pgwatch2-next-generation-postgresql-monitoring-tool/, développé par le conférencier). Version 2 toute nouvelle. Repose sur Graphana et influxDb.
– pg_hero (https://github.com/ankane/pghero) : tableau de performances, suggestion d’index. Complet et populaire. Existe en image Docker.
– Snipets (https://wiki.postgresql.org/wiki/Category:Snippets) : des morceaux de code venant de la communauté. Certains peuvent vous éviter de coder vous-même.
– Autres scripts : pgx_scripts (https://github.com/pgexperts/pgx_scripts), pg_utils (http://pg-utils.readthedocs.io/en/latest/)...

5) Analyse de log :
Awk, grep…
– pgbadger (https://github.com/dalibo/pgbadger) : développement actif, très connu.
– redislog (https://github.com/2ndquadrant-it/redislog) :  transfert vers Reddis avant insertion dans Elasticsearch.
– PostgreSQL peut lire ses propres logs avec le Foreign Data Wrapper « file_fdw ».

6) Maintenance des données :
– Les conseils du wiki.
– index : hypopg (https://github.com/dalibo/hypopg) : index hypothétique.
– Bloat : pgstattuple (https://www.postgresql.org/docs/9.5/static/pgstattuple.html). Extensions : pg_sqeeze, pg_repack, pgcompacttable… Je ne détaille pas mais chacune ont leurs points forts et leurs conditions d’utilisation.

7) Navigation :
Autre conseil : prenez le temps de connaître et comprendre l’outil psql et la libpg. Il y a de nombreuses fonctions qui peuvent vous simplifier la vie si vous gérez de nombreuses instances.
– pgcli (http://pgcli.com/) : client amélioré. C’est du Python alors attention à la quantité de données retournées : ça peut bloquer.
– niceupdate (https://github.com/zalando/acid-tools/wiki/Niceupdate) : permet de donner des limites de consommation disque et CPU pour vos updates.
– pgAdmin 3 ou 4 (https://www.pgadmin.org/), bien sûr.
– Jetbrain Datagrip (https://www.jetbrains.com/datagrip/) : interface graphique multiSGBD. Pas open, pas gratuit, mais concilliant. Populaire chez les développeurs allemands, à ce que je comprends.
– SQLPad (https://github.com/rickbergfalk/sqlpad) : partage de codes entre équipier, à travers le nuage.

8) Intégration des données :
– PostgreSQL Foreign Data Wrapper (https://wiki.postgresql.org/wiki/Foreign_data_wrappers) : supporte un nombre considérable de moteurs. Probablement le votre.
– cstore_fdw : foreign data wrapper pour les tables en colonne.
– pgloader (http://pgloader.io/): migration en une commande depuis MySQL.
– postgrest/ngx_postgres (https://github.com/FRiCKLE/ngx_postgres) : extraction depuis JSON ou depuis NGinx directement.

– 9) Aide pour les développeurs :
– Présentation des plans d’exécution : https://explain.depesz.com/ , une référence.
– SQL Parse (https://pypi.python.org/pypi/sqlparse) : module Python.
– PL Profiler (https://www.bigsql.org/docs/plprofiler/profiler.jsp) et PL Debugger (https://git.postgresql.org/gitweb/?p=pldebugger.git;a=summary) : analyse des blocs pl/pgsql.
– pg_top (http://ptop.projects.pgfoundry.org/) : Aurait pu trouver sa place dès le début mais inclu les statistiques des tables et des indexes donc peut aider au développement.

Conclusion : un catalogue impressionnant d’outils. Pour la plupart, ils sont activement développés et partagés par les sociétés qui les utilisent.
A vous d’essayer et de choisir ceux qui vous conviennent.

 Corruption Wars (Christopher Pettus, PostgreSQL Experts, Inc.)

Pas le temps de souffler : on accélère le rythme.

Entrée en matière : les corruptions de pages existent et elles se produiront. Même avec PostgreSQL. La bonne nouvelle est que c’est assez facile à réparer tant que vous avez un dernier backup fiable (« known-good backup », c’est à dire un backup validé par restauration). Car vous avez un dernier backup fiable, n’est-ce pas ?

Ceci dit, commençons :

– Prévention :
PostgreSQL part du principe – naïf – que le système d’exploitation est parfait. Or, beaucoup de fabriquants prennent des libertés avec les standards (souvent pour obtenir de beaux benchmarks). Exemple typique : le traitement de la fonction « fsync », qui doit garantir l’écriture finale de la page sur disque et qui est souvent plus laxiste qu’attendue.
(il insiste lourdement) « Faites des backups, des backups, des backups… Demandez-vous : qu’est-ce qui est stocké sur un disque qui ne vous appartient pas ? ».
Evitez les montages réseaux pour le $PGDATA et les sauvegardes.

– Définissez un protocole de sauvegarde.
Utilisez des produits dédiés comme pgbarman ou pitrery (il ne connait pas dbSQWare mais on lui pardonne car il est américain).
Et testez les ! « Sans test vous n’avez pas de stratégie, juste beaucoup d’espoir ».
Détection des corruptions silencieuses en faisant un pgdump > /dev/null, forçant la lecture de toutes les lignes. Attention à la charge disque, quand même.

– Attention au matériel :
chaque disque à ses secteurs défectueux, chaque contrôleur ses bugs. La RAM devrait être ECC (avec checksum pour correction d’erreur). Les NAS ne savent souvent pas se rattacher proprement après coupure (une cause fréquente de problèmes chez Amazon. « AWS network is terrible »). Il y a fréquemment des problèmes avec les RAID logiciels (« mais de quel disque me parlez-vous ? Vous demandra-t-il après un reboot »).

– PostgreSQL a des bugs :
Regrettable mais vrai. Avez-vous entendu parler des corruptions d’index en 9.6.1 ? Non ? Tenez vous informés. Mettez à jour. Signalez vos problèmes aux développeurs.

– Erreur humaine :
Cf l’incident chez GitLab (qui, au final, en est sorti avec une bonne image grâce à sa transparence. Voir ici : https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/). Une erreur humaine sur des procédures mal maîtrisées = exemple de manipulation qui aggrave le problème.
Note : postgreSQL 10 renomme les répertoires « pg_clog » et « pg_xlogs » en « pg_cwal » et « pg_xwals » car trop de gens supprimaient leur contenu (« mais c’est que des logs !.. »).

– Réflexes élémentaires :
Sauvegardez les morceaux, autant que possible. Faites, si possible (et ça devrait l’être : le disque est le composant le moins cher), des sauvegardes complètes du FS. Ne faites pas le malin : dans la panique, vous ne devriez pas avoir à saisir des commandes plus complexes que « cp -r * /save_all/ ». Soyez méthodiques. Documentez chaque action.
Le problème vient peut être d’ailleurs : est-il possible de faire un simple « cp -r $PGDATA > /dev/null » ?

– Corruption d’index :
C’est le cas le plus courant. Drop / create doit suffire. Passez un pgdump pour détecter d’autres erreurs.
Erreur « bad datapage » : problème de checksum. On peut quand même relancer le serveur en jouant sur le nombre d’erreurs tolérées.
Corruption profonde : on peut tenter des selects autours du CTID, la colonne cachée servant à la gestion des versions du modèle MVCC.
On peut tenter de rétablir le service en modifiant le code et en capturant l’erreur de lecture car, à part celles qui sont fatales au postmaster, toutes les erreurs de backend sont correctement gérées.

– Périmètre :
Déterminer précisément le périmètre du problème. C’est souvent une occurrence unique (« one-off situation »). Ne cassez pas tout à chaque fois. regardez « dmesg », s’il y a des erreurs de disques ou des messages de OOM killer.

Conclusion :
Un exposé vif et instructif, basé sur une vaste expérience. Une assurance mêlée d’une distance ironique, fruit de longues nuits à réparer des catastrophes que l’on avait pourtant vu venir. Ça devrait être nous.
Une phrase à retenir : « le matériel est bon marché, les données sont inestimables ».


« Ce qu’un débutant peut faire en un mois avec PostgreSQL » (Sylvie Aune, SA Infoconsulting).

Je passerais plus rapidement car c’est un cas assez simple de développement d’application en interne, un outil d’inventaire.
Par contre, c’était une initiative intéressante que de faire venir une personne extérieure au cercle habituel. Et ça nous a permis de souffler un peu avant la dernière conférence de la matinée…
Et une remarque : malgré la nervosité de la conférencière qui rendait parfois la compréhension difficile et le thème inhabituel, l’assemblée a été respectueuse et amicale. Pas de bavardages périphériques, des applaudissements polis. Nous pouvons être fiers de nous.

 « Mesurer et réduire les latences » (Fabien Coelho, ParisTech)

Changement de registre et de rythme. L’orateur est très à l’aise, précis et énergique. Malgré le thème, tout à été très clairement exposé.

La présentation tourne autours de test pgbench avec différentes charges et deux versions de PostgreSQL : 9.5 et 9.6.
Entre ces deux versions, il y a eu un gros travail d’optimisation sur les checkpoints, dont les effets sont plus lissés en 9.6+.
Je ne vais pas décrire chacun des graphiques car ils seront disponibles sur le site des PGDay.

Pour l’essentiel :
Débit (« throughput »), exprimé en transactions par seconde. Latence exprimée en millisecondes par transaction. Les deux critères sont corrélés mais contradictoires : augmenter le débit peut augmenter les latences (ex: attente réseau/disque) mais diminuer les latences augmente le débit. Eh oui.
Les latences sont additives : une latence de 1 ms peut être négligeable si l’évènement dure plusieurs secondes mais être capitale s’il dure 5ms.

Il montre une série de test avec pgbench; Ceux-ci doivent être assez longs et joués plusieurs fois. Attention : l’outil se comporte comme un fou du volant : il fonce le plus vite possible, bloque, reprend à fond, etc. Attention à la déviation standard : elle permet d’interpréter correctement les mesures.

– test 1 : coût d’une connexion.
Pas de surprise, sur une transaction client/serveur, l’ouverture de la session coûte cher donc il faut éviter au maximum de le faire.
postgreSQL à une politique de « Buy now, pay later » : les écritures sont absorbées dans les caches et les WAL puis, lors du checkpoint, descendues par « fsync » vers le disque.
9.5 : « Tempête d’IO » (« IO storm ») lors du checkpoint avec un pic d’écritures aléatoires (mortelles sur HDD, moins sur SSD) et saturation.
9.6 : tri des écritures par ordre de fichiers plus flush régulier donc fsync a moins de travail lors du checkpoint.

– test 2 : limitation de la latence.
pgbench, suite à l’insistance du conférencier, supporte des options de limitation sur le débit et les latences. Le test montre l’effet perturbateur du checkpoint en 9.5, atténué en 9.6.

– test avec différentes options de stockage :
« fillfactor » pour les pages : pas de grosses différences.
« unlogged table » : un énorme gain de performance… et la perte possible (probable ?) de vos données. Peut être utile pour des tables temporaires.
« SSL » : un coût modeste mais indéniables sur les connexions. Si vous n’avez pas de vrai certificat (c’est à dire pas signé par vous même) et pas besoin de chiffrement, autant le désactiver.
Au passage, il parle de « Confidentiality, Integrity, Authentication », donc l’acronyme – souligne-t-il ironiquement – fait « C.I.A ».

– test avec différents types de requêtes :
Combinées, préparées… Ces dernières bien plus rapides. il y a une astuce niveau client avec le « \; » qui permet d’envoyer plusieurs instructions en un seul paquet. Le serveur se débrouille pour s’y retrouver. Les blocs PL/pgsql sont très performants car PostgreSQL cache les plans (et que construire des plans coûte du temps).

– test de l’effet distance client / serveur :
Sans surprise, vaut mieux être en local. Se remarque surtout avec les SSD puisque les temps de lecture sont plus courts, donc les temps réseaux paraissent plus longs.

– test avec type de FS :
Éviter BTRFS ou ZFS car ils ajoutent une couche de transactionnel à un logiciel qui l’est déjà.
Sous Linux, testez les différents IO schedulers qui peuvent avoir un effet selon votre type d’activité.
Et attention aux options de montage qui peuvent jouer (les timestamps par fichiers, par exemple : noatime, etc.).

Conclusion :
le débit du traitement n’est pas la seule mesure à prendre en compte. Les latences comptent et il est important de bien les mesurer afin de garantir un niveau de service. Sauf pour des benchmarks, il vaut mieux viser le « c’est assez bien » que le « maximum de performances ». Ce n’est qu’une fois toutes les bonnes questions posées et répondues que vous pouvez acheter du matériel plus puissant.
Ne présumez pas : mesurez ! Utilisez la 9.6 !

Une excellente conférence !

« PostgreSQL 10 : regardez moi ça ! » (Magnus Hagander, Redpill Linpro et membre de la Core Team)

Un homme souriant et détendu, manifestement très à l’aise et fier du travail accompli.

– Numéro de version : Plus de X.Y.z mais seulement X.y. Il y aura une 10.1 mais pas de 10.1.1. C’est, en partie, pour clarifier le support des produits. Certains demandaient « PostgreSQL 9 » et la question était « laquelle ? ». Donc à partir de maintenant : une version majeure et des bugs fixes (car il y en aura).

– Partout où s’était possible, le nom « log » à été supprimé : plus de « pg_resetxlog » mais du « pg_resetwal »; plus de dossiers « pg_xlogs » mais « pg_wal ». Plus de « pg_switch_xlogs » mais « pg_switch_wal »… Pareil pour les tables et les fonctions.

– Quelques améliorations sur les messages et l’outil psql.

– Nouvelle méthode d’authentification : SRAM (http://paquier.xyz/postgresql-2/postgres-10-scram-authentication/), plus sûre et mieux implémentée que les autres. Dépend du support des clients. C’est un standard, plus facile à maintenir, donc pas de raison de ne pas l’utiliser.

– libpq : support de plusieurs hosts dans la chaîne de connexion. facilite la gestion des clusters.

– Monitoring : amélioration de pg_stat_activity qui montre maintenant plus de détails sur les attentes; affiche aussi l’activité de la replication (sender / receiver). Plus de 100 nouveaux compteurs ont été ajoutés.

– Pour les développeurs : beaucoup de choses mais je n’ai pas tout compris. Ils ont l’air contents.

– backup et réplication : De nouveaux défaut pour éviter des reboots : « replica » pour wal_level, plus de slots et de senders pour la réplication. Important : apparition de slots de réplication temporaire pour éviter que des copies en cours (avec pg_basebackup, par exemple) ayant plantées ne laissent des slots ouvert derrière elles. « Quorum based sync replication » : nombre de réponses attendues dans un pool de machines pour qu’une écriture soit validée.
« Logical replication » : un modèle de publication / souscription façon Sybase, compatible avec la réplication physique, permettant plusieurs copies et un filtrage des DML. La matérialisation des données vient tout juste d’être implémentée.

– Performances :
Les hash indexes sont maintenant loggés (c’était un pré-requis pour la réplication logique). « Un code vieux de 20 ans dans lequel personne ne voulait mettre le nez », dixit Magnus). Gros gains de performance.
Partitionning : même chose qu’avant mais mieux présenté, « donc peut-être qu’il sera utilisé » (sic). « Ce sera pas pire que ce qu’il y avait avant » (re-sic). Encore de nombreuses limitations. Travail en cours.
Amélioration du parallélisme : utilisation de différents indexes.

… et bien d’autres choses mais il arrive au bout de son temps de parole.

Conclusion :
Le changement de numéro de version n’est pas un simple effet de manche. il y a eu une quantité impressionnante de commit et de nouvelles fonctionnalités. Magnus, que je n’avais jamais rencontré, malgré son statut dans le projet, est un type sympa, souriant, marrant… Difficile de deviner la quantité de code qu’il a pu écrire.
il termine sur cet appel : « aidez-nous ! Installez la 10 (peut-être pas tout de suite en production) ! Testez vos applications et remontez les bugs : ce sera déjà beaucoup ».

« Infrastructure Monitoring » (Steven Simpson, StackHPC)

Je vais faire court car cette conférence repose surtout sur une évolution de slides : au départ, une architecture top-design avec du kafka, de l’ElasticSearch, du MySQL… une dizaine de composants chargés chacun de stocker un type de données (log, timeseries, gros volume, message queue…).

Il remplace progressivement la majorité des composants par PostgreSQL pour montrer que, bien que n’étant pas à la mode en ce moment, SQL est un outil formidable qui n’est pas près d’être remplacé.

Il note aussi une tendance – louable au départ – de faire un outil pour un usage mais avec le risque d’augmenter inutiliement la complexité de l’exploitation.

Si le sujet vous intéresse, allez voir sa présentation.

Conclusion :
Si on prend la peine de réfléchir au possiblilité de ce que l’on utilise déjà (ici PostgreSQL, mais c’est valable un peu partout), on peut souvent faire ce que l’on souhaite sans chercher un autre outil.

 

« Row Level Security » (Joe Conway, Crunchy Data)

Comment résumer cette conférence ? Prenez d’un coté SELinux et son système très perfectionné d’étiquettes pour les niveaux de sécurité. Prenez de l’autre PostgreSQL et ses fonctions de contrôle d’accès au niveau ligne. Prenez enfin un conférencier – ressemblant à un ancien instructeur américain, comme dans les films – maîtrisant son sujet sur le bout des doigts.

Vous obtenez 45 minutes de conférence très dense mais compréhensible.

Par contre, je relis mes notes et je ne me sens pas le courage de vous résumer tout ça.

En bref :
– pour la sécurité, il y a des niveaux (ex: public, employés, managers) et des cloisonnements (ex: un manager coté marketing ne peut pas accéder aux données RH). Cela donne une matrice d’accès.

– SELinux implémente complètement ces contraintes. Cela fait de Linux un système utilisable dans les environnements classé secret défense, par exemple.

– Il est possible de mapper des utilisateurs Linux et des utilisateurs PostgreSQL afin de gérer les accès à tous les niveaux, avec une politique homogène. Ainsi, même l’administrateur du SGBD ne peut pas tout voir.

– Il l’admet : c’est un sujet passionnant mais pas facile d’accès.

Je retiens surtout que cela se sent un peu au niveau des performances mais pas trop.

« Réplication et récupération » (Simon Riggs, 2nd Quadrant)

Dernière conférence de la journée. Après la précédente, tout parait simple…

Pour commencer, il insiste sur la très bonne réputation de PostgreSQL en tant que moteur et rappelle que la préoccupation du projet est d’être un moyen de stockage solide et digne de confiance.

Il revient sur les nouveautés de la réplication logique et sur les moyens qui ont été choisi pour assurer la consistance des données qui transitent. Le code a été soigneusement pensé pour être le plus simple possible et donc, normalement, le plus robuste.

La vue « pg_stat_replication » : contient plus d’information mais il y a eu de longues discussions imprévues. En effet, la mesure de la latence est un sujet plus complexe qu’il n’y parait. Au final, ce n’est pas un décalage en seconde entre master/slave qui est mesuré mais le temps d’aller/retour. De plus, le chiffre a été pensé pour les outils de monitoring afin d’être exploitable.

Il y a eu un gros effort sur la syntaxe pour qu’elle soit consistante entre la réplication physique et la logique.

Outils « pg_logical 2.0 » : qui devrait permettre des migrations en live à partir de la 9.4 vers la 10. Avancé mais pas terminé.

Il mentionne également leur solution de réplication multi-master : PostgreSQL-BDR.

 

Il y avait une certaine redite sur quelques points mais il a beaucoup insisté sur la qualité du travail fait sur le code, dans un soucis de « less is more ».
Fin de la conférence, fin de la journée. Applaudissements.

Merci à toute l’équipe des PGDay.A vous les studios !