Présentation des fonctionnalités de PostgreSQL 10 avec 2 conférences qui lui sont consacrées sur les 8 présentées au PGDAY. Support d’origine ici

Conférences du PGDAY du 23 Mars 2017 à Paris (et compléments par la suite)

Deux conférences évoquaient les nouveautés de la version 10 de PostgreSQL.

• A look a the Elephants trunk - PostgreSQL 10 par Magnus Hagander;
• Replication & Recovery in PostgreSQL 10.0 par Simon Riggs.

Magnus est un très bon orateur. Sa mise en scène avec sa présentation projetée transforme le moment passé avec lui de simple présentation technique en épisode de TBBT (The Big Bang Theory). C’est accessible et le public est diverti en même temps.

Une révolution

La première chose abordée dans cette présentation est la petite révolution apportée dans la gestion des numéros de version : on passe de 9.X … 9.Y pour les versions majeures à 10, 11, 12… jusqu'à 94 car le retour du 95 serait trop déroutant.

Mais à raison d’une release majeure par an, en 2102 un tel versionnement sera-t-il seulement encore d’actualité ?

Cette version de PostgreSQL est celle qui comporte le plus de modifications de code par rapport à toutes les versions précédentes. Les avancées sont massives. C’est une des raisons qui expliquent le changement de numérotation des versions (avec aussi l’avancée technique principale mais nous allons revenir sur cette partie).

Alors, qu’est-ce qui change exactement ?

Tout d’abord, nous sommes prévenus, certaines choses disparaissent :

• fin du support du protocole client/serveur 1.0 (clients datant d’avant la version 6.3);
• fin du support des TIMESTAMP avec floating point.

D’autres changent :

• nomenclatures dans les vues, paramètres, options des outils et toute autre mention de “xlog” et “clog” qui deviennent respectivement “wal” et “xact”.

Cela inclut également les répertoires de données pg_xlog et pg_clog. C’est d’ailleurs la principale raison de ces modifications.

La raison derrière ce changement ?

Cette histoire commence toujours de la même façon : “Nous n’avions plus de place car le sytème de fichiers était plein. Tout ce ce que nous avons fait c’est de supprimer des vieux logs”.

Je parle bien évidemment des logs de transaction (wal) et informations de validation (clog) dont le nom pouvait être source de confusion pour les non-initiés.

Ce qui aura valu de si nombreux “Facepalm” à tous les DBA PostgreSQL depuis que ces répertoires existent.

C’est donc de l’histoire ancienne. Sur la prochaine version plus de confusion possible. A moins que…

Un petit ajout cosmétique dans psql :

“\gx” pour formater la sortie de commande de façon unitaire sans modifier l’environnement d’exécution.

Grâce à cela, plus besoin de penser à effectuer un \x avant d'écrire la requête.

Au menu

• DBA et administration

  • Authentification SCRAM plus sécurisée que md5, standardisée et permettant de passer à l’authentification quand tous les clients le supportent et ont été mis à niveau;
  • Amélioration de libpq (options psql) : connexions à de multiples systèmes, demande à accéder à une instance ouverte aux écritures, chemin d’accès au .pgpass qui peut etre forcé.

• Monitoring (pg_stat_activity)

  • processus walsender visible;
  • nouveaux évènements pour le statut “wait”, plus de détails (extensions, client/socket/timeout, reads, writes, identification individuelle…).

• Fonctionnalités SQL et développeurs

  • fonction regexp_match() ne retournant pas d’ensemble et pouvant être incluse dans une sous-requête;
  • Pl/python supporte les arrays;
  • file_fdw peut maintenant utiliser les programmes (gunzip ou autre utilitaire);
  • COPY VIEW FROM;
  • XMLTABLE pour transformer un document XML en ensemble de résultat le tout plus rapidement qu’avec une requête individuelle.

• Sauvegarde et réplication

  • les fichiers postgresql.conf et pg_hba.conf configurés par défaut pour autoriser la réplication, sans nécessiter le redémarrage du serveur;
  • slots de réplication temporaires supprimés automatiquement à la fin de la session pour des questions de sécurité et et d’intégrité;
  • pg_base_backup supporte le mode streaming en tar (option -Ft), -X stream est maintenant une valeur par défaut, et utilise un slot de réplication temporaire par défaut;
  • pg_receivewal (ancien pg_receivexlog) supporte la compression;
  • QUORUM replication : avec ANY et FIRST pour synchronous_standby_names;
  • réplication logique : légère et basée sur les WAL, répliquant les objets individuellement, nouvelles commandes PUBLICATION (primaire) et SUBSCRIPTION (secondaire). Cependant, cette fonctionnalité nécessite encore du travail car les objets déclarés sur le primaire ne sont pas automatiquement créés sur le secondaire (la COPY initiale ayant été commitée le jour même de la conférence). Les séquences ne sont pas supportées et il est préférable de rappeler que ce n’est pas une solution de Fail-over (une réplication physique est bien mieux adaptée à cet usage).

