Réplication multi-maître utilisable pour Postgres?

1. J'ai essayé Postgres-XC et il n'implémente pas encore le SQL complet (comme SERIAL)

2. Postgres-R semble intéressant mais il n'est "pas prêt pour la production" selon les développeurs.

J'ai donc utilisé pgpool-II 3.0.1. Oui, ça marche bien. Mais pour autant que je sache, ce n'est que pour 2 nœuds PG.

Existe-t-il quelque chose qui soit réellement prêt pour la production ET capable de travailler avec plusieurs nœuds PG?

Avez-vous pensé à Bucardo ? C'est multimaster asynchrone. Il n'a pas complètement fait son chemin et n'est pas une solution générale, mais cela pourrait valoir la peine d'être essayé.

Je suis d'accord avec l'évaluation de Peter: il n'y a pas vraiment de bonne réplication multimaître pour Postgres en ce moment. (Faire une véritable réplication multimaître est un problème très difficile, et je ne suis séduit par aucune des solutions disponibles.)

Cribbing Wikipédia liste des solutions potentielles que vous voudrez peut-être étudier:

PostgreSQL propose plusieurs solutions pour la réplication multimaître, y compris des solutions basées sur une validation en deux phases. Il y a Bucardo, rubyrep, PgPool et PgPool-II, PgCluster et Sequoia ainsi que certaines solutions propriétaires. Postgres-R est une autre approche prometteuse, implémentant une réplication désirée (synchrone), mais elle est toujours en développement. Encore un autre projet, implémentant la réplication synchrone est Postgres-XC. Postgres-XC est également en cours de développement.

C'est très orienté Java, mais les API clientes des bases de données natives peuvent être reliées aux sources de données JDBC. Tungsten Myosotis est un exemple pour MySQL natif du pontage JDBC.

• Tungsten Enterpriese est bon pour les multi-maîtres asynchrones. Je pense que cela fonctionne pour MySQL, PostgreSQL et Oracle. Il peut fonctionner de manière autonome ou intégré dans une application Java. Je l'ai vu fonctionner pour MySQL, mais ils prétendent PostgreSQL. Leur composant Replicator est open-source, mais la solution complète a plus de pièces et nécessite des coûts de licence. Continuent avait à l'origine Sequoia pour la synchronisation multi-maîtres mais ils l'ont abandonné et ont créé Tungsten à la place pour la synchronisation multi-maîtres asynchrone - ils considèrent la mise à l'échelle comme une activité plus stratégique que la cohérence ACID synchrone. Tungsten est écrit en Java, c'est pourquoi ils proposent Myosotis pour combler les clients de bases de données natives.

• SymmetricDS est bon pour les multi-maîtres asynchrones. C'est open-source. Il installe / désinstalle des déclencheurs pour capturer les mises à jour, au lieu de la journalisation des bacs. Il peut fonctionner de manière autonome ou intégré dans une application Java.

• HA-JDBC est bon pour les synchrones multi-maîtres. Il remplace les anciens logiciels disparus comme C-JDBC et Sequoia. C'est open-source. Il utilise une validation en deux phases et fonctionne pour PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase et bien d'autres via des dialectes. C'est principalement pour l'embarqué, donc embarqué dans une application Java pour le relier à PostgreSQL. Les verrous distribués, les séquences, l'heure, le rand, etc. sont gérés par les jGroups de Redhat / JBoss. Une fonctionnalité intéressante est le mode de transaction "série" au lieu de "parallèle", si votre application a connu des blocages et ne prend pas en charge la restauration. J'ai utilisé avec succès ce mode "série" pour moderniser une application héritée qui n'était pas au courant du cluster DB, il manquait donc le code de nouvelle tentative de transaction. Le mode série a sauvé la journée et évité une réécriture désagréable.

• H2 est bon pour les synchrones multi-maîtres. C'est open-source. Il prend en charge les bases de données autonomes ou les clusters utilisant la validation en deux phases, similaire à l'architecture HA-JDBC, mais il est tout en un au lieu de nécessiter un composant supplémentaire pour la validation en deux phases. Je ne sais pas si elle se verrouille distribuée elle-même, ou dépend de tiers comme jGroups ou Hazelcast.

Toute réplication basée sur JDBC pour PostgreSQL et d'autres bases de données nécessite un pont natif vers JDBC, sauf si votre application est déjà écrite en Java. Pour MySQL, Tungsten Enterprise propose un composant optionnel appelé Myosotis. J'ai utilisé cela avec succès pour relier PHP / Perl / C / mysqlclient à JDBC, où la source de données JDBC se trouvait être une source de données proxy HA-JDBC pointant vers un cluster MySQL / InnoDB à 4 nœuds.

Tungsten prend en charge PostgreSQL dans leurs composants Réplicateur et Routeur, mais n'est pas sûr du composant Myosotis. Peut être. Les composants de réplicateur / routeur de tungstène sont pour asynchrones multi-maîtres, mais Myosotis peut vous relier à un back-end JDBC alternatif comme HA-JDBC ou H2 pour synchrone.

S'il existe un pont PostgreSQL natif de JDBC, j'aimerais en entendre parler. En théorie, toute base de données avec un pilote JDBC Type 4 peut être pontée. Le type 4 JDBC parle de protocole de base de données natif tout comme l'interface client native pour cette base de données, il doit donc y avoir un mappage un à un des appels natifs vers les appels JDBC.

La réponse à cette question est un non catégorique.

J'utilise londiste depuis 2 ans pour la réplication multimaître dans postgresql.

Vous mettez vos tables dans des files d'attente à l'aide de pg_queue et vous pouvez vous abonner autant de bases de données que vous le souhaitez à chaque file d'attente, la réplication est atomique par file d'attente et elle est très résistante.

Vous pouvez lire sur londiste ici ( http://pgfoundry.org/projects/skytools/ ), c'est ce que les gars de Skype utilisent pour leur cluster, ils l'ont également créé, donc c'est le double de la cool :)

Si vous êtes toujours intéressé, essayez celui-ci: http://www.symmetricds.org/ (Java uniquement)

J'ai trouvé un système de réplication "multi-maître" utilisable:

1. obtenez RabbitMQ http://www.rabbitmq.com/ - c'est un middleware de message.

2. configurer un cluster Rabbit MQ dans Rabbit.

3. créer une file d'attente pour chaque nœud d'un cluster et les lier à l'échange de type «fanout».

De cette façon, un message envoyé à n'importe quel nœud et à n'importe quelle file d'attente est répliqué sur tous les autres nœuds. J'ai un code de travail pour ça!