Replicação multimestre utilizável para Postgres?


16
  1. Eu tentei o Postgres-XC e ele ainda não implementa SQL completo (como SERIAL)

  2. O Postgres-R parece interessante, mas "não está pronto para produção", de acordo com 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 lá fora, na verdade pronta para produção E capaz de trabalhar com vários nós PG?


Alguns anos atrás, chegamos ao mesmo problema. Eventualmente, mudamos todas as nossas coisas para a Oracle. Espero que você possa encontrar replicação multimaster utilizável nos dias de hoje, eu não olhei ... Boa sorte, no entanto.
grufftech

2
A própria documentação do PostgreSQL diz para usar um aplicativo de middleware :) .. " Replicação síncrona de multimaster . O PostgreSQL não oferece esse tipo de replicação, embora o commit de duas fases do PostgreSQL (PREPARE TRANSACTION e COMMIT PREPARED) possa ser usado para implementar isso em código de aplicação ou middleware "
warren

Você não está limitado a dois nós.
foocorpluser

Respostas:


6

Você já considerou Bucardo ? É multimaster assíncrono. Não pegou completamente e não é uma solução geral, mas pode valer a pena tentar.


11
Aparentemente, eu não era suficientemente específico: preciso de replicação síncrona. Além disso, qual é o significado disso nas perguntas frequentes? "Bucardo pode replicar entre mais de dois mestres? Não. Atualmente, Bucardo suporta apenas mestre para mestre (assim como mestre para muitos escravos, é claro)." Então, é multi-master ou não?
mrkafk

4
Somente se sua definição de "multi" for "2"!
hmallett

Por favor, note que a partir Bucardo 5 a limitação de apenas 2 mestres foi levantada
Joril

3

Eu tenho que concordar com a avaliação de Peter: Não há realmente uma boa replicação multimestre para o Postgres no momento. (Realizar replicação multimestre verdadeira é um problema muito difícil, e não estou apaixonada por nenhuma das soluções disponíveis.)

Cribbing A lista de possíveis soluções da Wikipedia que você pode querer investigar:

O PostgreSQL oferece várias soluções para replicação multimestre, incluindo soluções baseadas em confirmação de duas fases. Existem Bucardo, rubyrep, PgPool e PgPool-II, PgCluster e Sequoia, além de algumas soluções proprietárias. Outra abordagem promissora, implementando a replicação ágil (síncrona), é o Postgres-R, mas ainda está em desenvolvimento. Outro projeto, implementando a replicação síncrona, é o Postgres-XC. O Postgres-XC também ainda está em desenvolvimento.


Uau, apenas ler essa lista causa choque e terror para mim. :)
Peter Eisentraut

Para mim é a depressão e ódio :-)
voretaq7

Eu pensaria que seria possível usar um sistema semelhante ao etcd para configuração e comunicação, talvez executando qualquer instrução de atualização dentro do commit de duas fases ... uma parte difícil seria manter um nó de fora até que ele seja capturado e corresponda a outros nós. . Eu realmente adoraria uma solução perto automagic para este
Tracker1

3

Isso é orientado para Java pesado, mas as APIs do cliente de banco de dados nativo podem ser conectadas às fontes de dados JDBC. O Tungsten Myosotis é um exemplo para o MySQL nativo da ponte JDBC.


  • Tungstênio Enterpriese é bom para multi-mestre assíncrono. Eu acho que funciona para MySQL, PostgreSQL e Oracle. Pode ser executado de forma independente ou incorporado em um aplicativo Java. Eu já vi isso funcionar no MySQL, mas eles reivindicam o PostgreSQL. O componente Replicator é de código aberto, mas a solução completa possui mais peças e requer custos de licenciamento. O Continuent originalmente possuía o Sequoia para multi-mestre síncrono, mas eles o abandonaram e, em vez disso, criaram o Tungsten para multi-mestre assíncrono - consideram escalar um negócio mais estratégico do que a consistência síncrona do ACID. O tungstênio é escrito em Java; é por isso que eles oferecem o Myosotis para conectar clientes de banco de dados nativos.

  • SymmetricDS é bom para multi-mestre assíncrono. É de código aberto. Ele instala / desinstala os gatilhos para capturar atualizações, em vez do log de posição. Pode ser executado de forma independente ou incorporado em um aplicativo Java.

  • O HA-JDBC é bom para síncrono multimestre. Ele substitui o software extinto mais antigo, como C-JDBC e Sequoia. É de código aberto. Ele usa commit de duas fases e trabalha para PostgreSQL, MySQL, Oracle, SQL Server, Derby, Sybase e muitos outros via dialetos. É principalmente para incorporado, portanto, incorpore em um aplicativo Java para conectá-lo ao PostgreSQL. Bloqueios distribuídos, sequências, hora, rand, etc. são tratados pelo jGroups do Redhat / JBoss. Um recurso interessante é o modo de transação "serial" em vez de "paralelo", se o seu aplicativo tiver conflitos e não suportar reversão. Usei esse modo "serial" com êxito para atualizar um aplicativo herdado que não tinha conhecimento do cluster de banco de dados e, portanto, estava faltando o código de nova tentativa de transação. O modo serial salvou o dia e evitou uma reescrita desagradável.

  • H2 é bom para multi-mestre síncrono. É de código aberto. Ele suporta bancos de dados ou clusters independentes usando confirmação de duas fases, semelhante à arquitetura HA-JDBC, mas é tudo em um, em vez de exigir um componente extra para confirmação de duas fases. Não tenho certeza se ele distribui bloqueios ou depende de terceiros, como jGroups ou Hazelcast.

