PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Diferença entre replicação de fluxo e replicação lógica


TL;DR :A replicação lógica envia alterações linha por linha, a replicação física envia alterações de bloco de disco. A replicação lógica é melhor para algumas tarefas, a replicação física para outras.

Observe que no PostgreSQL 12 (atual no momento da atualização) a replicação lógica é estável e confiável, mas bastante limitada. Use a replicação física se estiver fazendo essa pergunta.

A replicação de streaming pode ser replicação lógica. É tudo um pouco complicado.

Envio WAL x streaming


Existem duas maneiras principais de enviar dados do mestre para a réplica no PostgreSQL:

  • Envio WAL ou arquivamento contínuo , onde arquivos de log de gravação antecipada individuais são copiados de pg_xlog pelo archive_command executando no mestre para algum outro local. Um restore_command configurado no recovery.conf da réplica é executado na réplica para buscar os arquivos para que a réplica possa reproduzir o WAL.

    Isso é o que é usado para replicação pontual (PITR), que é usado como método de backup contínuo.

    Nenhuma conexão de rede direta é necessária para o servidor mestre. A replicação pode ter longos atrasos, especialmente sem um archive_timeout definir. O envio WAL não pode ser usado para replicação síncrona.

  • replicação de streaming , em que cada alteração é enviada para um ou mais servidores de réplica diretamente por meio de uma conexão TCP/IP à medida que ocorre. As réplicas devem ter uma conexão de rede direta com o mestre configurado em seu recovery.conf 's primary_conninfo opção.

    A replicação de streaming tem pouco ou nenhum atraso, desde que a réplica seja rápida o suficiente para acompanhar. Ele pode ser usado para replicação síncrona . Você não pode usar a replicação de streaming para PITR, portanto, não é muito útil para backup contínuo. Se você soltar uma tabela no mestre, opa, ela também cairá nas réplicas.

Assim, os dois métodos têm finalidades diferentes.

Streaming assíncrono x síncrono


