PostgreSQL est peut-être le plus populaire base de données open source dans le monde, et son essor au cours de la dernière décennie a été tout simplement remarquable. Son exhaustivité et sa fiabilité attirent l'attention des grandes organisations établies. De plus, il s'agit d'un système de gestion de base de données gratuit et open source. Cela constitue son principal argument de vente auprès des petites entreprises opérant avec un budget limité.
Cela dit, tous ces avantages ne vont pas sans revers. PostgreSQL, comme tout autre courant dominant SGBD, a ses inconvénients que chaque développeur doit connaître à l'avance. Cet article discutera des problèmes les plus courants rencontrés par les développeurs PostgreSQL et des meilleurs moyens de les contourner.
Les problèmes de performance
Il n'existe pas un seul système de gestion de base de données qui ne rencontre des problèmes de performances occasionnels. PostgreSQL n'est pas sujet à ces problèmes, mais ils se produisent occasionnellement, et il est sage pour tout administrateur système de savoir comment les identifier et s'en débarrasser.
De nombreux développeurs et administrateurs système pensent que le réglage des paramètres dans postgresql.conf est le seul moyen d'éliminer les problèmes de performances. Bien que les paramètres de configuration puissent être bénéfiques, ils ne vous amèneront pas toujours à la racine du problème. Dans de nombreux cas, le problème sera finalement différent de ce sur quoi vous vous concentrez.
Certaines personnes utilisent la vue pg_stat_statements pour détecter les requêtes lentes en regardant leurs temps de chargement. D'autres préfèrent Expliquer PostgreSQL, qui est vénéré pour fournir une répartition des requêtes plus précise et plus inclusive. Associée à Analyser, la fonction permet de booster Client PostgreSQL performances en affichant le plan d'exécution généré par le planificateur de PostgreSQL et en affichant le temps d'exécution.
Problèmes de décalage de réplication
Les cas de problèmes de décalage de réplication sont rares, mais leur impact important sur les performances des applications les rend dignes d'être inclus dans cette liste. L'identification des retards de réplication PostgreSQL est une tâche relativement facile, mais il existe plusieurs façons d'aborder le problème, qui pourraient déterminer la manière la plus appropriée de le résoudre.
PostgreSQL utilise la réplication en continu - une fonctionnalité introduite dans la version 9.0 - qui devrait la rendre rapide puisque les modifications sont enregistrées sous la forme d'une série d'enregistrements de journal exactement au moment où le récepteur WAL les intercepte. Une fois que ces enregistrements de journal sont placés dans le fichier WAL, le processus de démarrage de PostgreSQL relit ces données et le processus de réplication en continu commence.
La plupart des décalages surviennent lorsque le Segment WAL introuvable ou il y a des problèmes de réseau, des problèmes de configuration, un mauvais matériel ou des hochements de tête occupés. Vous pouvez utiliser l'utilitaire pg_stat_replication pour obtenir une vue de l'état de la réplication en continu. Il a également été démontré que ClusterControl aide à la surveillance des nœuds de base de données.
Temps d'arrêt lors de la mise à jour du schéma
La mise à jour d'un schéma de base de données PostgreSQL est facile si vous pouvez vous déconnecter tout en le faisant. Il vous suffit de fermer l'application, de créer une sauvegarde de schéma, d'effectuer les opérations de mise à jour, d'examiner et de tester votre travail et de redémarrer votre application, en espérant que tout est correct.
Cependant, les choses ne seront pas si faciles si la nature de votre candidature nécessite zéro temps d'arrêt. Cela nécessite une procédure complexe en plusieurs phases qui peut impliquer l'utilisation d'une approche rétrocompatible pour modifier votre base de données. Le but de ceci est de rendre la base de données utilisable à la fois pour vos anciennes et nouvelles versions d'application.
Pour les opérations de migration qui ne sont pas rétrocompatibles, vous pouvez les décomposer en étapes plus petites pour créer une base de données que les deux versions de votre application peuvent utiliser. Souvent, cela nécessite que l'utilisateur crée une nouvelle table ou vue, ou colonne, que votre nouvelle version de l'application utilisera.
Renforcement de la sécurité
Tout d'abord, qu'il soit clair que la base de données PostgreSQL offre certains des meilleurs la sécurité des données fonctionnalités pour votre serveur et vos données. Le problème survient au moment de les identifier et de les déployer.
Le renforcement de la sécurité dans PostgreSQL peut être divisé en trois catégories : la configuration du serveur, le chiffrement des données et la configuration du réseau. Il est toujours conseillé d'effectuer le chiffrement des données en vol et au repos. Pour le chiffrement des données en cours de vol, l'accès à la base de données client doit être défini pour utiliser SSL. Le serveur doit également exiger ou accepter des connexions sécurisées.
Le chiffrement au repos peut être effectué à de nombreuses phases différentes de la pile ; où vous l'implémentez sera principalement déterminé par les exigences d'infrastructure et d'application. Le module pgcrypto est utilisé à des fins de chiffrement et de déchiffrement au niveau de la base de données. La technique est utile en dernier recours lorsqu'il n'y a pas d'autre méthode de chiffrement viable et que des ensembles de données spécifiques doivent être chiffrés.
Les administrateurs peuvent toujours crypter les données au niveau du cloud ou du système de fichiers – une approche plus transparente et moins impactante sur les performances.
Le risque de perte de données
Bien qu'il existe de nombreuses façons de réduire le risque de perte de données, vous ne pouvez jamais réduire cette possibilité à zéro. Ainsi, chaque administrateur de base de données doit disposer d'une stratégie de sauvegarde robuste pour s'assurer que les applications sont de nouveau opérationnelles dès que possible suite à une cyber-attaque, un événement catastrophique ou un problème d'intégrité des données.
Les sauvegardes de données doivent être au centre de toute stratégie de gestion de base de données. Pour les utilisateurs de PostgreSQL, il existe plusieurs façons de configurer une stratégie de sauvegarde, en fonction des préférences et d'autres facteurs fonctionnels. Par exemple, la fonction pg_dump intégrée peut être utilisée pour créer des sauvegardes périodiques avec installation de machine virtuelle ou bare metal en l'absence d'une couche de service gérée. La sortie pg_dump est constituée d'un fichier texte que vous pouvez stocker sur une plate-forme non attachée à la base de données et récupérer plus tard lorsque les puces sont en panne. L'opération de récupération de données consiste généralement simplement à rendre le fichier disponible pour le programme PostgreSQL en tant qu'entrée.
Bien que l'utilisation de pg_dump soit idéale pour les plans de sauvegarde formulés par l'utilisateur, services de cloud computing tels que Stratoscale SMD et AWS RDS fournissent la sauvegarde et la reprise après sinistre en tant que fonctionnalités intégrées, vous n'avez donc pas à vous soucier de créer une stratégie de sauvegarde à partir de zéro.
Endnote
La gestion de la base de données n'est simple que si vous maîtrisez la phase de planification et connaissez les défis quotidiens et les stratégies d'atténuation viables. Espérons que les conseils ci-dessus vous aideront à vous préparer aux accrocs et à vous relever rapidement et de manière transparente.
