Lettre d'information de Dalibo

L'actualité de PostgreSQL et de ses projets satellites. Juin 2008.

Événements PostgreSQL

La nouvelle a fait grand bruit sur la liste pgsql-hackers. Tom Lane a annoncé le 29 mai 2008 que la « core team » veut ajouter la réplication directement dans le moteur de PostgreSQL. Évidemment, cela change du discours habituel (« no “one size fits all” replication solution »). En fait, ce changement est survenu après la conférence d'Andrew lors de pgcon 2008. Les développeurs de PostgreSQL attendaient un retour des développeurs de modules de réplication. Ce retour ne venant pas, ils ont décidé d'intégrer une solution de réplication dans PostgreSQL. Le but n'est évidemment pas d'empêcher l'existence des autres solutions, mais d'en proposer une par défaut et facile à installer.

Il existe déjà un bout de réplication dans PostgreSQL. Il est possible de faire envoyer les journaux de transactions sur un deuxième serveur et de faire en sorte que ce serveur restaure en continue les données contenues dans les journaux de transactions. Donc, on se retrouve avec un deuxième serveur, en restauration continue, prêt à prendre la main en cas de problème sur le serveur principal. C'est ce qu'on appelle le « Warm Standby » ou encore « Log Shipping » (lire aussi sur ce point notre article, installation_du_logshipping. Néanmoins, la solution n'est pas parfaite :

  • vous devez répliquer l'instance complète (pas de choix des objets à répliquer comme avec Slony par exemple) ;
  • l'esclave n'est pas disponible (alors qu'il est en lecture seule sur la plupart des autres outils de réplication, Slony par exemple ;
  • vous pouvez perdre l'équivalent en données d'un journal de transaction (à modérer avec le paramètre archive_timeout qui permet justement d'avoir un délai maximum avant de forcer l'utilisation d'un nouveau journal de transaction… ce qui a un prix en terme de bande passante, surtout si votre esclave dépend d'une ligne peu rapide) ;
  • la réplication est asynchrone (ce qui peut-être parfaitement acceptable dans certains cas et intolérable dans d'autres).

Le but est de répondre aux deux derniers points pour offrir une réplication, asynchrone et/ou synchrone, sans délai. Pour cela, il faut bien comprendre ce qu'est un journal de transactions. Un journal est une aggrégation de pages disques qui ont été modifiées. Il contient aussi d'autres types d'enregistrement comme les CHECKPOINT, mais il est principalement composé de pages disques. Chacune de ces pages disques (de 8 Ko) représente une modification sur une partie d'un fichier représentant une table ou un index. Plutôt que d'envoyer ces pages disques regroupées en bloc de 16 Mo (donc au maximum 2048 pages disques stockées), les développeurs de PostgreSQL voudraient les envoyer grouper par transaction. En effet, suivant la transaction SQL exécutée, une ou plusieurs pages disques seront ajoutées au journal de transaction pour indiquer les modifications entreprises. Plutôt que d'envoyer un journal de transaction (qui peut contenir des transactions validées et/ou annulées, plusieurs transactions ou une partie d'une transaction), il est préférable de récupérer toutes celles qui correspondent à une transaction et à envoyer tout d'un coup après COMMIT et/ou ROLLBACK. De cette façon, la réplication est en temps réel.

La question du type de réplication s'est aussi posée : sera-t-elle asynchrone (comme le LogShipping ou comme Slony) ou synchrone ? et la réponse de Tom Lane n'a pas tardé : « les deux, suivant la configuration ». Là aussi, c'est très bien joué. Plutôt que d'imposer le type de réplication, on laisse le choix à l'administrateur. Avoir une réplication synchrone n'est pas que du bonheur, ça a un impact sur les performances. Tous les esclaves devront renvoyer un message pour indiquer qu'ils ont bien reçu (et enregistré sur disque) la transaction avant que le serveur maître puisse dire au client que les données sont enregistrées. Donc, pour les cas où une réplication synchrone est inutile, la désactiver permettra de gagner en performances.

Il est prévu malgré tout de travailler sur l'utilisation des esclaves en lecture seule. Le travail reste important. D'après Simon Riggs, il sera difficile d'intégrer ça dans la version 8.4. Il est plus probable que l'on verra ça seulement en 8.5. Tout dépend en fait de la façon dont NTT va communiquer sur ce sujet. NTT est une entreprise asiatique qui a déjà développé ce type de réplication (avec un composant de haute-disponibilité utilisant Heartbeat). Eux-aussi ont réalisé une présentation de ces travaux lors de pgcon2008. Les slides permettent de bien comprendre leur travaux, ne surtout pas hésiter à les lire.

Pour terminer, ce que cette réplication ne fera pas :

  • répliquer à un niveau plus fin que l'instance même.
  • pas de possibilité de mettre à jour vers une nouvelle version majeure de PostgreSQL (je dis bien majeure, car les mineures seraient possibles d'après Simon Riggs).
  • pas de failover automatique.

La version 8.4 semble décidément très alléchante.

Calendrier PostgreSQL

L'annonce faite le mois dernier était un peu rapide car il nous manquait la confirmation des organisateurs. Du coup, il ne reste plus qu'une conférence et six ateliers. Le stand sera bien là.

La seule conférence sera réalisée par Guillaume Lelarge qui fera un tour d'horizon de PostgreSQL. Quant aux ateliers, voici les sujets proposés et acceptés :

  • Installation de PostgreSQL ;
  • Utilisation de la recherche plein texte en 8.3 ;
  • PITR et LogShipping ;
  • Réplication avec Slony ;
  • Réplication avec bucardo ;
  • Procédures stockées en PL/pgsql.

Nous vous attendons nombreux !

Actualité des produits dérivés

  • DbWrench Database Design v1.4.7 (sortie le 20.05.2008), création de diagrammes Entités/Relations, http://www.dbwrench.com/

Avancées sur PostgreSQL

Ce mois de mai a vu l'arrivée d'un nouveau « commit fest » qui a aboutit à l'intégration de nombreux patchs :

  • Moteur - Instructions SQL
    • Ajout d'une option RESTART (sans paramètre) à ALTER SEQUENCE pour réinitialiser une séquence à sa valeur d'origine.
  • Moteur - Fonctions internes
    • Ajout de la fonction pg_conf_load_time() pour connaître l'heure du dernier chargement de la configuration
    • Ajout des versions timestamp et timestamptz de generate_series().
  • Moteur - Statistiques
    • Ajout du support pour tracer les appels et la durée d'exécution des fonctions utilisateur.
  • Moteur - Divers
    • Ajout du support de la traduction d'ecpg.
  • psql
    • Affichage de la taille d'une relation avec \d+.
    • Affichage des valeurs possibles des ENUM dans \dt+.
    • Affichage des droits d'accès, les ACL, sur plusieurs lignes pour \z.
    • Réorganisation de l'affichage de l'aide (\?).
  • PL/pgsql
    • Ajout du support de RETURN QUERY EXECUTE.
    • Ajout de l'instruction CASE.

Un « commit fest » vraiment très productif !

Il faut aussi s'attendre le mois prochain à de nouvelles versions correctives.

Avancées sur pgAdmin3

Il y a eu beaucoup de corrections de bogues ce mois-ci. Une version 1.8.4 devrait bientôt apparaître.

Guillaume Lelarge a ajouté deux nouvelles fonctionnalités pour la future 1.10 La sélection d'un noeud principal affiche dans la partie « Propriétés » les noms des éléments de ce noeud (par exemple, un clic sur “Tables” affiche la liste des tables avec le commentaire associé). Une colonne supplémentaire a été ajoutée pour afficher le propriétaire des objets. De plus, des informations statistiques manquaient pour les tables : n_live_tup, n_dead_tup, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze. Tout est ajouté dans l'onglet « Statistiques ».

De son côté, Dave Page a ajouté la découverte automatique de serveurs PostgresPlus, le support de l'option –clean de pg_restore ainsi que celui des triggers TRUNCATE pour PostgreSQL 8.4. Enfin, il a ré-écrit le code sur la gestion de la configuration.

Avancées sur phpPgAdmin

Pas grand chose ce mois-ci en dehors d'un patch pour ajouter le support de l'authentification Kerberos dans phpPgAdmin, et un autre portant sur le coeur du système.

Sessions de formation

Dalibo, en partenariat avec la société Mandriva, organise une session de formation « PostgreSQL Avancé » fin février à Paris. Destinée aux administrateurs confirmés de PostgreSQL (ou autre SGBD), la formation « PostgreSQL Avancé » donne les clés pour comprendre, sécuriser et optimiser les bases des données PostgreSQL.

Plus d'informations sur : http://dalibo.com/-Formations-.html

Dernières versions

Depuis le 18 mars 2008 :

  • 8.3.1
  • 8.2.7
  • 8.1.11
  • 8.0.15
  • 7.4.19

Version Windows supportée :

  • 8.3.1
  • 8.2.7

Informations générales

Cette lettre d'information présente l'actualité francophone et internationale de PostgreSQL et de ses “logiciels satellites”. Elle vous est proposée par la société Dalibo.

Dalibo est une société d'expertise sur PostgreSQL et tous ses projets satellites.

Dalibo peut vous accompagner dans la mise en œuvre efficace et professionnelle de PostgreSQL. Qu'il s'agisse d'un nouveau projet ou de la migration d'un existant.

Si vous ne souhaitez plus recevoir cette lettre, envoyez simplement un courriel à l'adresse : newsletter-desabonnement@listes.dalibo.com

Afficher le texte source