Replicação do PostgreSQL

Nós constantemente discutimos isso pelo escritório, e a pergunta continua a surgir. Como você lida com a replicação do PostgreSQL? Não estou necessariamente falando de clusters avançados, apenas simplificando-o com Master-Slave, Master-MultiSlave e Master-Master. Acho que configurá-lo para o MySQL é tipicamente bastante simples. O failover é simples, se não perfeito, especialmente pela facilidade de configuração. Jogamos com o Slony, mas é um pouco prático (as mudanças de esquema requerem intervenção, novos bancos de dados exigem intervenção, etc.). O PGPool2 foi bem legal, até que um nó foi desativado e não conseguimos encontrar uma maneira simples (além de reduzir tudo e re-analisar o nó caído) para obter a replicação novamente em sincronia. Basicamente, aqui está o que estou procurando:

• Configuração fácil (decidirei por uma configuração difícil, mas fácil de expandir)
• Failover simplista
• Trazer um nó caído de volta apenas requer tempo (ou seja, como mysql. O servidor fica inoperante, você o abre e aguarda a replicação)
• Alterações no esquema não interrompem a replicação
• Adicionar um novo banco de dados ao servidor é contínuo (ou seja, como o mysql, você pode replicar um servidor de banco de dados inteiro, para que um novo banco de dados seja criado no mestre, ele se propague automaticamente para o escravo)

O MySQL lida com a maioria deles razoavelmente bem, mas tenho um certo carinho pelo PostgreSQL. Além disso, temos algumas situações em que é nossa única opção e gostaríamos de adicionar replicação ao mix. O que você está usando atualmente e como você se sente sobre sua solução? Este não é um post sobre MySQL versus PostgreSQL, prometo, porque não é isso que estou tentando começar. :)

Resposta curta - ainda não existe uma solução para o PostgreSQL se você precisar de escravos on-line somente leitura.

Atualmente, existem dois grandes projetos de desenvolvimento nessa área, incluídos no PostgreSQL 9.0 (primavera / verão 2010), a saber:

• Replicação síncrona:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

• Leia apenas escravos quentes em espera:

http://wiki.postgresql.org/wiki/Hot_Standby

que, em combinação, visam alcançar a facilidade de uso da replicação no estilo MySQL, menos os bugs / problemas que o MySQL possui, além da confiabilidade que os usuários conhecem do PostgreSQL.

Tudo isso foi iniciado por um manifesto da equipe principal do PostgreSQL em 2008:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

As soluções de replicação do PostgreSQL até hoje com a maior base de usuários são Slony-I (mais caro para gravações, faz alterações de esquema complicadas), WAL shipping / walmgr (os Slaves não podem ser usados ​​online) e pgQ / londiste do Skype / Skytools ( mais ferramentas / blocos de construção do que uma solução pronta).

Eu escrevi algumas coisas sobre Log Shipping, walmgr e Slony-I, veja

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 para obter mais informações.

E para lançar outra solução no ringue: rubyrep.

Para comparar com seus requisitos:

• Configuração fácil
  Sim, esse é realmente o foco principal do rubyrep.
• Failover simplista
  Sim. De fato, o rubyrep faz a replicação master-master - para failover, nenhuma ação é necessária. Basta começar a usar o outro banco de dados.
• Alterações de esquema não interrompem a replicação
  Sim.
  Para alterações de chave não primária, a replicação nem precisa parar (mas certifique-se de que o esquema seja alterado nos dois lados ao mesmo tempo)
  Para adicionar / remover tabelas, basta reiniciar o daemon de replicação. Apenas alterar a coluna da chave primária de uma tabela exige um pouco de esforço.
• Adicionar um novo banco de dados ao servidor é contínuo (ou seja, como o mysql, você pode replicar um servidor de banco de dados inteiro, para que um novo banco de dados seja criado no mestre, ele se propague automaticamente para o escravo).
  Isso é suportado apenas de forma limitada: cada rubyrep A instalação replica apenas um banco de dados por vez. (Mas é muito fácil configurar a replicação para mais de um banco de dados.)

