"Il est paradoxal, mais vrai, de dire que plus nous en savons, plus nous devenons ignorants au sens absolu, car ce n'est que par l'illumination que nous devenons conscients de nos limites. L'un des résultats les plus gratifiants de l'évolution intellectuelle est précisément l'ouverture continue de perspectives nouvelles et plus vastes. Nikola Tesla
PostgreSQL est un projet génial et il évolue à une vitesse incroyable. Nous nous concentrerons sur l'évolution des capacités de tolérance aux pannes dans PostgreSQL à travers ses versions avec une série d'articles de blog.
PostgreSQL en bref
PostgreSQL est tolérant aux pannes par nature. Tout d'abord, il s'agit d'un système de gestion de base de données open source avancé et fêtera son 20e anniversaire cette année. Il s'agit donc d'une technologie éprouvée et d'une communauté active, grâce à laquelle elle progresse rapidement.
PostgreSQL est conforme à SQL (SQL : 2011) et entièrement conforme à ACID (atomicité, consistance, isolation, durabilité).
PostgreSQL permet la réplication physique et logique et dispose de solutions de réplication physique et logique intégrées. Nous parlerons des méthodes de réplication (dans les prochains articles de blog) dans PostgreSQL concernant la tolérance aux pannes.
PostgreSQL autorise les transactions synchrones et asynchrones, PITR (Point-in-time Recovery) et MVCC (Multiversion Concurrency Control). Tous ces concepts sont liés à la tolérance aux pannes à un certain niveau et je vais essayer d'expliquer leurs effets tout en expliquant les termes nécessaires et leurs applications dans PostgreSQL.
PostgreSQL est robuste !
Toutes les actions sur la base de données sont effectuées dans le cadre de transactions , protégé par un journal des transactions qui effectuera une récupération automatique sur incident en cas de défaillance du logiciel.
Les bases de données peuvent éventuellement être créées avec des sommes de contrôle de bloc de données pour aider à diagnostiquer les pannes matérielles. Plusieurs mécanismes de sauvegarde existent, avec un PITR complet et détaillé, en cas de besoin de récupération détaillée. Une variété d'outils de diagnostic sont disponibles.
La réplication de base de données est prise en charge de manière native. Réplication synchrone peut fournir plus de "5 neuf" (99,999 %) disponibilité et protection des données, si elles sont correctement configurées et gérées.
Compte tenu des faits ci-dessus, nous pouvons facilement affirmer que PostgreSQL est robuste !
Tolérance aux pannes PostgreSQL :WAL
La journalisation en écriture anticipée est le principal système de tolérance aux pannes pour PostgreSQL.
Le WAL consiste en une série de fichiers binaires écrits dans le sous-répertoire pg_xlog du répertoire de données PostgreSQL. Chaque modification apportée à la base de données est d'abord enregistrée dans WAL, d'où le nom de log « write-ahead », synonyme de « journal des transactions ». Lorsqu'une transaction est validée, le comportement par défaut (et sûr) consiste à forcer les enregistrements WAL sur le disque.
En cas de plantage de PostgreSQL, le WAL sera rejoué, ce qui ramène la base de données au point de la dernière transaction validée, et assure ainsi la durabilité de toute modification de la base de données.
Transaction ? S'engager ?
Les modifications de la base de données elles-mêmes ne sont pas écrites sur le disque lors de la validation de la transaction. Ces modifications sont écrites sur le disque un peu plus tard par le rédacteur en arrière-plan ou le pointeur de contrôle sur un serveur bien réglé. (Vérifiez la description WAL ci-dessus. )
Les transactions sont un concept fondamental de tous les systèmes de bases de données. Le point essentiel d'une transaction est qu'elle regroupe plusieurs étapes en une seule opération tout ou rien.
Les états intermédiaires entre les étapes ne sont pas visibles pour les autres transactions simultanées, et si un échec se produit qui empêche la transaction de se terminer, aucune des étapes n'affecte la base de données. PostgreSQL ne prend pas en charge les lectures modifiées (la transaction lit les données écrites par une transaction simultanée non validée ).
Point de contrôle
La récupération après crash rejoue le WAL, mais à partir de quel moment commence-t-il à récupérer ?
La récupération commence à partir de points dans le WAL appelés points de contrôle . La durée de la reprise sur incident dépend du nombre de modifications apportées au journal des transactions depuis le dernier point de contrôle. Un point de contrôle est un point de départ sûr et connu pour la récupération, car il garantit que toutes les modifications précédentes apportées à la base de données ont déjà été écrites sur le disque.
Un point de contrôle peut être soit immédiat ou programmé . Les points de contrôle immédiats sont déclenchés par une action d'un superutilisateur, comme le CHECKPOINT commande ou autre; les points de contrôle planifiés sont décidés automatiquement par PostgreSQL.
Conclusion
Dans cet article de blog, nous avons répertorié les fonctionnalités importantes de PostgreSQL liées à la tolérance aux pannes dans PostgreSQL. Nous avons mentionné la journalisation en écriture anticipée, la transaction, la validation, les niveaux d'isolement, les points de contrôle et la récupération après incident. Nous continuerons avec la réplication PostgreSQL dans le prochain article de blog.
Références :
Documentation PostgreSQL
Livre de recettes d'administration PostgreSQL 9 – Deuxième édition
