DBA découvre un nouveau problème avec PostgreSQL

Comme toujours, les utilisateurs qui mettent à niveau ou initialisent un nouveau cluster bénéficieront de meilleures performances (par exemple, de meilleures analyses d'index parallèles, des jointures de fusion et des sous-requêtes non liées, des agrégations plus rapides, des jointures plus intelligentes sur les serveurs distants) et de l'agrégation), tout cela fonctionne immédiatement. , mais dans cet article, je veux parler de quelque chose qui ne fonctionne pas immédiatement et qui nécessite en fait que vous preniez certaines mesures pour en bénéficier. Les fonctionnalités mises en évidence ci-dessous sont compilées du point de vue d'un administrateur de base de données, et il y aura bientôt un article couvrant les changements du point de vue d'un développeur.

Notes de mise à niveau

Tout d'abord quelques conseils pour la mise à niveau à partir d'une configuration existante : certaines petites choses peuvent causer des problèmes lors de la migration à partir de la version 9.6 ou antérieure, alors assurez-vous de tester la mise à niveau sur une copie séparée et de parcourir la version avant de procéder à la mise à niveau proprement dite. Tout est possible questions dans la description. Les défauts les plus notables sont :

Toutes les fonctions contenant "xlog" ont été renommées pour utiliser "wal" au lieu de "xlog".

Cette dernière dénomination peut être confondue avec les journaux de serveur normaux, il s'agit donc d'un changement "juste au cas où". Si vous utilisez des outils tiers de sauvegarde/réplication/HA, vérifiez qu’ils sont à jour.

Le dossier pg_log qui contient les journaux du serveur (messages d'erreur/avertissements, etc.) a été renommé « log ».

Assurez-vous de vérifier que votre analyse de journal ou votre script grep (si vous en avez un) fonctionne.

Par défaut, les requêtes utiliseront jusqu'à 2 processus en arrière-plan.

Si vous utilisez la valeur par défaut de 10 dans le paramètre postgresql.conf sur une machine avec un faible nombre de processeurs, vous pouvez constater des pics d'utilisation des ressources puisque le traitement parallèle est activé par défaut - c'est une bonne chose car cela devrait signifier pour requêtes plus rapides. Si vous souhaitez l'ancien comportement, définissez max_parallel_workers_per_gather sur 0.

Par défaut, les connexions de réplication pour localhost sont activées.

Pour simplifier les choses comme les tests, les connexions de réplication localhost et de socket Unix local sont désormais activées en mode "trust" (pas de mot de passe) dans pg_hba.conf ! Par conséquent, veillez à modifier la configuration si d'autres utilisateurs non-DBA ont accès à la véritable machine de production.

Mes favoris du point de vue DBA

Copie logique

Cette fonctionnalité tant attendue nécessite une configuration simple avec une perte de performances minimale lorsque vous souhaitez uniquement copier une seule table, une partie d'une table ou toutes les tables, ce qui signifie également que les versions majeures ultérieures peuvent être mises à niveau sans aucun temps d'arrêt ! Historiquement (nécessite Postgres 9.4+), cela a été possible en utilisant des extensions tierces ou des solutions basées sur des déclencheurs lents. Pour moi, ce sont les 10 meilleures fonctionnalités.

Déclarer les partitions

La méthode précédente de gestion des partitions impliquait l'héritage et la création de déclencheurs pour rediriger les insertions vers la bonne table, ce qui était ennuyeux, sans parler de l'impact sur les performances. Les schémas de partitionnement « plage » et « liste » sont actuellement pris en charge. Si quelqu'un manque de partitionnement « par hachage » dans certains moteurs de base de données, vous pouvez utiliser le partitionnement « par liste » avec des expressions pour obtenir la même fonctionnalité.

Index de hachage disponibles

Les index de hachage sont désormais enregistrés dans WAL et donc protégés contre les crashs, et ont bénéficié de certaines améliorations de performances, ce qui les rend plus rapides que les index B-tree standard sur des données plus volumineuses pour des recherches simples. Des tailles d'index plus grandes sont également prises en charge.

Statistiques de l'optimiseur multi-colonnes

Ces statistiques doivent être créées manuellement sur un ensemble de colonnes de tableau pour indiquer que les valeurs dépendent réellement les unes des autres d'une manière ou d'une autre. Cela traitera des requêtes lentes pour lesquelles le planificateur pense que très peu de données sont renvoyées (le produit des probabilités donne souvent de très petits nombres) et entraîne donc de mauvaises performances avec de grandes quantités de données (par exemple, choisir une jointure "en boucle imbriquée").

Instantanés parallèles sur les répliques

Il est désormais possible d'utiliser plusieurs processus (indicateur -jobs) dans pg_dump pour accélérer considérablement les sauvegardes sur les serveurs de secours.

Mieux ajuster le comportement des travailleurs du traitement parallèle

Référez-vous aux paramètres max_parallel_workers et min_parallel_table_scan_size/min_parallel_index_scan_size. Je recommande d'augmenter un peu les valeurs par défaut pour ces deux derniers (8 Mo, 512 Ko).

Nouveaux rôles de surveillance intégrés pour une utilisation plus facile des outils

Les nouveaux rôles pg_monitor, pg_read_all_settings, pg_read_all_stats et pg_stat_scan_tables facilitent l'exécution de diverses tâches de surveillance - qui devaient auparavant être effectuées à l'aide d'un compte superutilisateur ou d'une fonction wrapper SECURITY DEFINER.

Emplacement de réplication temporaire (par session) pour une génération de répliques plus sûre

Une nouvelle extension Contrib pour vérifier la validité des index B-tree

Ces deux contrôles intelligents révèlent des incohérences structurelles et du contenu non couverts par la validation au niveau de la page. Espérons que ce soit plus approfondi dans un avenir proche.

L'outil de requête Psql prend désormais en charge les branches de base (if/elif/else)

Par exemple, ce qui suit permettra d'activer un seul script de maintenance/surveillance avec une branche de version spécifique (avec différents noms de colonnes pour les vues pg_stat*, etc.) au lieu de nombreux scripts spécifiques à une version.

SELECT :VERSION_NAME = '10.0' AS is_v10 \gset
\if :is_v10
SELECT 'yippee' AS msg;
\else
SELECT 'time to upgrade!' AS msg;
\endif

C'est tout cette fois ! Il y a bien sûr beaucoup d'autres choses qui ne sont pas répertoriées, donc pour un administrateur de base de données dédié, je recommanderais certainement de jeter un regard plus complet sur les enregistrements de versions. Un grand merci aux plus de 300 personnes qui ont contribué à cette version !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!