• Performance

  • postgres_fdw : aggrégats, et FULL JOIN
  • le grand retour des index de type HASH qui avaient été laissés de coté d’un point de vue développement depuis plusieurs versions : seront loggés dans les WAL, auront un meilleur support de la mise en cache, et seront dotés d’un vacuum “page-level". Leurs performances dépassent celles des index btree dans certains cas;
  • partitionnement : l’usage sera simplifié avec une surcouche permettant moins de commandes et une retro compatibilité avec les précédentes versions. Le partitionnement est donc toujours basé sur l’héritage de table;
    • Le routage des tuples est automatique jusqu'à la bonne partition.
    • On peut partitionner par RANGE ou par LIST;
    • Les limitations sont néanmoins nombreuses : pas de mouvement de tuple, pas d’index interpartition, pas de clé interpartition, pas de calcul partitionné intelligent ou sur partitions multiples, et pas de routage de tuple sur les partitions externes;
  • parallélisme : le parallélisme introduit dans la dernière version majeure en date permettait déjà de couvrir les seqscans, aggrégats, jointures HASH et LOOP.
    • Cette fois-ci, PostgreSQL 10 ira plus loin, beaucoup plus loin : max_parallel_workers, un paramètre global de parallélisation.
    • Les sous-requêtes issues d’une parallélisation ayant des workers associés apparaitront dans pg_stat_activity en tant que requête non-correlée;
    • Autres types de parallélismes : bitmap heap scan, index scan, index-only scan, gather merge, merge join;
    • Il reste à paralléliser : CREATE INDEX, un meilleur hash join sur les grandes tables, parallel append, la généralisation à l’accès au parallélisme à tout le language PL/pgSQL, requête SERIALIZABLE et j’en oublie;
  • Patch WARM (Write Amplification Reduction) réalisé partiellement suite au départ de UBER de PostgreSQL pour MySQL, mais le problème d’amplification des écritures consécutivement au patch HOT était en soit une raison suffisante;

• Décodage logique sur standby;

• Sessions en arrière plan;

• pg_stat_walwrites;

• Barre de progression pour ANALYZE;

• Support ICU.

Mesure du retard de réplication

Simon Riggs de 2ndQuadrant nous parle ici de la réplication logique intégrée à PostgreSQL 10 ainsi que des outils de monitoring associés.

J’ai été tout particulièrement marqué par l’approche utilisée pour quantifier le retard de réplication (pg_stat_replication). Un nouveau module a d’ailleurs été créé pour l’occasion.

Il s’agit d’un module qui se base sur les mesures du temps mis par les fichiers WAL récents pour être écrits, flushés et rejoués.

Ces temps représentent le décalage de commit qui a eu lieu (ou aurait eut lieu) par un niveau de commit synchrone (synchronous commit level), si le serveur distant était configuré en réplication synchrone (synchronous standby).

Pour un replica asynchrone, la colonne “replay_lag_column” donne une approximation du delai avant que les transactions récentes ne soit visibles par les requêtes.

Si le replica a entièrement rattrapé son retard avec son primaire et qu’il n’y a pas d’activité dans le WAL, la mesure de lag la plus récente reste affichée pendant un temps et passera ensuite à NULL.

Le traçage du retard est automatique en réplication physique.

Pour la réplication logique, le traçage est possible mais est de la responsabilité du plugin de décodage logique. Le traçage est effectué individuellement par un module privé à l’intérieur de chaque walsender, avec les valeurs rapportées à la mémoire partagée. Le module n’est pas utilisé en dehors des walsenders.

Pour résumer :

Les mesures sont basées sur les quantités de données à traiter et le temps mis dernièrement par les réplicas pour les absorber.

Il en résulte que le valeur de lag observée est plus précise que si elle était basée sur un horodatage ou un LSN (Logical Sequence Number) (contrairement à MySQL - voir ici) mais elle est toujours dans le passé : on observe donc la valeur à laquelle le lag était quelques instants auparavant.