Qualquer replicação baseada em JDBC para PostgreSQL e outros bancos de dados precisa de uma ponte nativa para JDBC, a menos que seu aplicativo já esteja gravado em Java. Para o MySQL, o Tungsten Enterprise oferece um componente opcional chamado Myosotis. Usei isso com êxito para conectar o PHP / Perl / C / mysqlclient ao JDBC, onde a fonte de dados JDBC era uma fonte de dados proxy HA-JDBC apontando para um cluster MySQL / InnoDB de 4 nós.

O Tungsten suporta o PostgreSQL nos componentes Replicator e Router, mas não tem certeza sobre o componente Myosotis. Talvez. Os componentes do replicador / roteador de tungstênio são para multi-mestre assíncrono, mas o Myosotis pode conectar você a um back-end JDBC alternativo, como HA-JDBC ou H2, para síncrona.

Se houver um nativo do PostgreSQL na ponte JDBC, eu gostaria de ouvir sobre isso. Em teoria, qualquer banco de dados com um driver JDBC Tipo 4 pode ser ponte. O JDBC do tipo 4 fala o protocolo de banco de dados nativo da mesma forma que a interface do cliente nativo para esse banco de dados; portanto, deve haver um mapeamento individual das chamadas nativas para chamadas JDBC.


2

A resposta para isso é um retumbante não.


Faz alguns anos desde que eu pesquisei, mas minha empresa chegou a essa conclusão quando tentamos.
grufftech

1

Eu venho usando londiste nos últimos 2 anos para replicação multimestre no postgresql.

Você coloca suas tabelas em filas usando pg_queue e pode assinar quantos outros bancos de dados desejar para cada fila, a replicação é atômica por fila e é muito resistente.

Você pode ler sobre londiste aqui ( http://pgfoundry.org/projects/skytools/ ), é isso que os caras do Skype usam para o cluster, eles também o criaram, então é o dobro da diversão :)


Hummm isso é interessante, mas de acordo com o que eu vi aqui: wiki.postgresql.org/wiki/… , Londiste é escravo-mestre e assíncrono? Então, como pode ser multi-master? Além disso, preciso mesmo de replicação síncrona: a transação falhará se algum dos nós do cluster (ativo) falhar.
mrkafk

Essa replicação é pós-transacional caso contrário, seria bastante lento
lynxman

Eu não pretendo soar como um pé no saco (nitpicking), mas ... 1. Eu usei o pgpool-II e as transações foram muito rápidas (embora eu não tenha feito benchmarks), e 2. embora Se a transação individual for mais lenta, não vejo uma boa razão para o rendimento geral das transações ser baixo. Enfim, talvez o ponto mais importante seja como é o multi-mestre Londiste? Posso gravar no servidor pg 1 e replicá-lo para 2 e gravar no servidor 2 e replicá-lo no servidor 1?
mrkafk


-2

Eu encontrei o sistema de replicação "multimestre" utilizável:

  1. obtenha o RabbitMQ http://www.rabbitmq.com/ - é um middleware de mensagem.

  2. configure um cluster Rabbit MQ no Rabbit.

  3. crie fila para cada nó em um cluster e vincule-os à troca do tipo 'fanout'.

Dessa 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!


2
@rafraf - você postaria / vincularia o "código de trabalho" que possui?
Warren

2
O que isso tem a ver com a replicação com o postgres? Isso distribuirá as mensagens, mas de onde você está recebendo as atualizações / mensagens de dados do banco de dados e como está atualizando os nós que recebem as mensagens na fila de mensagens?
monksy

3
Esta pode ser uma solução para o problema fundamental que estavam enfrentando, mas é não uma resposta a esta pergunta.
Tom Anderson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.