J'ai passé une semaine dans la magnifique ville de Lisbonne pour assister à la conférence annuelle européenne PostgeSQL. Cela marquait le 10e anniversaire depuis la première conférence européenne PostgreSQL et ma sixième participation.
Premières impressions
La ville était géniale, l'ambiance était géniale et il semblait que ce serait une semaine très productive et informative pleine de conversations intéressantes avec des gens intelligents et amicaux. Donc, fondamentalement, la toute première chose cool que j'ai apprise à Lisbonne, c'est à quel point Lisbonne et le Portugal sont formidables, mais je suppose que vous êtes venu ici pour le reste de l'histoire !
Tampons partagés
Nous avons assisté à la session de formation "PostgreSQL DBA toolbelt for day-to-day ops"
par Kaarel Moppel (Cybertec) . Une chose que j'ai notée était le paramètre de shared_buffers. Étant donné que shared_buffers concurrence ou complète le cache du système, il ne doit pas être défini sur une valeur comprise entre 25% et 75% de la RAM totale disponible. Ainsi, alors qu'en général, le paramètre recommandé pour les charges de travail typiques est de 25 % de RAM, il peut être défini sur>=75 % pour des cas particuliers, mais pas entre les deux.
Autres choses que nous avons apprises au cours de cette session :
- malheureusement, l'activation/l'activation en ligne (ou hors ligne) facile des sommes de contrôle de données n'est pas encore dans 11 (initdb/réplication logique reste la seule option)
- attention à vm.overcommit_memory, vous feriez mieux de le désactiver en le réglant sur 2. Réglez vm.overcommit_ratio sur environ 80.
Réplication logique avancée
Dans le discours de Petr Jelinek (2e quadrant) , les auteurs originaux de la réplication logique, nous avons découvert des utilisations plus avancées de cette nouvelle technologie passionnante :
- Collecte de données centralisée :nous pouvons avoir plusieurs éditeurs, puis un système central avec un abonné à chacun de ces éditeurs, rendant les données provenant de diverses sources disponibles dans un système central. (utilisation typique :OLAP)
- Des données mondiales partagées ou, en d'autres termes, un système central de gestion des données et des paramètres mondiaux (tels que les devises, les actions, les valeurs du marché/des matières premières, la météo, etc.) qui publient pour un ou plusieurs abonnés. Ensuite, ces données sont conservées dans un seul système mais disponibles dans tous les abonnés.
- La réplication logique peut être asynchrone mais aussi synchrone (garantie à la validation)
- Nouvelles possibilités avec le décodage logique :
- intégration avec Debezium/Kafka via des plugins de décodage logique
- Plug-in wal2json
- Réplication bidirectionnelle
- Mises à niveau avec des temps d'arrêt proches de zéro :
- configurer la réplication logique sur le nouveau serveur (éventuellement initdb avec l'activation des sommes de contrôle des données)
- attendre que le décalage soit relativement faible
- depuis pgbouncer mettre en pause la ou les bases de données
- attendre que le décalage soit nul
- changer la configuration de pgbouncer pour pointer vers le nouveau serveur, recharger la conf de pgbouncer
- depuis pgbouncer reprendre la ou les bases de données
Nouveautés de PostgreSQL 11
Dans cette présentation passionnante, Magnus Hagander (Redpill Linpro AB) nous a présenté les merveilles de PostgreSQL 11 :
- pg_stat_statements prend en charge l'ID de requête 64 bits.
- pg_prewarm (une méthode pour réchauffer le cache du système ou les tampons partagés) :ajout de nouveaux paramètres de configuration
- Nouveaux rôles par défaut facilitant l'abandon de postgres (l'utilisateur que je veux dire :))
- Procédures stockées avec contrôle xactionnel
- Recherche plein texte améliorée
- La réplication logique prend en charge TRUNCATE
- Les sauvegardes de base (pg_basebackup) valident les sommes de contrôle
- Plusieurs améliorations dans la parallélisation des requêtes
- Partitionnement encore plus raffiné qu'en 10
- partition par défaut
- mises à jour sur les partitions (déplace la ligne d'une partition à une autre)
- index de partition locale
- clé unique sur toutes les partitions (toujours pas encore référençable)
- partitionnement par hachage
- jointures par partition
- Agrégats par partition
- les partitions peuvent être des tables étrangères dans différents serveurs étrangers. Cela ouvre de grandes possibilités pour un sharding plus fin.
- Compilation juste à temps
zheap :une réponse aux problèmes de gonflement de PostgreSQL
Ce n'est toujours pas dans 11, mais cela semble si prometteur que j'ai dû l'inclure dans la liste des choses sympas. La présentation a été donnée par Amit Kapila (EnterpriseDB) l'un des principaux auteurs de cette nouvelle technologie qui vise à être intégrée à terme dans le noyau PostgreSQL en tant que type de tas alternatif. Cela sera intégré à la nouvelle API Pluggable Storage dans PostgreSQL, qui prendra en charge plusieurs méthodes d'accès aux tables (de la même manière que les différentes méthodes d'accès [Index] abordées dans mon premier blog).
Cela tentera de résoudre les lacunes chroniques de PostgreSQL avec :
- gonflement de la table
- besoin de (auto)vider
- potentiellement un bouclage d'identifiant de transaction
Tous ces éléments ne sont pas un problème pour la moyenne à grande entreprise (bien que cela soit très relatif), nous connaissons des banques et d'autres institutions financières qui exécutent PostgreSQL des dizaines de To de données et plusieurs milliers de transactions/sec sans problème. Le gonflement de la table est géré par autovacuum et le gel des lignes résout le problème du bouclage de l'ID de transaction, mais cela n'est toujours pas sans maintenance. La communauté PostgreSQL travaille vers une base de données vraiment sans maintenance, c'est pourquoi l'architecture zheap est proposée. Cela apportera :
- un nouveau journal UNDO
- Le journal UNDO rendra les données visibles pour les anciennes transactions voyant les anciennes versions
- UNDO sera utilisé pour annuler les effets des transactions abandonnées
- les changements se produisent sur place. Les anciennes versions ne sont plus conservées dans les fichiers de données.
Objectifs de haut niveau :
- meilleur contrôle des ballonnements
- moins d'écritures
- en-têtes de tuple plus petits
Cela mettra PostgreSQL sur un pied d'égalité avec MySql et Oracle à cet égard.
Requête parallèle dans PostgreSQL :comment ne pas (mal)l'utiliser ?
Dans cette présentation par Amit Kapila et Rafia Sabih (EnterpriseDB), nous avons appris les éléments internes de la parallélisation et également des conseils pour éviter les erreurs courantes ainsi que certains paramètres GUC recommandés :
- le parallélisme ne prend en charge que les index B-tree
- max_parallel_workers_per_gather défini sur 1→ 4 (selon les cœurs disponibles)
- faites attention aux paramètres suivants :
- parallel_tuple_cost :coût de transfert d'un tuple d'un processus de travail parallèle vers un autre processus
- parallel_setup_cost :coût de lancement des nœuds de calcul parallèles et d'initialisation de la mémoire partagée dynamique
- min_parallel_table_scan_size :la taille minimale des relations à prendre en compte pour le balayage de séquence parallèle
- min_parallel_index_scan_size :la taille minimale d'index à prendre en compte pour un scan parallèle
- random_page_cost :coût estimé de l'accès à une page aléatoire sur le disque
