Une synthèse, et en route vers le futur

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
44
Mois de parution
octobre 2009
Domaines


Résumé

Ce hors-série nous a permis de présenter un certain nombre de solutions de pooling de connexions, de réplication... bref, de la haute disponibilité sur PostgreSQL. Cet article va faire le tour de tous les systèmes de pooling et de réplication que nous connaissons.


Body

1. Synthèse des solutions actuelles de pooling

Voici un tableau faisant la synthèse des solutions de pooling de connexions :

 

Outil

Licence

Mode de pooling

Type

pgPool-II

BSD

session

multiprocessus

pgBouncer

BSD

session, transaction, instruction

multithread

Le choix ici est simple. Si vous avez simplement besoin de pooling, pgBouncer a de fortes chances d'être le bon choix. Si vous avez besoin aussi de répartition de charge, commencez par jeter un œil à pgPool-II.

Bien sûr, il existe d'autres systèmes de pooling qui ne sont pas spécifiques à PostgreSQL. Java/Hibernate en propose un, mais tous les échos que nous en avons eus sont peu flatteurs.

2. Synthèse des solutions actuelles de réplication

Et maintenant, un tableau faisant la synthèse des solutions de réplication.

 

Outil

Licence

Réplication

Synchrone

Répartition de charge

Esclave accessible

Log Shipping/Warm Standby

BSD

Maître/esclave

Non

Non

Non

pgPool

BSD

Maître/esclave, par réplication des instructions

 

 

 

deux serveurs uniquement

Oui

Oui

Oui

 

 

pgPool-II

BSD

Maître/esclave, par réplication des instructions

Oui

Oui

Oui

slony-I

BSD

Maître/esclave, par triggers

Non

Non

Oui

Londiste

BSD

Maître/esclave, par triggers

Non

Non

Oui

Mammoth

BSD

Maître/esclave

Non

Non

Oui

rubyrep

MIT

Maître/maître ou maître/esclave

Non

Non

Oui

Bucardo

BSD

Maître/maître ou maître/esclave, par triggers

Non

Non

Oui

DRBD

GPL

Maître/esclave

Oui

Non

Non

Cybercluster

BSD

Maître/maître

Oui

Oui

Oui

PGCluster

BSD

Maître/maître

Oui

Oui

Oui

Postgres-R

BSD

Maître/maître

Oui

Oui

Oui

Attention, pgPool est un projet abandonné qui a laissé la place à pgPool-II. Tous les projets présentés dans ce tableau sont spécifiques à PostgreSQL, à l'exception de rubyrep et de DRBD.

Les projets les plus intéressants actuellement (car les plus actifs) sont Log Shipping/Warm Standby, pgPool-II, Londiste et Bucardo.

3. Le futur

Maintenant que nous avons revu les différentes solutions actuelles, regardons ce qui devrait arriver sous peu.

3.1 Au niveau de PostgreSQL

Tout le monde attend avec une grande impatience la possibilité d'avoir accès en lecture seule aux serveurs Warm Standby. En fait, la dénomination officielle est Hot Standby, d’où le nom du patch de Simon Riggs. Initialement prévue par son auteur pour la 8.4, elle a dû être repoussée. Nous espérons voir cela pour la 8.5, même si Simon semble rencontrer des soucis quant à son implémentation dans PostgreSQL.

Autre patch très attendu, SyncRep. Le but est de fournir une synchronisation à la transaction près, dans le moteur de PostgreSQL. Une sorte de Log Shipping qui n'envoie pas de journaux de transactions complets, mais plutôt des bouts de journaux correspondant à des transactions unitaires. Là aussi, son auteur travaille dessus.

Il faut bien dire qu'avec ces deux patchs, la vie des autres systèmes de réplication risque de se compliquer. Certains systèmes pourraient tirer leur épingle du jeu en appuyant sur le fait qu'ils ont une granularité beaucoup plus fine quant aux choix des objets à répliquer. Slony, Londiste, Bucardo et rubyrep en font partie.

3.2 Le futur de Slony

Cela ne sera pas Slony-II qui est laissé en friche depuis bien trop longtemps. Aucun développeur ne travaille dessus.

L'article sur Slony utilisait PostgreSQL 8.3, ce qui n'est pas un hasard, la version 8.4 n'étant pas encore supportée. Très rapidement, les versions 1.2.17 et 2.0.3 devraient sortir pour supporter cette version. Il devrait même y avoir un support des triggers TRUNCATE. Si vous utilisez Slony, testez ces versions, elles sont prometteuses.

