A configura\u00e7\u00e3o da replica\u00e7\u00e3o entre duas bases de dados oferece toler\u00e2ncia a falhas contra contratempos inesperados. \u00c9 considerada a melhor estrat\u00e9gia para se atingir alta disponibilidade durante desastres.<\/p>\n
Neste artigo, vamos mergulhar nas diferentes estrat\u00e9gias que podem ser implementadas pelos desenvolvedores backend<\/a> para a replica\u00e7\u00e3o sem problemas do PostgreSQL.<\/p>\n A replica\u00e7\u00e3o PostgreSQL \u00e9 definida como o processo de c\u00f3pia de dados de um servidor de banco de dados PostgreSQL<\/a> para outro servidor. O servidor de banco de dados de origem tamb\u00e9m \u00e9 conhecido como servidor “prim\u00e1rio”, enquanto o servidor de banco de dados que recebe os dados copiados \u00e9 conhecido como servidor “r\u00e9plica”.<\/p>\n O banco de dados PostgreSQL segue um modelo de replica\u00e7\u00e3o simples, onde todas as escritas v\u00e3o para um node prim\u00e1rio. O node prim\u00e1rio pode ent\u00e3o aplicar estas mudan\u00e7as e transmiti-las para o node secund\u00e1rio.<\/p>\n Failover \u00e9 um m\u00e9todo para recuperar dados se o servidor prim\u00e1rio ceder<\/a> por qualquer raz\u00e3o. Desde que voc\u00ea tenha configurado o PostreSQL para gerenciar sua replica\u00e7\u00e3o f\u00edsica de streaming, voc\u00ea – e seus usu\u00e1rios – estar\u00e3o protegidos do tempo de inatividade devido a um snafu do servidor prim\u00e1rio.<\/p>\n Note que o processo de failover pode levar algum tempo para ser configurado e iniciado. N\u00e3o h\u00e1 ferramentas integradas para monitorar e escanear falhas de servidor no PostgreSQL, ent\u00e3o voc\u00ea precisar\u00e1 ser criativo.<\/p>\n Felizmente, voc\u00ea n\u00e3o precisa ser dependente do PostgreSQL para o failover. Existem ferramentas dedicadas que permitem o failover autom\u00e1tico e a comuta\u00e7\u00e3o autom\u00e1tica para o modo standby, reduzindo o tempo de inatividade do banco de dados<\/a>.<\/p>\n Ao configurar a replica\u00e7\u00e3o de failover, voc\u00ea garante uma alta disponibilidade, garantindo que os standbys estejam dispon\u00edveis se o servidor prim\u00e1rio algum dia falhar.<\/p>\n Aqui est\u00e3o alguns dos principais benef\u00edcios de alavancar a replica\u00e7\u00e3o do PostgreSQL:<\/p>\n Em geral, as pessoas acreditam que quando voc\u00ea est\u00e1 se envolvendo com uma arquitetura prim\u00e1ria e secund\u00e1ria, s\u00f3 h\u00e1 uma maneira de configurar backups<\/a> e replica\u00e7\u00e3o. As implementa\u00e7\u00f5es do PostgreSQL, no entanto, podem seguir qualquer um desses tr\u00eas m\u00e9todos<\/a>:<\/p>\n A replica\u00e7\u00e3o do PostgreSQL tamb\u00e9m conhecida como replica\u00e7\u00e3o WAL pode ser configurada perfeitamente ap\u00f3s a instala\u00e7\u00e3o do PostgreSQL em todos os servidores. Esta abordagem de replica\u00e7\u00e3o \u00e9 baseada em mover os arquivos WAL do banco de dados prim\u00e1rio para o banco de dados alvo.<\/p>\n Voc\u00ea pode implementar a replica\u00e7\u00e3o do PostgreSQL atrav\u00e9s de uma configura\u00e7\u00e3o prim\u00e1ria secund\u00e1ria. O servidor prim\u00e1rio \u00e9 a inst\u00e2ncia principal que lida com o banco de dados prim\u00e1rio e todas as suas opera\u00e7\u00f5es. O servidor secund\u00e1rio atua como inst\u00e2ncia suplementar e executa todas as mudan\u00e7as feitas no banco de dados prim\u00e1rio em si mesmo, gerando uma c\u00f3pia id\u00eantica no processo. O servidor prim\u00e1rio \u00e9 o servidor de leitura\/grava\u00e7\u00e3o enquanto o servidor secund\u00e1rio \u00e9 meramente de leitura.<\/p>\n Para este m\u00e9todo, voc\u00ea precisa configurar tanto o node prim\u00e1rio quanto o node de espera. As se\u00e7\u00f5es seguintes ir\u00e3o elucidar os passos envolvidos na configura\u00e7\u00e3o deles com facilidade.<\/p>\n Voc\u00ea pode configurar o node prim\u00e1rio para replica\u00e7\u00e3o de streaming, executando os seguintes passos:<\/p>\n Para inicializar o banco de dados<\/strong>, voc\u00ea pode utilizar o comando utilit\u00e1rio O usu\u00e1rio ter\u00e1 que fornecer uma senha e um nome de usu\u00e1rio para a consulta em quest\u00e3o. A palavra-chave de replica\u00e7\u00e3o \u00e9 usada para dar ao usu\u00e1rio os privil\u00e9gios necess\u00e1rios. Um exemplo de consulta seria algo parecido com isto:<\/p>\n A seguir, voc\u00ea pode configurar as propriedades de streaming com o arquivo de configura\u00e7\u00e3o do PostgreSQL (postgresql.conf<\/strong>) que pode ser modificado da seguinte forma:<\/p>\n Aqui est\u00e1 um pequeno fundo em torno dos par\u00e2metros usados no trecho anterior:<\/p>\n Ap\u00f3s voc\u00ea ter modificado os par\u00e2metros no arquivo postgresql.conf<\/strong>, uma nova entrada de replica\u00e7\u00e3o no arquivo pg_hba.conf<\/strong> pode permitir que os servidores estabele\u00e7am uma conex\u00e3o uns com os outros para replica\u00e7\u00e3o.<\/p>\n Voc\u00ea geralmente pode encontrar este arquivo no diret\u00f3rio de dados do PostgreSQL. Voc\u00ea pode usar o seguinte trecho de c\u00f3digo para o mesmo:<\/p>\n Uma vez que o trecho de c\u00f3digo \u00e9 executado, o servidor prim\u00e1rio permite que um usu\u00e1rio chamado Para configurar o node de espera para replica\u00e7\u00e3o de streaming, siga estes passos:<\/p>\n Para configurar o node de espera, utilize o utilit\u00e1rio Os par\u00e2metros usados na sintaxe mencionada acima s\u00e3o os seguintes:<\/p>\n A seguir, voc\u00ea precisa verificar se o arquivo de configura\u00e7\u00e3o da replica\u00e7\u00e3o existe. Se n\u00e3o existir, voc\u00ea pode gerar o arquivo de configura\u00e7\u00e3o de replica\u00e7\u00e3o como recovery.conf<\/strong>.<\/p>\n Voc\u00ea deve criar este arquivo no diret\u00f3rio de dados da instala\u00e7\u00e3o do PostgreSQL. Voc\u00ea pode ger\u00e1-lo automaticamente usando a op\u00e7\u00e3o O arquivo recovery.conf<\/strong> deve conter os seguintes comandos:<\/p>\n Os par\u00e2metros usados nos comandos acima s\u00e3o os seguintes:<\/p>\n Para configurar uma conex\u00e3o, voc\u00ea precisa fornecer o nome de usu\u00e1rio, endere\u00e7o IP e senha como valores para o par\u00e2metro primary_conninfo. Por exemplo:<\/p>\n Finalmente, voc\u00ea pode reiniciar o servidor secund\u00e1rio para completar o processo de configura\u00e7\u00e3o.<\/p>\n No entanto, a replica\u00e7\u00e3o do streaming vem com v\u00e1rios desafios, como por exemplo:<\/p>\n O m\u00e9todo do dispositivo de bloco replicado depende do espelhamento de disco (tamb\u00e9m conhecido como replica\u00e7\u00e3o de volume). Nesta abordagem, as mudan\u00e7as s\u00e3o escritas em um volume persistente que \u00e9 espelhado de forma s\u00edncrona em outro volume.<\/p>\n O benef\u00edcio adicional deste m\u00e9todo \u00e9 sua compatibilidade e durabilidade de dados em ambientes de nuvem com todos os bancos de dados relacionais, incluindo PostgreSQL, MySQL, e SQL Server<\/a>, para citar alguns.<\/p>\n Entretanto, a abordagem de espelhamento em disco da replica\u00e7\u00e3o do PostgreSQL precisa que voc\u00ea replique tanto o log WAL quanto os dados da tabela. J\u00e1 que cada um escreve no banco de dados agora precisa passar pela rede de forma s\u00edncrona, voc\u00ea n\u00e3o pode se dar ao luxo de perder um \u00fanico byte, pois isso poderia deixar seu banco de dados em um estado corrupto.<\/p>\n Este m\u00e9todo \u00e9 normalmente alavancada usando o Azure PostgreSQL e o Amazon RDS.<\/p>\n WAL consiste de arquivos de segmento (16 MB por padr\u00e3o). Cada segmento tem um ou mais registros. Um log sequence record (LSN) \u00e9 um ponteiro para um registro no WAL, deixando voc\u00ea saber a posi\u00e7\u00e3o\/localiza\u00e7\u00e3o onde o registro foi salvo no arquivo de registro.<\/p>\n Um servidor standby utiliza segmentos WAL – tamb\u00e9m conhecido como XLOGS na terminologia do PostgreSQL – para replicar continuamente as mudan\u00e7as de seu servidor prim\u00e1rio. Voc\u00ea pode usar o registro write-ahead para garantir durabilidade e atomicidade em um SGBD atrav\u00e9s da serializa\u00e7\u00e3o de peda\u00e7os de dados de byte-array (cada um com um LSN \u00fanico) para armazenamento est\u00e1vel antes que eles sejam aplicados a um banco de dados.<\/p>\n A aplica\u00e7\u00e3o de uma muta\u00e7\u00e3o em um banco de dados pode levar a v\u00e1rias opera\u00e7\u00f5es de sistema de arquivos. Uma quest\u00e3o pertinente que surge \u00e9 como um banco de dados pode assegurar atomicidade no caso de uma falha no servidor devido a uma queda de energia enquanto ele est\u00e1 no meio de uma atualiza\u00e7\u00e3o do sistema de arquivos. Quando um banco de dados inicia, ele inicia um processo de inicializa\u00e7\u00e3o ou replay que pode ler os segmentos WAL dispon\u00edveis e os compara com o LSN armazenado em cada p\u00e1gina de dados (cada p\u00e1gina de dados \u00e9 marcada com o LSN do \u00faltimo registro WAL que afeta a p\u00e1gina).<\/p>\n A replica\u00e7\u00e3o em fluxo refina o processo de envio de log. Ao contr\u00e1rio de esperar pela chave WAL, os registros s\u00e3o enviados \u00e0 medida que s\u00e3o criados, diminuindo assim o atraso de replica\u00e7\u00e3o.<\/p>\n A replica\u00e7\u00e3o em fluxo cont\u00ednuo tamb\u00e9m supera o envio de logs porque o servidor standby se conecta com o servidor prim\u00e1rio atrav\u00e9s da rede, alavancando um protocolo de replica\u00e7\u00e3o. O servidor prim\u00e1rio pode ent\u00e3o enviar registros WAL diretamente sobre esta conex\u00e3o sem ter que depender de scripts fornecidos pelo usu\u00e1rio final.<\/p>\n O envio de logs \u00e9 definido como c\u00f3pia de arquivos de log para outro servidor PostgreSQL para gerar outro servidor standby atrav\u00e9s da reprodu\u00e7\u00e3o de arquivos WAL. Este servidor \u00e9 configurado para trabalhar em modo de recupera\u00e7\u00e3o, e seu \u00fanico prop\u00f3sito \u00e9 aplicar quaisquer novos arquivos WAL conforme eles aparecem.<\/p>\n Este servidor secund\u00e1rio ent\u00e3o se torna um backup quente do servidor prim\u00e1rio do PostgreSQL. Ele tamb\u00e9m pode ser configurado para ser uma r\u00e9plica lida, onde ele pode oferecer consultas somente leitura, tamb\u00e9m chamada de hot standby.<\/p>\n A duplica\u00e7\u00e3o de arquivos WAL como eles s\u00e3o criados em qualquer local que n\u00e3o seja o subdiret\u00f3rio O script pode aproveitar o comando Outras configura\u00e7\u00f5es baseadas em log incluem:<\/p>\n Um processo conhecido como receptor WAL, rodando no servidor standby, aproveita os detalhes da conex\u00e3o fornecidos no par\u00e2metro de recovery.conf<\/strong> Para iniciar a replica\u00e7\u00e3o do streaming, o frontend pode enviar o par\u00e2metro de replica\u00e7\u00e3o dentro da mensagem de inicializa\u00e7\u00e3o. Um valor booleano de verdadeiro, sim, 1, ou ON permite ao backend<\/a> saber que ele precisa entrar no modo walsender de replica\u00e7\u00e3o f\u00edsica.<\/p>\n O WAL sender \u00e9 outro processo que roda no servidor prim\u00e1rio e est\u00e1 encarregado de enviar os registros WAL para o servidor de espera \u00e0 medida que eles s\u00e3o gerados. O receptor WAL salva os registros WAL no WAL como se eles fossem criados pela atividade do cliente de clientes conectados localmente.<\/p>\n Assim que os registros WAL chegam aos arquivos do segmento WAL, o servidor de espera continua constantemente reproduzindo o WAL para que o prim\u00e1rio e o de espera estejam atualizados.<\/p>\n Nesta se\u00e7\u00e3o, voc\u00ea ter\u00e1 uma compreens\u00e3o mais profunda dos modelos comumente utilizados (replica\u00e7\u00e3o single-master e multi-master), tipos (replica\u00e7\u00e3o f\u00edsica e l\u00f3gica) e modos (s\u00edncrono e ass\u00edncrono) de replica\u00e7\u00e3o PostgreSQL.<\/p>\n Escalabilidade significa adicionar mais recursos\/ hardware aos nodes existentes para aumentar a capacidade do banco de dados de armazenar e processar mais dados que podem ser alcan\u00e7ados horizontal e verticalmente. A replica\u00e7\u00e3o do PostgreSQL \u00e9 um exemplo de escalabilidade horizontal que \u00e9 muito mais dif\u00edcil de implementar do que a escalabilidade vertical. N\u00f3s podemos alcan\u00e7ar escalabilidade horizontal principalmente pela replica\u00e7\u00e3o de um single-master (SMR) e replica\u00e7\u00e3o multi-master (MMR).<\/p>\n A replica\u00e7\u00e3o multi-master permite que os dados sejam modificados somente em um \u00fanico node, e estas modifica\u00e7\u00f5es s\u00e3o replicadas em um ou mais nodes. As tabelas replicadas no banco de dados de r\u00e9plicas n\u00e3o t\u00eam permiss\u00e3o para aceitar quaisquer altera\u00e7\u00f5es, exceto aquelas do servidor prim\u00e1rio. Mesmo que aceitem, as altera\u00e7\u00f5es n\u00e3o s\u00e3o replicadas de volta ao servidor prim\u00e1rio.<\/p>\n Na maioria das vezes, o SMR \u00e9 suficiente para a aplica\u00e7\u00e3o porque \u00e9 menos complicado de configurar e gerenciar, sem chances de conflitos. A replica\u00e7\u00e3o de um single-master tamb\u00e9m \u00e9 unidirecional, uma vez que os dados de replica\u00e7\u00e3o fluem em uma dire\u00e7\u00e3o principalmente, do banco de dados prim\u00e1rio para o banco de dados de r\u00e9plicas.<\/p>\n Em alguns casos, SMR sozinho pode n\u00e3o ser suficiente, e voc\u00ea pode precisar implementar MMR. O MMR permite que mais de um node aja como o node prim\u00e1rio. Mudan\u00e7as nas linhas da tabela em mais de um banco de dados prim\u00e1rio designado s\u00e3o replicadas para suas tabelas contrapartes em todos os outros bancos de dados prim\u00e1rios. Neste modelo, esquemas de resolu\u00e7\u00e3o de conflitos s\u00e3o frequentemente empregados para evitar problemas como duplica\u00e7\u00e3o de chaves prim\u00e1rias.<\/p>\n H\u00e1 algumas vantagens no uso do MMR, a saber:<\/p>\n Entretanto, o lado negativo da implementa\u00e7\u00e3o do MMR \u00e9 a complexidade e sua dificuldade para resolver conflitos.<\/p>\n V\u00e1rios ramos e aplica\u00e7\u00f5es fornecem solu\u00e7\u00f5es MMR, pois o PostgreSQL n\u00e3o o suporta nativamente. Estas solu\u00e7\u00f5es podem ser open-source<\/a>, gratuitas ou pagas. Uma dessas extens\u00f5es<\/a> \u00e9 a replica\u00e7\u00e3o bidirecional (BDR) que \u00e9 ass\u00edncrona e \u00e9 baseada na fun\u00e7\u00e3o de decodifica\u00e7\u00e3o l\u00f3gica do PostgreSQL.<\/p>\n Como a aplica\u00e7\u00e3o BDR reproduz transa\u00e7\u00f5es em outros nodes, a opera\u00e7\u00e3o de replay pode falhar se houver um conflito entre a transa\u00e7\u00e3o sendo aplicada e a transa\u00e7\u00e3o comprometida no node receptor.<\/p>\n Existem dois tipos de replica\u00e7\u00e3o PostgreSQL: replica\u00e7\u00e3o l\u00f3gica e f\u00edsica.<\/p>\n Uma simples opera\u00e7\u00e3o l\u00f3gica<\/em> A replica\u00e7\u00e3o f\u00edsica geralmente lida com arquivos e diret\u00f3rios. Ela n\u00e3o sabe o que esses arquivos e diret\u00f3rios representam. Estes m\u00e9todos s\u00e3o usados para manter uma c\u00f3pia completa dos dados completos de um \u00fanico cluster, tipicamente em outra m\u00e1quina, e s\u00e3o feitos no n\u00edvel do sistema de arquivos ou no n\u00edvel do disco e usam endere\u00e7os de bloco exatos.<\/p>\n A replica\u00e7\u00e3o l\u00f3gica \u00e9 uma forma de reproduzir entidades de dados e suas modifica\u00e7\u00f5es, com base em sua identidade de replica\u00e7\u00e3o (geralmente uma chave prim\u00e1ria). Ao contr\u00e1rio da replica\u00e7\u00e3o f\u00edsica, ela lida com bancos de dados, tabelas e opera\u00e7\u00f5es de DML e \u00e9 feita em n\u00edvel de cluster de bancos de dados. Ele usa um modelo de publica\u00e7\u00e3o<\/em> e assinatura<\/em> onde um ou mais assinantes<\/em> s\u00e3o assinantes de uma ou mais publica\u00e7\u00f5es<\/em> em um node editor<\/em>.<\/p>\n O processo de replica\u00e7\u00e3o come\u00e7a tirando um instant\u00e2neo dos dados no banco de dados da editora e depois copiando-os para o assinante. Os assinantes retiram os dados das publica\u00e7\u00f5es que assinam e podem re-publicar os dados posteriormente para permitir replica\u00e7\u00e3o em cascata ou configura\u00e7\u00f5es mais complexas. O assinante aplica os dados na mesma ordem que o editor para que a consist\u00eancia transacional seja garantida para publica\u00e7\u00f5es dentro de uma \u00fanica assinatura, tamb\u00e9m conhecida como replica\u00e7\u00e3o transacional.<\/p>\n Os casos t\u00edpicos de uso para replica\u00e7\u00e3o l\u00f3gica s\u00e3o:<\/p>\n O banco de dados de assinantes comporta-se da mesma forma que qualquer outra inst\u00e2ncia PostgreSQL e pode ser usado como editor para outros bancos de dados definindo suas publica\u00e7\u00f5es.<\/p>\n Quando o assinante \u00e9 tratado como somente leitura por aplica\u00e7\u00e3o, n\u00e3o haver\u00e1 conflitos a partir de uma \u00fanica assinatura. Por outro lado, se houver outras escritas feitas por um aplicativo ou por outros assinantes para o mesmo conjunto de tabelas, podem surgir conflitos.<\/p>\n O PostgreSQL suporta ambos os mecanismos simultaneamente. A replica\u00e7\u00e3o l\u00f3gica permite um controle fino tanto sobre a replica\u00e7\u00e3o de dados quanto sobre a seguran\u00e7a.<\/p>\n H\u00e1 principalmente dois modos de replica\u00e7\u00e3o PostgreSQL: s\u00edncrono e ass\u00edncrono. A replica\u00e7\u00e3o s\u00edncrona permite que os dados sejam escritos no servidor prim\u00e1rio e secund\u00e1rio ao mesmo tempo, enquanto a replica\u00e7\u00e3o ass\u00edncrona assegura que os dados sejam primeiro escritos no host e depois copiados para o servidor secund\u00e1rio.<\/p>\n No modo de replica\u00e7\u00e3o s\u00edncrona, as transa\u00e7\u00f5es no banco de dados prim\u00e1rio s\u00e3o consideradas completas somente quando essas mudan\u00e7as tiverem sido replicadas em todas as r\u00e9plicas. Os servidores de r\u00e9plicas devem estar todos dispon\u00edveis o tempo todo para que as transa\u00e7\u00f5es sejam completadas no banco de dados prim\u00e1rio. O modo s\u00edncrono de replica\u00e7\u00e3o \u00e9 usado em ambientes transacionais high-end com requisitos de failover imediato.<\/p>\n No modo ass\u00edncrono, as transa\u00e7\u00f5es no servidor prim\u00e1rio podem ser declaradas completas quando as mudan\u00e7as tiverem sido feitas apenas no servidor prim\u00e1rio. Estas mudan\u00e7as s\u00e3o ent\u00e3o replicadas nas r\u00e9plicas mais tarde no tempo. Os servidores de r\u00e9plicas podem permanecer fora da sincroniza\u00e7\u00e3o por uma certa dura\u00e7\u00e3o, chamada de lag de replica\u00e7\u00e3o. No caso de uma falha, pode ocorrer perda de dados, mas a sobrecarga fornecida pela replica\u00e7\u00e3o ass\u00edncrona \u00e9 pequena, ent\u00e3o \u00e9 aceit\u00e1vel na maioria dos casos (n\u00e3o sobrecarrega o host). O failover do banco de dados prim\u00e1rio para o banco de dados secund\u00e1rio leva mais tempo do que a replica\u00e7\u00e3o s\u00edncrona.<\/p>\n Para esta se\u00e7\u00e3o, estaremos demonstrando como configurar o processo de replica\u00e7\u00e3o PostgreSQL em um sistema operacional Linux. Para este exemplo, estaremos usando Ubuntu 18.04 LTS e PostgreSQL 10.<\/p>\nO que \u00e9 replica\u00e7\u00e3o PostgreSQL?<\/h2>\n
![\"Ilustra\u00e7\u00e3o](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
O que \u00e9 Failover autom\u00e1tico?<\/h3>\n
Benef\u00edcios de usar a replica\u00e7\u00e3o PostgreSQL<\/h2>\n
\n
Como funciona a replica\u00e7\u00e3o PostgreSQL<\/h2>\n
\n
M\u00e9todo 1: Streaming<\/h3>\n
Configurando o Node prim\u00e1rio<\/h4>\n
Passo 1: Inicialize o banco de dados<\/h5>\n
initdb<\/code>. Em seguida, voc\u00ea pode criar um novo usu\u00e1rio com privil\u00e9gios de replica\u00e7\u00e3o, utilizando o seguinte comando:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nPasso 2: Configure as propriedades do Streaming<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code>:<\/strong> Este par\u00e2metro \u00e9 necess\u00e1rio para a capacidade pg_rewind<\/code> que vem a calhar quando o servidor standby est\u00e1 fora de sincronia com o servidor prim\u00e1rio.<\/li>\nwal_level<\/code>:<\/strong> Voc\u00ea pode usar este par\u00e2metro para habilitar a replica\u00e7\u00e3o de fluxo do PostgreSQL, com poss\u00edveis valores incluindo minimal<\/code>, replica<\/code>, ou logical<\/code>.<\/li>\nmax_wal_size<\/code>:<\/strong> Isto pode ser usado para especificar o tamanho dos arquivos WAL que podem ser retidos em arquivos de log.<\/li>\nhot_standby<\/code>:<\/strong> Voc\u00ea pode utilizar este par\u00e2metro para uma conex\u00e3o de leitura com o secund\u00e1rio quando ele estiver definido como ON.<\/li>\nmax_wal_senders<\/code>:<\/strong> Voc\u00ea pode usar max_wal_senders<\/code> para especificar o n\u00famero m\u00e1ximo de conex\u00f5es simult\u00e2neas que podem ser estabelecidas com os servidores standby.<\/li>\n<\/ul>\nPasso 3: Criando nova entrada<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> se conecte e atue como servidor de espera, usando o IP especificado para replica\u00e7\u00e3o. Por exemplo, o IP especificado para replica\u00e7\u00e3o:<\/p>\nhost replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nConfigurando o node de espera<\/h4>\n
Passo 1: Backup do node prim\u00e1rio<\/h5>\n
pg_basebackup<\/code> para gerar um backup do node prim\u00e1rio. Isto servir\u00e1 como um ponto de partida para o node de espera. Voc\u00ea pode usar este utilit\u00e1rio com a seguinte sintaxe:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code>:<\/strong> Voc\u00ea pode usar isto para mencionar o host prim\u00e1rio.<\/li>\n-D<\/code>:<\/strong> Este par\u00e2metro indica o diret\u00f3rio no qual voc\u00ea est\u00e1 trabalhando atualmente.<\/li>\n-C<\/code>:<\/strong> Voc\u00ea pode usar isto para definir os pontos de verifica\u00e7\u00e3o.<\/li>\n-X<\/code>:<\/strong> Este par\u00e2metro pode ser usado para incluir os arquivos de log transacional necess\u00e1rios.<\/li>\n-W<\/code>:<\/strong> Voc\u00ea pode usar este par\u00e2metro para solicitar ao usu\u00e1rio uma senha antes de criar um link para o banco de dados.<\/li>\n<\/ul>\nPasso 2: Prepare o arquivo de configura\u00e7\u00e3o da replica\u00e7\u00e3o<\/h5>\n
-R<\/code> dentro do utilit\u00e1rio pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'<\/code> primary_conninfo = 'host=<master host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"''<\/code> recovery_target_timeline = 'latest' (mais recente)<\/code><\/pre>\n\n
primary_conninfo<\/code>:<\/strong> Voc\u00ea pode usar isto para fazer uma conex\u00e3o entre os servidores prim\u00e1rio e secund\u00e1rio, alavancando uma cadeia de conex\u00e3o.<\/li>\nstandby_mode<\/code>:<\/strong> Este par\u00e2metro pode fazer com que o servidor prim\u00e1rio comece como standby quando ligado.<\/li>\nrecovery_target_timeline<\/code>:<\/strong> Voc\u00ea pode usar isto para definir o tempo de recupera\u00e7\u00e3o.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nPasso 3: Reinicie o servidor secund\u00e1rio<\/h5>\n
\n
M\u00e9todo 2: Dispositivo de bloco replicado<\/h3>\n
M\u00e9todo 3: WAL<\/h3>\n
Replica\u00e7\u00e3o baseada no envio de logs (n\u00edvel de bloco)<\/h4>\n
Replica\u00e7\u00e3o baseada no envio de logs (n\u00edvel de arquivo)<\/h4>\n
Arquivamento WAL Cont\u00ednuo<\/h4>\n
pg_wal<\/code> para arquiv\u00e1-los \u00e9 conhecida como arquivamento WAL. PostgreSQL ir\u00e1 chamar um script dado pelo usu\u00e1rio para arquivamento, cada vez que um arquivo WAL for criado.<\/p>\nscp<\/code> para duplicar o arquivo para um ou mais locais, como uma montagem NFS. Uma vez arquivados, os arquivos do segmento WAL podem ser alavancados para recuperar o banco de dados em qualquer ponto no tempo.<\/p>\n\n
Detalhes do protocolo WAL Streaming<\/h4>\n
primary_conninfo<\/code> e se conecta ao servidor prim\u00e1rio alavancando uma conex\u00e3o TCP\/IP.<\/p>\n![\"Diagrama](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elementos da replica\u00e7\u00e3o do PostgreSQL<\/h2>\n
Modelos de replica\u00e7\u00e3o do banco de dados PostgreSQL<\/h3>\n
\n
Tipos de replica\u00e7\u00e3o PostgreSQL<\/h3>\n
initdb<\/code> realizaria a opera\u00e7\u00e3o f\u00edsica de criar um diret\u00f3rio base para um cluster. Da mesma forma, uma simples opera\u00e7\u00e3o l\u00f3gica<\/em> CREATE DATABASE<\/code>\u00a0realizaria a opera\u00e7\u00e3o f\u00edsica<\/em> de cria\u00e7\u00e3o de um subdiret\u00f3rio no diret\u00f3rio base.<\/p>\n\n
Modos de replica\u00e7\u00e3o<\/h3>\n
Como configurar a replica\u00e7\u00e3o do PostgreSQL<\/h2>\n