¿Replicación multi-master utilizable para Postgres?


16
  1. Intenté Postgres-XC y todavía no implementa SQL completo (como SERIAL)

  2. Postgres-R parece interesante pero "no está listo para la producción" según los desarrolladores.

Entonces utilicé pgpool-II 3.0.1. Sí, funciona muy bien. Pero por lo que puedo ver, solo es para 2 nodos PG.

¿Hay algo por ahí que esté listo para la producción Y sea capaz de trabajar con múltiples nodos PG?


Hace unos años aterrizamos con el mismo problema. Finalmente, trasladamos todas nuestras cosas a Oracle. Espero que pueda encontrar replicación multimaster utilizable en estos días, no he buscado ... Buena suerte, sin embargo.
grufftech

2
La propia documentación de PostgreSQL dice que se debe usar una aplicación de middleware :) .. " Replicación síncrona multimaster .. PostgreSQL no ofrece este tipo de replicación, aunque se puede utilizar el compromiso de dos fases de PostgreSQL (PREPARE TRANSACTION y COMMIT PREPARED) para implementar esto en código de aplicación o middleware "
warren

No está limitado a dos nodos.
foocorpluser

Respuestas:


6

¿Has considerado a Bucardo ? Es asíncrono multimaster. No se ha entendido completamente y no es una solución general, pero puede valer la pena intentarlo.


1
Aparentemente no era lo suficientemente específico: necesito replicación sincrónica. Además, ¿cuál es el significado de esto en las preguntas frecuentes? "¿Puede Bucardo replicar entre más de dos maestros? No. Actualmente, Bucardo solo admite maestro a maestro (así como maestro a muchos esclavos, por supuesto)". Entonces, ¿es multimaestro o no?
mrkafk

44
¡Solo si su definición de "multi" es "2"!
hmallett

Tenga en cuenta que a partir de Bucardo 5 se ha eliminado la limitación de solo 2 maestros
Joril

3

Tengo que estar de acuerdo con la evaluación de Peter: en este momento no hay una réplica multimaestro realmente buena para Postgres. (Hacer una verdadera replicación multimaestro es un problema muy difícil, y no estoy enamorado de ninguna de las soluciones disponibles).

Cribando la lista de Wikipedia de posibles soluciones que puede investigar:

PostgreSQL ofrece múltiples soluciones para la replicación multimaestro, incluidas soluciones basadas en el compromiso de dos fases. Hay Bucardo, rubyrep, PgPool y PgPool-II, PgCluster y Sequoia, así como algunas soluciones patentadas. Otro enfoque prometedor, la implementación de replicación ansiosa (síncrona) es Postgres-R, sin embargo, todavía está en desarrollo. Otro proyecto más, que implementa la replicación sincrónica es Postgres-XC. Postgres-XC también está todavía en desarrollo.


Wow, solo leer esa lista me causa conmoción y terror. :)
Peter Eisentraut

Para mí es depresión y asco :-)
voretaq7

Pensaría que sería posible usar un sistema similar a etcd para la configuración y las comunicaciones, tal vez ejecutando cualquier declaración de actualización dentro de la confirmación de dos fases ... una parte difícil sería mantener un nodo fuera hasta que quede atrapado y coincida con otros nodos ... Realmente me encantaría una solución
casi automática

3

Esto está orientado a Java, pero las API de cliente de base de datos nativas se pueden conectar a fuentes de datos JDBC. Tungsten Myosotis es un ejemplo para MySQL nativo del puente JDBC.


  • Tungsten Enterpriese es bueno para múltiples maestros asincrónicos. Creo que funciona para MySQL, PostgreSQL y Oracle. Puede ejecutarse de forma independiente o incrustada en una aplicación Java. Lo he visto funcionar para MySQL, pero afirman PostgreSQL. Su componente Replicator es de código abierto, pero la solución completa tiene más partes y requiere costos de licencia. Originalmente, Continuent tenía Sequoia para síncrono multimaestro, pero lo abandonaron y crearon Tungsten en su lugar para asíncrono multimaestro; consideran que es un negocio más estratégico que la consistencia ACID síncrona. Tungsten está escrito en Java, de ahí que ofrezcan Myosotis para conectar clientes de bases de datos nativas.

  • SymmetricDS es bueno para múltiples maestros asincrónicos. Es de código abierto. Instala / desinstala desencadenantes para capturar actualizaciones, en lugar del registro bin. Puede ejecutarse de forma independiente o incrustada en una aplicación Java.

  • HA-JDBC es bueno para múltiples maestros síncronos. Sustituye a los software obsoletos más antiguos como C-JDBC y Sequoia. Es de código abierto. Utiliza el compromiso de dos fases y funciona para PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase y muchos otros a través de dialectos. Es principalmente para incrustar, por lo que incrustar en una aplicación Java para conectarlo a PostgreSQL. JGroups de Redhat / JBoss maneja los bloqueos distribuidos, las secuencias, el tiempo, el rand, etc. Una buena característica es el modo de transacción "serial" en lugar de "paralelo", si su aplicación experimentó puntos muertos y no admite la reversión. Utilicé con éxito este modo "serial" para actualizar una aplicación heredada que no era consciente del clúster DB, por lo que faltaba el código de reintento de transacción. El modo serie salvó el día y evitó una reescritura desagradable.

  • H2 es bueno para múltiples maestros síncronos. Es de código abierto. Admite bases de datos o clústeres independientes que utilizan el compromiso de dos fases, similar a la arquitectura HA-JDBC, pero es todo en uno en lugar de requerir un componente adicional para el compromiso de dos fases. No estoy seguro de si distribuye bloqueos por sí mismo, o depende de terceros como jGroups o Hazelcast.