Além disso, há síncrono e assíncrono replicação de streaming:

  • Na replicação de streaming assíncrona a(s) réplica(s) pode(m) ficar atrás do mestre no momento em que o mestre estiver mais rápido/mais ocupado. Se o mestre travar, você poderá perder dados que ainda não foram replicados.

    Se a réplica assíncrona ficar muito atrás do mestre, o mestre poderá descartar as informações de que a réplica precisa se max_wal_size (antes era chamado de wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's do mestre pg_wal(was pg_xlog) pode encher e impedir que o master funcione até que o espaço em disco seja liberado se max_wal_size está muito alto ou um slot é usado.

  • Na replicação síncrona o mestre não termina de confirmar até que uma réplica tenha confirmado que recebeu a transação. Você nunca perde dados se o mestre trava e você precisa fazer failover para uma réplica. O mestre nunca jogará fora os dados que a réplica precisa ou preencherá seu xlog e ficará sem espaço em disco devido a atrasos na réplica. Em troca, pode fazer com que o mestre fique lento ou até pare de funcionar se as réplicas tiverem problemas, e sempre tem algum impacto no desempenho do mestre devido à latência da rede.

    Quando há várias réplicas, apenas uma é síncrona por vez. Consulte synchronous_standby_names .

Você não pode ter envio de log síncrono.

Na verdade, você pode combinar o envio de logs e a replicação assíncrona para se proteger contra a necessidade de recriar uma réplica se ela ficar muito atrasada, sem correr o risco de afetar o mestre. Essa é uma configuração ideal para muitas implantações, combinada com o monitoramento de até que ponto a réplica está atrás do mestre para garantir que esteja dentro dos limites aceitáveis ​​de recuperação de desastres.

Lógico x físico


Além de isso temos lógico vs físico replicação de streaming, conforme introduzido no PostgreSQL 9.4:

  • Na replicação de streaming físico as alterações são enviadas quase no nível do bloco do disco, como "no deslocamento 14 da página 18 do disco da relação 12311, escreveu tupla com valor hexadecimal 0x2342beef1222....".

    A replicação física envia tudo :o conteúdo de cada banco de dados na instalação do PostgreSQL, todas as tabelas em cada banco de dados. Ele envia entradas de índice, ele envia todos os novos dados da tabela quando você VACUUM FULL , ele envia dados para transações que foram revertidas, etc. Então ele gera muito "ruído" e envia muitos dados em excesso. Ele também exige que a réplica seja completamente idêntica, portanto, você não pode fazer nada que exija uma transação, como criar tabelas temporárias ou não registradas. Consultar a réplica atrasa a replicação, portanto, consultas longas na réplica precisam ser canceladas.

Em troca, é simples e eficiente aplicar as alterações na réplica, e a réplica é exatamente igual ao mestre. O DDL é replicado de forma transparente, assim como todo o resto, portanto, não requer tratamento especial. Ele também pode transmitir grandes transações à medida que elas acontecem, portanto, há pouco atraso entre a confirmação no mestre e a confirmação na réplica, mesmo para grandes alterações.

A replicação física é madura, bem testada e amplamente adotada.
  • replicação de streaming lógico , novo na versão 9.4, envia alterações em um nível mais alto e muito mais seletivo.

Ele replica apenas um banco de dados por vez. Ele envia apenas alterações de linha e apenas para transações confirmadas, e não precisa enviar dados vazios, alterações de índice etc. Ele pode enviar dados seletivamente apenas para algumas tabelas em um banco de dados. Isso torna a replicação lógica muito mais eficiente em largura de banda.

Operar em um nível mais alto também significa que você pode fazer transações nos bancos de dados de réplica. Você pode criar tabelas temporárias e não registradas. Mesmo mesas normais, se você quiser. Você pode usar wrappers de dados estrangeiros, visualizações, criar funções, o que quiser. Também não há necessidade de cancelar consultas se elas forem muito longas.

A replicação lógica também pode ser usada para construir a replicação multimestre no PostgreSQL, o que não é possível usando a replicação física.

Em troca, porém, ele não pode (atualmente) transmitir grandes transações à medida que elas acontecem. Tem que esperar até que eles se comprometam. Portanto, pode haver um longo atraso entre a confirmação de uma grande transação no mestre e a aplicação na réplica.

Ele reproduz as transações estritamente na ordem de confirmação, portanto, pequenas transações rápidas podem ficar presas atrás de uma grande transação e atrasar bastante.

DDL não é tratado automaticamente. Você mesmo precisa manter as definições de tabela sincronizadas entre o mestre e a réplica, ou o aplicativo que usa a replicação lógica precisa ter seus próprios recursos para fazer isso. Pode ser complicado acertar isso.

O processo de aplicação em si é mais complicado do que "escrever alguns bytes onde me disseram" também. Também são necessários mais recursos na réplica do que a replicação física.

As implementações de replicação lógica atuais não são maduras ou amplamente adotadas, ou particularmente fáceis de usar.

Muitas opções, diga-me o que fazer


Ufa. Complicado, né? E eu nem entrei nos detalhes de replicação atrasada, slots, max_wal_size , cronogramas, como funciona a promoção, Postgres-XL, BDR e multimaster, etc.

Então, o que você deve fazer ?

Não existe uma única resposta certa. Caso contrário, o PostgreSQL só suportaria isso de uma maneira. Mas existem alguns casos de uso comuns:

Para backup e recuperação de desastres use pgbarman para fazer backups básicos e reter o WAL para você, fornecendo backup contínuo fácil de gerenciar. Você ainda deve fazer o pg_dump periódico backups como seguro extra.

Para alta disponibilidade com risco zero de perda de dados use a replicação síncrona de streaming.

Para alta disponibilidade com baixo risco de perda de dados e melhor desempenho você deve usar a replicação de streaming assíncrona. Tenha o arquivamento WAL habilitado para fallback ou use um slot de replicação. Monitore até que ponto a réplica está atrás do mestre usando ferramentas externas como Icinga.

Referências