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

16

  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?

replication postgresql mrkafk
la source
Il y a quelques années, nous avons eu le même problème. Finalement, nous avons déplacé toutes nos affaires vers Oracle. J'espère que vous pouvez trouver une réplication multimaître utilisable ces jours-ci, je n'ai pas regardé ... Bonne chance, néanmoins.
grufftech
2
La propre documentation de PostgreSQL indique d'utiliser une application middleware :) .. " Réplication synchrone multimaître . PostgreSQL n'offre pas ce type de réplication, bien que la validation en deux phases de PostgreSQL (PREPARE TRANSACTION et COMMIT PREPARED) puisse être utilisée pour l'implémenter dans code d'application ou middleware "
warren
Vous n'êtes pas limité à deux nœuds.
foocorpluser
blog.2ndquadrant.com/bdr-is-coming-to-postgresql-9-6
Neil McGuigan

Réponses:

6

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é.

Peter Eisentraut
la source
1
Je n'étais pas assez précis apparemment: j'ai besoin d'une réplication synchrone. D'ailleurs, quelle est la signification de cela dans la FAQ? "Bucardo peut-il se reproduire entre plus de deux maîtres? Non. Actuellement, Bucardo ne prend en charge que le maître à maître (ainsi que le maître à de nombreux esclaves bien sûr)." Est-ce donc multi-maître ou non?
mrkafk
4
Seulement si votre définition de "multi" est "2"!
hmallett
Veuillez noter qu'à partir de Bucardo 5, la limitation de seulement 2 maîtres a été levée
Joril
3

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.

voretaq7
la source
Wow, juste lire cette liste provoque un choc et une terreur pour moi. :)
Peter Eisentraut
Pour moi, c'est la dépression et le dégoût :-)
voretaq7
Je pense que l'utilisation d'un système similaire à etcd pour la configuration et les communications serait possible, peut-être en exécutant n'importe quelle instruction de mise à jour dans un commit en deux phases ... une partie difficile serait de garder un noeud jusqu'à ce qu'il soit rattrapé et correspond à d'autres noeuds .. J'adorerais vraiment une solution presque automagique pour cela
Tracker1
3

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.

Justin
la source
2

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

Peter Eisentraut
la source
Cela fait quelques années que je n'ai pas fait de recherche, mais mon entreprise est arrivée à cette conclusion lorsque nous avons essayé.
grufftech
1

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 :)

lynxman
la source
Hmm c'est intéressant, mais d'après ce que j'ai vu ici: wiki.postgresql.org/wiki/… , Londiste est maître-esclave et asynchrone? Alors, comment peut-il être multi-maître? De plus, j'ai vraiment besoin d'une réplication synchrone: la transaction doit échouer si l'un des nœuds de cluster (actifs) échoue.
mrkafk
Cette réplication est post-transactionnelle sinon elle serait assez lente
lynxman
Je ne veux pas ressembler à une douleur dans le cul (piqûre), mais ... 1. J'ai utilisé pgpool-II et les transactions sont passées assez rapidement (même si je n'ai pas fait de benchmarks), et 2. même si les transactions individuelles peuvent être plus lentes, je ne vois pas de bonne raison pour que le débit global des transactions soit faible. Quoi qu'il en soit, le point le plus important est peut-être de savoir comment Londiste est multimaître. Puis-je écrire sur le serveur pg 1 et le faire répliquer sur 2, et écrire sur le serveur pg 2 et le faire répliquer sur le serveur 1?
mrkafk
1

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

Herberth Amaral
la source
-2

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!

mrkafk
la source
2
@mrafk - publieriez-vous / lieriez-vous le "code de travail" que vous avez?
warren
2
Qu'est-ce que cela a à voir avec la réplication avec postgres? Cela distribuera les messages, mais où obtenez-vous les messages / mises à jour de données de la base de données et comment met-il à jour les nœuds recevant les messages dans la file d'attente de messages?
monksy
3
Cela peut être une solution au problème fondamental auquel vous étiez confronté, mais ce n'est pas une réponse à cette question.
Tom Anderson