Replicação PostgreSQL

Question

Nós constantemente batemos isso no escritório, e a questão continua a surgir. Como você lida com a replicação do PostgreSQL? Eu não estou necessariamente falando sobre clusters avançados, apenas mantendo-os simples com Master-Slave, Master-MultiSlave e Master-Master. Eu acho que configurá-lo para o MySQL é tipicamente bastante simples. O failover é simples, se não perfeito, especialmente pela facilidade de configuração. Nós tocamos com o Slony, mas é um pouco prático (mudanças de esquema requerem intervenção, novos bancos de dados requerem intervenção, etc). O PGPool2 foi muito legal, até que um nó foi desativado e não conseguimos encontrar um caminho mais gracioso (além de derrubar tudo e espalhar novamente o nó perdido) para obter a replicação de volta em sincronia. Basicamente, aqui está o que eu estou procurando normalmente:

• Configuração fácil (vou me contentar com configuração difícil, mas fácil de expandir)
• Failover simplista
• Trazer um nó caído de volta requer apenas tempo (isto é, como o mysql. O servidor fica inativo, você o atualiza e espera que a replicação seja atualizada)
• Alterações no esquema não interrompem a replicação
• Adicionar um novo banco de dados ao servidor é simples (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 propaga automaticamente para o escravo)

O MySQL lida com a maioria deles bastante bem, mas eu tenho uma certa predileção 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 em relação à sua solução? Este não é um post do MySQL versus PostgreSQL, eu prometo, porque não é isso que eu estou tentando começar. :)

    

Answer 1

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

Existem dois grandes projetos de desenvolvimento atualmente em andamento nesta área que estão incluídos no PostgreSQL 9.0 (Spring / Summer 2010), a saber:

• Replicação síncrona:

link

• Ler somente escravos em espera ativa:

link

que, combinados, visam alcançar a facilidade de uso da replicação no estilo MySQL menos os erros / 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:

link

As soluções de replicação do PostgreSQL até hoje, com a maior base de usuários, são Slony-I (mais caras para gravações, tornam as mudanças de esquema complicadas), WAL shipping / walmgr (Slaves não podem ser usados on-line) e pgQ / londiste do Skype / Skytools (mais ferramentas / blocos de construção do que uma solução finalizada).

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

link para mais informações.

    

Answer 2

E para jogar outra solução no anel: rubyrep.

Para comparar com seus requisitos:

• Configuração fácil
  Sim, esse é o foco principal do rubyrep.
• Failover simplista
  Sim. De fato, o rubyrep faz replicação master-master - para failover, nenhuma ação é necessária. Basta começar a usar o outro banco de dados.
• Alterações no esquema não interrompem a replicação
  Sim.
  Para alterações de chave não primária, a replicação nem precisa parar (mas verifique se o esquema é alterado em ambos os lados ao mesmo tempo)
  Para adicionar / remover tabelas, simplesmente reinicie o daemon de replicação. Apenas alterar a coluna de chave primária de uma tabela exige um pouco de esforço.
• Adicionar um novo banco de dados ao servidor é perfeito (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 propaga automaticamente para o escravo)
  Isso é suportado apenas de forma limitada: cada configuração do rubyrep replica apenas um banco de dados por vez. (Mas é muito fácil configurar a replicação para mais de um banco de dados.)

Answer 3

Você não mencionou ter um escravo de leitura como requisito, então vou propor o uso de Heartbeat com armazenamento compartilhado ou DRBD. Apenas faz a coisa certa e a administração é uma brisa. É o equivalente em Linux do clustering antigo do Microsoft SQL Server. Um nó está ativo e o outro nó é passivo, enquanto os dados são compartilhados entre os dois. Você não precisa se preocupar com a replicação baseada em SQL, porque ela é manipulada 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, na melhor das hipóteses, falso e você deve configurar tudo novamente se algum dia você interromper o processo de envio para uma reinicialização do servidor. slony e londiste não corte a mostarda. Se você quiser ficar na árvore principal e não for comercial, o Heartbeat é sua melhor aposta.

    

Answer 4

De suas exigências, 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, então o PITR pode estar certo.

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

Se você achar instruções muito detalhadas, dê uma olhada no SkyTools WalMgr que fará o processo de criação / failover para a tarefa de comando único de dados do hot-standby.

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

    

Answer 5

Se você quiser replicação mestra / escrava assíncrona, 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, replicação apenas "alcança".

O failover não está incorporado. Você precisará alterar as strings de conexão do aplicativo ou ofuscar a conexão do BD por trás de outra camada de software.

Algumas alterações no esquema são fáceis. Outros são mais difíceis. Depende do seu aplicativo. A próxima versão do skytools (ver 3.0) deve lidar com DDL e incluir recursos para tornar o failover mais fácil.

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

    

Answer 6

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

link

e

Concorrentes do Bucardo Versão 1, encontrado mais abaixo na página:

link

    

Answer 7

Realmente não existem formas gratuitas / de código aberto para fornecer o que você está procurando. Se você quer algo que é tão pronto, veja várias soluções de replicação comercial de terceiros.

Agora, é possível classificar sua própria replicação com o Postgres usando o envio do log de cabeçalho de gravação (WAL):

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

É basicamente onde você pode colocar um nó secundário no modo de recuperação contínua e importar logs de transação para ele a cada {pequeno intervalo}. A configuração do Postgres tem "stubs" para permitir que você faça certas coisas quando um Postgres quando um WAL é concluído e, portanto, não, e é sobre isso que a configuração é baseada - utilizando esses "stubs".

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

Em qualquer caso, ele definitivamente funciona para o descaso, mas eu não o chamaria de "configuração fácil", "failover simplista", "sem costura" ou qualquer coisa assim.

    

Answer 8

Com exceção da opção "adicionando um novo banco de dados", você pode experimentar o Mammoth Replicator ( link ). É 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.

    

Answer 9

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

    

Answer 10

Atualmente estou vendo o replicador da Tungsten, mas ainda estou longe de qualquer conclusão definitiva, mas provavelmente vale a pena dar uma olhada.

www.continuent.com