45 votes

Réplication PostgreSQL

Nous en parlons constamment au bureau, et la question revient sans cesse. Comment gérer la réplication de PostgreSQL ? Je ne parle même pas nécessairement de clusters avancés, mais simplement de Master-Slave, Master-MultiSlave et Master-Master. Je trouve que la mise en place de MySQL est généralement assez simple. Le basculement est simple, voire parfait, surtout si l'on considère la facilité avec laquelle il est configuré. Nous avons joué avec Slony, mais c'est un peu trop manuel (les changements de schéma nécessitent une intervention, les nouvelles bases de données nécessitent une intervention, etc). PGPool2 était plutôt bien, jusqu'à ce qu'un nœud tombe en panne et que nous ne trouvions pas de moyen gracieux (autre que de tout arrêter et de réensemencer le nœud tombé en panne) pour rétablir la synchronisation de la réplication. En gros, voici ce que je recherche typiquement :

  • Installation facile (je me contenterai d'une installation difficile, mais facile à étendre)
  • Basculement simple
  • Le rétablissement d'un nœud tombé en panne demande simplement du temps (comme pour mysql. Le serveur tombe en panne, vous le remontez et attendez que la réplication le rattrape).
  • Les changements de schéma n'interrompent pas la réplication
  • L'ajout d'une nouvelle base de données au serveur est transparent (comme pour mysql, il est possible de répliquer un serveur de base de données entier, de sorte qu'une nouvelle base de données créée sur le maître se propage automatiquement à l'esclave).

MySQL gère la plupart d'entre eux assez bien, mais j'ai un certain penchant pour PostgreSQL. De plus, dans certaines situations, c'est notre seule option, et nous aimerions ajouter la réplication au mélange. Qu'utilisez-vous actuellement et que pensez-vous de votre solution ? Ce n'est pas un article sur MySQL versus PostgreSQL, je le promets, parce que ce n'est pas ce que j'essaie de commencer :)

9voto

macbirdie Points 9417

Réponse courte - il n'existe pas encore de solution pour PostgreSQL si vous avez besoin d'esclaves en ligne en lecture seule.

Deux projets de développement majeurs sont actuellement en cours dans ce domaine et sont inclus dans PostgreSQL 9.0 (Spring/Été 2010), à savoir :

  • Réplication synchrone :

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

  • Esclaves en attente à chaud en lecture seule :

http://wiki.postgresql.org/wiki/Hot_Standby

qui, combinés, visent à obtenir la facilité d'utilisation de la réplication à la MySQL, sans les bogues/problèmes de MySQL, ainsi que la fiabilité que les utilisateurs connaissent de PostgreSQL.

Tout cela a été lancé par un manifeste de l'équipe centrale de PostgreSQL en 2008 :

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Les solutions de réplication PostgreSQL les plus utilisées à ce jour sont Slony-I (plus cher pour les écritures, rend les changements de schéma difficiles), WAL shipping/walmgr (les esclaves ne peuvent pas être utilisés en ligne) et pgQ/londiste de Skype/Skytools (plus des outils/éléments de construction qu'une solution finie).

J'ai écrit quelques articles sur Log Shipping, walmgr et Slony-I, voir

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 pour plus d'informations.

5voto

Et pour lancer une autre solution dans l'arène : rubyrep.

Pour comparer avec vos besoins :

  • Installation facile
    Oui, c'est en fait l'objectif principal de rubyrep.
  • Basculement simple
    Oui. En fait, rubyrep effectue une réplication maître-maître - pour basculer, aucune action n'est nécessaire. Il suffit d'utiliser l'autre base de données.
  • Les changements de schéma n'interrompent pas la réplication
    Oui.
    Pour les changements de clés non primaires, la réplication n'a même pas besoin de s'arrêter (mais assurez-vous que le schéma est modifié des deux côtés en même temps).
    Pour ajouter / supprimer des tables, il suffit de redémarrer le démon de réplication. Seule la modification de la colonne de la clé primaire d'une table demande un peu d'effort.
  • L'ajout d'une nouvelle base de données au serveur est transparent (comme pour mysql, il est possible de répliquer un serveur de base de données entier, de sorte qu'une nouvelle base de données créée sur le maître se propage automatiquement à l'esclave).
    Cela n'est possible que de manière limitée : chaque configuration de rubyrep ne réplique qu'une seule base de données à la fois. (Mais il est très facile de mettre en place une réplication pour plus d'une base de données).

4voto

warren Points 12172

Vous n'avez pas mentionné la nécessité d'avoir un esclave de lecture chaud, je vais donc proposer d'utiliser Heartbeat avec un stockage partagé ou un DRBD. Il fait ce qu'il faut et l'administration est un jeu d'enfant. C'est l'équivalent Linux de l'ancien clustering de Microsoft SQL Server. Un nœud est actif et l'autre est passif, tandis que les données sont partagées entre les deux. Vous n'avez pas à vous soucier de la réplication basée sur SQL, car elle est gérée au niveau du bloc.

Sérieusement, c'est de loin la meilleure solution si vous n'avez pas besoin d'esclaves de lecture. L'archivage WAL était au mieux bidon et vous devez tout réinstaller si vous interrompez le processus d'expédition pour redémarrer le serveur. slony et londiste ne font pas l'affaire. Si vous voulez rester sur l'arbre principal des sources et ne pas faire de commerce, Heartbeat est votre meilleur choix.

3voto

Telcontar Points 2329

D'après vos exigences, il semble que PITR soit le moyen le plus simple de résoudre votre problème :

Sauvegarde en ligne et récupération ponctuelle (PITR)

Vous n'avez pas indiqué que vous deviez interroger le serveur esclave, de sorte que PITR pourrait convenir.

Il fait partie intégrante de PostgreSQL depuis la version 8.0, vous avez donc probablement déjà tout ce qu'il faut pour le mettre en place et le faire fonctionner.

Si vous trouvez les instructions trop verbeuses, jetez un coup d'œil à SkyTools WalMgr ce qui rendra le processus de création/de basculement vers des données en attente à chaud une simple tâche de commande.

Pour des scénarios de réplication plus complexes, j'ai eu une bonne expérience avec Slony-1, mais PostgreSQL a beaucoup de bonnes options de réplication/HA disponibles.

2voto

EmmyS Points 1766

Si vous souhaitez une réplication asynchrone maître/esclave, pensez à Londiste (qui fait partie du package skytools de Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Il est facile à installer, l'ajout d'une nouvelle base de données est facile, la réplication se rattrape simplement.

Le basculement n'est cependant pas intégré. Vous devrez modifier les chaînes de connexion de votre application ou dissimuler la connexion à la base de données derrière une autre couche logicielle.

Certaines modifications de schéma sont faciles à réaliser. D'autres sont plus difficiles. Cela dépend de votre application. La prochaine version de skytools (ver 3.0) est censée gérer les DDL et inclure des facilités pour faciliter le basculement.

Nous sommes passés à Londiste après avoir trouvé Slony trop pénible à utiliser.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X