Você não mencionou ter um escravo de leitura quente como requisito, por isso vou propor o uso do Heartbeat com armazenamento compartilhado ou DRBD. Ele simplesmente faz a coisa certa e a administração é fácil. É o equivalente do Linux ao cluster mais antigo do Microsoft SQL Server. Um nó está ativo e o outro é passivo enquanto os dados são compartilhados entre os dois. Você não precisa se preocupar com a replicação baseada em SQL, porque tudo é tratado mais abaixo no nível do bloco.

Sério, é de longe a melhor solução se você não precisa ler escravos. O material do arquivo WAL era muito bom e você deve configurar tudo novamente se interromper o processo de entrega para uma reinicialização do servidor. slony e londiste não cortam a mostarda. Se você deseja permanecer na árvore principal de fontes e não comercializar, o Heartbeat é sua melhor aposta.

Pelos seus requisitos, parece que o PITR é a maneira mais fácil de resolver seu problema:

Backup on-line e recuperação point-in-time (PITR)

Você não disse que precisa consultar o servidor escravo, portanto, o PITR pode estar certo.

É parte padrão do PostgreSQL da versão 8.0, então você provavelmente já possui tudo o necessário para colocá-lo em funcionamento.

Se você encontrar instruções muito detalhadas, dê uma olhada no SkyTools WalMgr, que fará o processo de criação / failover em tarefa de comando único de dados de espera a quente.

Para cenários de replicação mais complexos, eu tive uma boa experiência com o Slony-1, mas o PostgreSQL tem muitas boas opções de replicação / alta disponibilidade.

Se você deseja replicação assíncrona de mestre / escravo, considere Londiste (parte do pacote skytools do Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

É fácil de instalar, adicionar um novo banco de dados é fácil, a replicação apenas "alcança".

O failover não está embutido. Você precisará alterar as cadeias de conexão do aplicativo ou ofuscar a conexão do banco de dados atrás de outra camada de software.

Algumas mudanças de esquema são fáceis. Outros são mais difíceis. Depende da sua aplicação. A próxima versão do skytools (versão 3.0) deve lidar com DDL e incluir recursos para facilitar o failover.

Nós nos mudamos para Londiste depois de achar Slony muito doloroso de usar.

Veja uma discussão aqui, talvez isso possa ajudar:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

e

Concorrentes da Bucardo Versão Um, encontrados mais abaixo na página:

http://www.planetpostgresql.org/

Realmente não existem maneiras gratuitas / de código aberto para fornecer o que você está procurando. Se você deseja algo que é tão chave na mão, consulte várias soluções de replicação comercial de terceiros.

Agora, é possível classificar sua própria replicação no Postgres usando o envio de write-head log (WAL):

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

É basicamente aqui que você pode colocar um nó secundário no modo de recuperação contínua e importar os logs de transações para ele a cada {pequeno intervalo}. A configuração do Postgres possui "stubs" para permitir que você faça certas coisas quando um Postgres quando um WAL é concluído e, portanto, não, e é nisso que se baseia essa configuração - utilizando esses "stubs".

No entanto, isso não permite que você faça master-master e / ou replicação circular.

De qualquer forma, ele definitivamente funciona para a erdundância, mas eu não chamaria isso de "configuração fácil", "failover simplista", "sem interrupção" ou algo assim.

Exceto por 'adicionar um novo banco de dados', você pode tentar o Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). É de código aberto, fácil de configurar e suporta failover. As principais limitações são o banco de dados único e a incapacidade de replicar alterações de DDL, ambas na lista TODO.

O Postgres-R parecia promissor, mas não sei se o projeto ainda está vivo.

Atualmente, estou olhando para o replicador de tungstênio, ainda estou longe de qualquer conclusão definitiva, mas provavelmente vale uma olhada.

www.continuent.com