Cualquier replicación basada en JDBC para PostgreSQL y otras bases de datos necesita un puente nativo para JDBC, a menos que su aplicación ya esté escrita en Java. Para MySQL, Tungsten Enterprise ofrece un componente opcional llamado Myosotis. Utilicé con éxito esto para conectar PHP / Perl / C / mysqlclient a JDBC, donde la fuente de datos JDBC resultó ser una fuente de datos proxy HA-JDBC que apunta a un clúster MySQL / InnoDB de 4 nodos.

Tungsten admite PostgreSQL en sus componentes Replicator y Router, pero no está seguro sobre el componente Myosotis. Tal vez. Los componentes del replicador / enrutador de tungsteno son para asíncronos multimaestro, pero Myosotis puede conectarlo a un back-end JDBC alternativo como HA-JDBC o H2 para síncrono.

Si hay un PostgreSQL nativo para el puente JDBC, me gustaría saberlo. En teoría, cualquier base de datos con un controlador JDBC Tipo 4 puede ser puenteada. El tipo 4 JDBC habla el protocolo de la base de datos nativa al igual que la interfaz de cliente nativa para esa base de datos, por lo que debe haber una asignación uno a uno de las llamadas nativas a las llamadas JDBC.


2

La respuesta a eso es un rotundo no.


Han pasado algunos años desde que investigué, pero mi compañía llegó a esta conclusión cuando lo intentamos.
grufftech

1

He estado usando londiste durante los últimos 2 años para la replicación multimaestro en postgresql.

Pones tus tablas en colas usando pg_queue y puedes suscribirte tantas otras bases de datos que quieras a cada cola, la replicación es atómica por cola y es muy resistente.

Puedes leer sobre londiste aquí ( http://pgfoundry.org/projects/skytools/ ), esto es lo que usan los chicos de Skype para su clúster, también lo crearon, así que es el doble de genial :)


Hmm eso es interesante, pero de acuerdo con lo que he visto aquí: wiki.postgresql.org/wiki/… , Londiste es Master-Slave y Asynchronous? Entonces, ¿cómo puede ser multimaestro? Además, realmente necesito una replicación síncrona: la transacción debería fallar si falla alguno de los nodos del clúster (activo).
mrkafk

Esta replicación es posterior a la transacción; de lo contrario, sería bastante lenta
lynxman

No quiero sonar como un dolor en el culo (quisquilloso), pero ... 1. Utilicé pgpool-II y las transacciones pasaron bastante rápido (aunque no he hecho puntos de referencia), y 2. aunque la transacción individual puede ser más lenta, no veo una buena razón para que el rendimiento general de las transacciones sea bajo. De todos modos, quizás el punto más importante es ¿cómo es Londiste multi-master? ¿Puedo escribir en pg server 1 y hacer que se replique en 2, y escribir en pg server 2 y hacer que se replique en el servidor 1?
mrkafk


-2

Encontré un sistema de replicación "multimaestro" utilizable:

  1. obtener RabbitMQ http://www.rabbitmq.com/ - es un middleware de mensajes.

  2. configurar un clúster Rabbit MQ en Rabbit.

  3. crear cola para cada nodo en un clúster y vincularlos al intercambio de tipo 'fanout'.

De esta manera, un mensaje enviado a cualquier nodo y cualquier cola se replica a todos los demás nodos. ¡Tengo un código de trabajo para esto!


2
@mrafk: ¿publicaría / vincularía el "código de trabajo" que tiene?
Warren

2
¿Qué tiene esto que ver con la replicación con postgres? Esto distribuirá los mensajes, pero ¿de dónde obtiene los mensajes / actualizaciones de datos del DB y cómo actualiza los nodos que reciben los mensajes en la cola de mensajes?
Monksy

3
Esto puede ser una solución al problema fundamental que estuviera frente, pero es no una respuesta a esta pregunta.
Tom Anderson
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.