Mais, à notre connaissance, il n'y a pas de plan pour une évolution plus importante.

3.3 Londiste 3

Les développeurs de Skype vont frapper un grand coup avec cette nouvelle version majeure des Skytools. Tout en conservant les meilleures fonctionnalités de la version 2, ils vont ajouter :

- un support des serveurs en cascade par le système de gestion de queues, PGQ ;

- un support des COPY parallélisées par Londiste, accélérant ainsi la mise en place d'une réplication ;

- une commande EXECUTE qui sera de la partie pour exécuter des scripts SQL sur les différents nœuds en même temps (pensez à l'envoi d'une modification de schéma sur tous les nœuds, ce que Slony est capable de faire avec slonik_execute_script.pl) ;

- une création automatique des tables et séquences par import de la structure du nœud maître (cela supprime une étape dans la mise en place de la réplication) ;

- une nouvelle console interactive d'administration ;

- et plein d'autres choses.

Clairement, les développeurs de Londiste proposent une nouvelle version très attrayante. Néanmoins, ils n'ont pas l'air très pressés de sortir cette version. Ils ont certainement besoin d'aide pour des tests. Avis aux amateurs !

3.4 Bucardo

Cet outil semble être bien parti pour progresser rapidement. Bien qu'il ne soit pas à la portée du premier venu pour l'instant, sa prochaine version, la 4.0, devrait être bien plus simple d'installation, tout en gardant cette fonctionnalité unique de réplication maître/maître.

 



Articles qui pourraient vous intéresser...

Tirez parti de votre environnement de travail en ligne de commandes

Magazine
Marque
Linux Pratique
Numéro
125
Mois de parution
mai 2021
Domaines
Résumé

Je vous propose de découvrir le monde merveilleux de la ligne de commandes. Pas un tutoriel pour l’utiliser, mais un ensemble d’outils pour tirer profit au maximum de cet environnement. Que vous soyez débutant ou utilisateur expérimenté, je souhaite dans cet article vous montrer comment personnaliser son apparence, vous passer de certains outils graphiques, vous faire découvrir de nouveaux utilitaires, de nouveaux usages et des alternatives à des commandes historiques connues.

À la découverte du gestionnaire de système et de services System Daemon

Magazine
Marque
Linux Pratique
Numéro
125
Mois de parution
mai 2021
Domaines
Résumé

Historiquement, les services du système GNU/Linux étaient pris en charge par ce qu’on appelait System V. Cela permettait de lancer des programmes au démarrage de l’ordinateur, mais également de gérer les niveaux d’exécution de différentes parties du système, grâce à des scripts shell placés dans le répertoire /etc/init.d. Après une courte transition par le projet upstart, une grande majorité des systèmes GNU/Linux a basculé sous Systemd (pour System Daemon), plus souple et efficace pour gérer les différents services, mais pas seulement.

Gérez vos gros volumes de données avec Elasticsearch

Magazine
Marque
Linux Pratique
Numéro
125
Mois de parution
mai 2021
Domaines
Résumé

Elasticsearch est un SGBD NoSQL qui gagne en popularité ces dernières années de par sa flexibilité et sa gestion facile. Il intègre la notion de cluster qui permet de décentraliser une base de données afin de rendre les requêtes à celle-ci plus rapides, tout en assurant une sécurité plus qu’acceptable. Dans cet article, nous allons gérer une base de données Elasticsearch en nous focalisant principalement sur la manipulation des données. Nous supposerons que vous disposez déjà d’un cluster installé disposant bien évidemment d’un nœud master, comme vu précédemment [1].

Les barrages se tordent (de rire) : comparaison d'images (mal) géoréférencées avec l'interférométrie par RADAR spatioporté

Magazine
Marque
GNU/Linux Magazine
Numéro
247
Mois de parution
avril 2021
Domaines
Résumé

Nombre d’images diffusées sur le Web sont manipulées, en particulier pour être projetées dans un référentiel géographique. Des projections automatiques mal contrôlées peuvent aboutir à un résultat aberrant... repris dans un documentaire diffusé par France 24 et donnant lieu à polémique sur les risques de rupture du plus gros barrage hydroélectrique du monde. Un peu de bon sens et de contrôle de l’information auraient pu éviter la bévue.