¿Replicación multi-master utilizable para Postgres?

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?

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

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.

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.

La respuesta a eso es un rotundo no.

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

Si todavía está interesado, pruebe este: http://www.symmetricds.org/ (solo Java)

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!