Como a replicação nativa do PostgreSQL se compara ao MySQL?
Sei que a replicação assíncrona tem suporte há mais tempo do que a sincronização, que é recente. O síncrono é confiável para ser usado em projetos reais?
AskOverflow.Dev
Como a replicação nativa do PostgreSQL se compara ao MySQL?
Sei que a replicação assíncrona tem suporte há mais tempo do que a sincronização, que é recente. O síncrono é confiável para ser usado em projetos reais?
Produção pronta?
Sim, está pronto para produção e é amplamente utilizado. Os seguidores do Heroku são baseados na replicação assíncrona integrada do PostgreSQL, por exemplo, assim como os standbys do AWS RDS e as réplicas de leitura. A replicação de streaming é usada quase universalmente com o PostgreSQL.
A configuração da replicação não é exatamente adorável, mas ferramentas como repmgr ajudam um pouco nisso e estão melhorando lentamente a cada versão principal. A capacidade do pg_basebackup de fazer uma cópia do sistema usando a replicação de streaming (e fazê-lo de outro modo de espera) é uma grande ajuda.
Em geral, um recurso simplesmente não será lançado no PostgreSQL até que esteja pronto para produção. Bugs acontecem, como em qualquer software, mas normalmente são corrigidos logo após serem identificados. Novos recursos realmente importantes às vezes têm bugs e problemas descobertos após o lançamento do .0, mas, nesse caso, corrigi-los é uma alta prioridade; os bugs não são apenas deixados por aí.
Não tenho conhecimento de nenhum problema sério com a replicação de streaming - sincronizado ou assíncrono - nem vi nenhum relatado por um bom tempo. Eles eram menos estáveis do que o padrão usual do Pg nos lançamentos .0 das versões principais em que foram introduzidos, mas ambos amadureceram rapidamente e estão completamente prontos para produção.
(Atualização: havia um bug específico na nova versão 9.3 anterior à 9.3.4 que causava problemas de replicação em alguns casos; os usuários da versão 9.3 devem atualizar para a versão 9.3.4 imediatamente. As versões mais antigas não são afetadas.)
A única ressalva que quero mencionar é um pequeno detalhe com a replicação síncrona: se você confirmar no mestre, cancele a consulta após a confirmação enquanto aguarda a confirmação da réplica, ela é tratada como confirmada no mestre antes mesmo de ser replicada. Você obtém o mesmo efeito reiniciando o mestre enquanto aguarda a resposta da réplica. Na prática, isso é irrelevante, mas é o único problema em que consigo pensar.
Comparar com o MySQL?
A replicação nativa do Pg é bem diferente da do MySQL.
O MySQL usa replicação lógica onde envia as alterações lógicas feitas nos dados da tabela, estrutura da tabela, etc, e a réplica aplica essas alterações.
A replicação do PostgreSQL é de nível inferior (em 9.5 e abaixo; versões futuras também podem adicionar replicação lógica). Envia os blocos que mudaram nas tabelas. É mais simples, mais fácil de acertar e impõe uma carga menor no servidor de réplica, mas consome mais largura de banda da rede e requer mais armazenamento no mestre para manter as alterações ainda não replicadas. É melhor configurado para usar replicação de streaming com fallback de arquivamento WAL, tornando-o mais complexo de configurar do que o do MySQL. Ele replica alterações de baixo nível, como atividade VACUUM, não apenas alterações de tupla, mantendo o estado em disco da réplica igual ao do mestre. Ele é incapaz de replicar apenas um banco de dados; todo o sistema deve ser replicado, o que pode ser frustrante se você tiver um banco de dados grande, de alta rotatividade e sem importância e um banco de dados pequeno, de baixa rotatividade e vital.
Em suma, depende do que você quer fazer com ele.
Vejo a replicação do PostgreSQL consideravelmente melhor para réplicas usadas para backup, alta disponibilidade e recuperação de desastres. Particularmente quando combinado com recuperação pontual (PITR) .
Por outro lado, não é tão bom para réplicas de relatório somente leitura porque a necessidade de atrasar a aplicação de dados replicados durante a execução de transações longas significa que você precisa permitir que ele cancele consultas de execução muito longa ou fique muito atrás do mestre, consumindo mais espaço em disco no mestre e forçando-o a trabalhar mais para acompanhar.
Há um trabalho contínuo para habilitar a replicação lógica no PostgreSQL , onde as alterações lógicas na estrutura da tabela, conteúdo da tabela etc. são replicadas, em vez de seu estado no disco. O design do catálogo do Pg e o suporte para tudo definido pelo usuário tornam essa tarefa bastante complexa. Algumas das bases foram implementadas para 9.4, mas é improvável que a replicação lógica completa seja utilizável antes de 9.6 ou posterior.