Eu tentei o Postgres-XC e ele ainda não implementa o SQL completo (como o SERIAL)
O Postgres-R parece interessante, mas "não está pronto para produção", segundo os desenvolvedores.
Então eu usei o pgpool-II 3.0.1. Sim, funciona bem. Mas, tanto quanto eu posso ver, é apenas para 2 nós PG.
Existe alguma coisa que esteja realmente pronta para produção E capaz de trabalhar com múltiplos nós PG?
Encontrei o sistema de replicação "multi-master" utilizável:
configure um cluster do Rabbit MQ no Rabbit.
crie uma fila para cada nó em um cluster e vincule-os à troca de tipo 'fanout'.
Desta forma, uma mensagem enviada para qualquer nó e qualquer fila é replicada para todos os outros nós. Eu tenho um código de trabalho para isso!
Você já considerou o Bucardo ? É um multimaster assíncrono. Não foi completamente pego e não é uma solução geral, mas pode valer a pena tentar.
Eu tenho que concordar com a avaliação de Peter: Não existe uma replicação multi-master boa para o Postgres agora. (A verdadeira replicação multimestre é um problema muito difícil, e eu não estou enamorado com nenhuma das soluções disponíveis.)
Críngando a lista de possíveis soluções da Wikipédia que você pode querer investigar:
PostgreSQL offers multiple solutions for multi-master replication, including solutions based on two phase commit. There's Bucardo, rubyrep, PgPool and PgPool-II, PgCluster and Sequoia as well as some proprietary solutions. Another promising approach, implementing eager (synchronous) replication is Postgres-R, however it is still in development. Yet another project, implementing synchronous replication is Postgres-XC. Postgres-XC also is still under development.
Isso é pesado orientado para Java, mas as APIs do cliente de banco de dados nativo podem ser vinculadas a fontes de dados JDBC. Tungsten Myosotis é um exemplo para o MySQL nativo da ponte JDBC.
O Tungsten Enterpriese é bom para assíncrono multi-mestre. Eu acho que funciona para MySQL, PostgreSQL e Oracle. Ele pode ser executado de forma independente ou incorporado em um aplicativo Java. Eu já vi isso funcionar para o MySQL, mas eles alegam o PostgreSQL. Seu componente Replicator é de código aberto, mas a solução completa tem mais partes e requer custos de licenciamento. Inicialmente, o Sequoia tinha multi-master síncrono, mas o abandonou e criou o Tungsten para assíncrono multi-mestre - eles consideram expandir um negócio mais estratégico do que a consistência do ACID síncrono. O tungstênio é escrito em Java, e é por isso que eles oferecem o Myosotis para fazer a ponte entre os clientes de banco de dados nativos.
SymmetricDS é bom para assíncrono multi-mestre. É de código aberto. Ele instala / desinstala os gatilhos para capturar atualizações, em vez de registrar em bin. Ele pode ser executado de forma independente ou incorporado em um aplicativo Java.
O HA-JDBC é bom para síncrono multi-mestre. Ele substitui softwares mais antigos, como C-JDBC e Sequoia. É de código aberto. Ele usa commit de duas fases e funciona para PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase e muitos outros através de dialetos. É principalmente para o embedded, portanto, incorpore em um aplicativo Java para vinculá-lo ao PostgreSQL. Bloqueios, seqüências, tempo, rand e assim por diante distribuídos são manipulados por jGroups do Redhat / JBoss. Um bom recurso é o modo de transação "serial" em vez de "paralelo", se o seu aplicativo apresentar bloqueios e não suportar a reversão. Eu usei esse modo "serial" com êxito para atualizar um aplicativo herdado que não estava ciente do cluster de DB, portanto, ele não tinha código de repetição de transação. O modo serial salvou o dia e evitou uma reescrita desagradável.
H2 é bom para síncrono multi-mestre. É de código aberto. Ele suporta bancos de dados independentes ou clusters usando two-phase commit, semelhante à arquitetura HA-JDBC, mas é tudo em um em vez de exigir um componente extra para two-phase commit. Não tenho certeza se ele faz bloqueios distribuídos, ou depende de terceiros como jGroups ou Hazelcast.
Qualquer replicação baseada em JDBC para o PostgreSQL e outros bancos de dados precisa de uma ponte JDBC nativa, a menos que seu aplicativo já esteja escrito em Java. Para o MySQL, o Tungsten Enterprise oferece um componente opcional chamado Myosotis. Eu usei com sucesso este para ligar PHP / Perl / C / mysqlclient para JDBC, onde a fonte de dados JDBC passou a ser uma fonte de dados de proxy HA-JDBC apontando para um cluster MySQL / InnoDB de 4 nós.
A Tungsten suporta o PostgreSQL em seus componentes Replicator e Router, mas não tem certeza sobre o componente Myosotis. Talvez. Os componentes do Replicador de tungstênio / roteador são para multi-mestre assíncrono, mas o Myosotis pode conectá-lo a um back-end JDBC alternativo, como HA-JDBC ou H2, para sincronização.
Se houver um nativo do PostgreSQL para a ponte JDBC, eu gostaria de ouvir sobre isso. Em teoria, qualquer banco de dados com um driver JDBC Tipo 4 pode ser conectado em ponte. O JDBC tipo 4 fala o protocolo do banco de dados nativo exatamente como a interface do cliente nativo desse banco de dados, portanto, deve haver um mapeamento de um para um das chamadas nativas para as chamadas JDBC.
A resposta para isso é um retumbante não.
Estou usando o londiste nos últimos dois anos para replicação multimestre no postgresql.
Você coloca suas tabelas em filas usando pg_queue e pode assinar quantos outros bancos de dados quiser em cada fila, a replicação é atômica por fila e é muito resiliante.
Você pode ler sobre o londiste aqui ( link ), isso é o que os caras do Skype usam para o cluster, também criaram então é o dobro do legal:)
Se ainda estiver interessado, tente este: link (Apenas Java)
Tags postgresql replication