Eu me considero um pouco explorador. Em certas coisas que é. Normalmente, sempre peço a mesma comida de um restaurante familiar, pois o medo da decepção supera minha apreensão de experimentar algo novo.
E, claro, um humano faminto tende a comer, certo?
No entanto, quando se trata de tecnologia, em particular SQL (PostgreSQL), costumo tropeçar a toda velocidade (minha definição de exploração) em áreas muitas vezes desconhecidas, com a esperança de aprender. Que melhor maneira de aprender do que a experiência?
Então, o que diabos essa divagação tem a ver com a replicação lógica e de streaming no PostgreSQL?
Eu sou um novato completo nestas áreas com conhecimento zero. Sim, tenho tanto conhecimento nesta área do Postgres quanto em astrofísica.
Eu mencionei que eu tinha zero conhecimento?
Portanto, nesta postagem do blog, tentarei digerir as diferenças nesses tipos de replicação. Sem experiência prática no mundo real, não posso prometer a você o 'Seja tudo em tudo ' manuscrito para replicação.
Provavelmente, outros menos versados nesta área específica (como eu) se beneficiariam com esta postagem no blog.
Usuários e desenvolvedores experientes junto para o passeio, espero vê-lo nos comentários abaixo.
Algumas definições básicas
No sentido amplo do termo, o que significa Replicação?
A replicação, conforme definido no Wikcionário, diz o seguinte:
"Processo pelo qual um objeto, pessoa, lugar ou ideia pode ser copiado, imitado ou reproduzido."
No entanto, o 5º item listado é mais aplicável a esta postagem do blog e acho que devemos analisá-lo também:
"(computação) O processo de copiar dados eletrônicos freqüentes de um banco de dados em um computador ou servidor para um banco de dados em outro para que todos os usuários compartilhem o mesmo nível de informação. Usado para melhorar a tolerância a falhas do sistema."
Agora há algo em que podemos entrar. A menção de copiar dados de um servidor ou banco de dados para outro? Estamos em território familiar agora...
Então, adicionando o que sabemos dessa definição, quais são as definições de Replicação de Streaming e Replicação Lógica?
Vamos ver o que o PostgreSQL Wiki tem a oferecer:
Replicação de streaming:"fornece a capacidade de enviar e aplicar continuamente os registros WAL XLOG a alguns servidores em espera para mantê-los atualizados.
E a Documentação do PostgreSQL tem esta definição para Replicação Lógica:
"Replicação lógica é um método de replicação de objetos de dados e suas alterações, com base em sua identidade de replicação (geralmente uma chave primária). Usamos o termo lógica em contraste com a replicação física, que usa endereços de bloco exatos e replicação byte a byte. "
Capítulo 19.6 A replicação da documentação oficial também está repleta de guloseimas, então não deixe de visitar essa fonte.
Abaixo, tentarei retransmitir as diferenças em termos leigos. (Lembre-se, se eu tropeçar, sou um novato.) Esta é uma visão geral extrema de 'alto nível'.
Replicação lógica
Um banco de dados "fonte" cria uma PUBLICATION usando o comando CREATE PUBLICATION. (Penso nisso em termos simples como o 'remetente'.)
A documentação o define como o editor.
Este banco de dados do editor tem os dados que queremos replicar. No entanto, devemos ter algo para replicar e é aí que entram as contrapartes da editora. O 'assinante'. Observe que coloquei uma forma plural alternativa porque, pelo que encontrei em pesquisas on-line, é uma configuração prática ter vários assinantes.
Um 'assinante' (também pode ser considerado como o banco de dados de réplica) cria uma ASSINATURA para um banco de dados de "fonte" (editor) definindo informações de conexão e quaisquer publicações que ele assina.
É possível que um assinante seja também um editor, criando sua própria PUBLICAÇÃO que outros assinantes podem assinar.
O que acontece agora?
Quaisquer alterações de dados que ocorram no editor são enviadas ao assinante. Que fora da caixa, é tudo, mas pode ser configurado ou limitado a certas operações (ou seja, INSERT, UPDATE ou DELETE).
Exemplo de alto nível:
Suponha que atualizamos uma linha ou várias linhas em uma tabela específica no editor, essas atualizações e alterações são replicadas na instância do assinante ou em vários assinantes se esse tipo de configuração for implementado.
Aqui estão algumas coisas para lembrar que me senti digno de mencionar:
- A configuração wal_level do banco de dados do editor deve ser definida como lógica.
- A replicação lógica não tem nenhum comando DDL (Data Definition Language).
- Na página Conflitos da documentação:"A replicação lógica se comporta de maneira semelhante às operações DML normais, pois os dados serão atualizados mesmo que tenham sido alterados localmente no nó do assinante. Se os dados recebidos violarem alguma restrição, a replicação será interrompida. Isso é referido como um conflito. Ao replicar as operações UPDATE ou DELETE, os dados ausentes não produzirão um conflito e tais operações serão simplesmente ignoradas."
- As tabelas do editor devem ter uma maneira de se identificar (chamada "identidade da réplica") para replicar corretamente as operações DML (UPDATE e DELETE) em qualquer réplica para essas linhas afetadas. Se a tabela tiver uma chave primária, este é o padrão (me parece a melhor escolha), mas na ausência de uma chave primária, outras opções de configuração estão disponíveis. A linha inteira pode ser usada se nenhuma outra chave candidata existir (denominada "completa"), embora a documentação mencione que isso normalmente não é uma solução eficiente. (Consulte a seção REPLICA IDENTITY nos documentos para obter uma descrição de nível inferior de como defini-la)
Restrições
A documentação na seção 31.4. Restrições tem alguns lembretes importantes sobre restrições que vou encobrir. Certifique-se e revise a página vinculada acima para verbiagem exata.
- O esquema de banco de dados e quaisquer comandos DDL não são suportados na replicação. Sugere-se que talvez o pg_dump possa ser usado inicialmente, mas ainda assim, você mesmo precisaria atualizar quaisquer outras alterações e avanços no esquema para todas as réplicas.
- Os dados nas colunas de sequência serão replicados. Mas, a própria sequência refletiria apenas o valor inicial. Para leituras, tudo bem. Mas se este for o seu destino para failover, você precisará ATUALIZAR para o valor atual por conta própria. Os documentos sugerem pg_dump aqui.
- Truncar ainda não é compatível.
- A replicação de objetos grandes não é compatível.
- Visualizações, visualizações materializadas, tabelas raiz de partição ou tabelas estrangeiras não são suportadas nem pelo editor nem pelo assinante.
Casos de uso comuns relatados
- Você está interessado apenas em determinados dados e alterações de dados que você realmente replica, em vez de apenas replicar todo o banco de dados.
- Quando você precisa de réplicas para operações somente leitura, como um cenário de análise.
- Permitir que usuários ou diferentes subconjuntos de usuários tenham acesso limitado ou monitorado aos dados.
- Distribuindo dados.
- Compatibilidade com outras versões do PostgreSQL.
Replicação de streaming
Ao pesquisar, ler e estudar a Replicação de Streaming, uma coisa que percebi logo de início é escolher configurar a replicação assíncrona (o padrão) ou síncrona.
Ah, termos mais desconhecidos, hein?
Aqui está minha definição de 'alto nível' de ambos:
Com a replicação assíncrona, depois que uma transação é confirmada no primário, há um pequeno atraso quando essa mesma transação é confirmada e gravada na réplica. Existe potencial para perda de dados com este tipo de configuração.
- Primeiro, suponha que o mestre falhe.
- Dois, a(s) réplica(s) está(ão) tão atrasada(s) em relação ao mestre, que descartou os dados e informações necessários para que a(s) réplica(s) sejam 'atuais'.
No entanto, na replicação síncrona, nenhuma transação é considerada completa, até que seja confirmada pelo(s) servidor(es) mestre e de réplica. Que terá escrito um commit no WAL de ambos os servidores.
Em termos que eu entendo, isso significa que as gravações no mestre também foram confirmadas e gravadas na réplica.
Aqui está a explicação oficial da seção 26.2.8. Replicação Síncrona na documentação oficial:
“Ao solicitar a replicação síncrona, cada confirmação de uma transação de gravação aguardará até que seja recebida a confirmação de que a confirmação foi gravada no log de gravação antecipada no disco do servidor primário e de espera. “
Outra passagem da documentação tem um bom resumo do que deve ser (na minha opinião), um grande benefício:"A única possibilidade de perda de dados é se tanto o primário quanto o de espera sofrerem travamentos ao mesmo tempo."
Embora nada seja impossível, isso ainda é uma boa garantia de que você não ficará sem cópia de seus dados.
Ok, sabemos que temos que escolher uma dessas configurações de configuração, mas qual é a essência geral?
Em poucas palavras, o Streaming Replication envia e aplica arquivos WAL (Write Ahead Log) de um servidor de banco de dados (o mestre ou primário) para uma 'réplica' (banco de dados de recebimento).
Mas há uma ressalva aqui para manter em mente. Potencialmente, os arquivos WAL do mestre podem ser reciclados antes que o standy os obtenha. Uma maneira de atenuar isso é aumentar a configuração wal_keep_segments para um valor mais alto.
Pontos na replicação de streaming
Recursos relacionados ClusterControl for PostgreSQL PostgreSQL Streaming Replication - aprofundamento Guia do especialista para Slony Replication for PostgreSQL- Por padrão, a replicação de streaming é assíncrona, o que significa que há um atraso (talvez pequeno) entre as transações confirmadas no mestre e sua visibilidade na réplica.
- As réplicas se conectam ao mestre por meio de uma conexão de rede.
- Lembre-se da autenticação. Veja aqui na documentação:"É muito importante que os privilégios de acesso para replicação sejam configurados para que apenas usuários confiáveis possam ler o fluxo WAL porque é fácil extrair informações privilegiadas dele"
Quando usar a replicação de streaming
- Um uso comum (especialmente em análises) fornece uma réplica "somente leitura" para aliviar a carga do servidor principal.
- Você precisa de um ambiente de alta disponibilidade.
- Configuração útil para failover para servidor de espera ativa caso o primário fique inativo.
