Replicação do PostgreSQL: um guia abrangente

Como qualquer proprietário de site lhe dirá, a perda de dados e o tempo de inatividade, mesmo em doses mínimas, podem ser catastróficos. Eles podem atingir os despreparados a qualquer momento, levando à redução da produtividade, acessibilidade e confiança no produto.

Para proteger a integridade do seu site, é vital criar proteções contra a possibilidade de tempo de inatividade ou perda de dados.

É aí que entra a replicação de dados.
Como qualquer proprietário de site lhe dirá que a perda de dados e o tempo de inatividade, mesmo em doses mínimas, podem ser catastróficos. Digite, replicação de dados Clique para Tweetar
A replicação de dados é um processo de backup automatizado no qual seus dados são copiados repetidamente de seu banco de dados principal para outro local remoto por segurança. É uma tecnologia integral para qualquer site ou aplicativo executando um servidor de banco de dados. Você também pode aproveitar o banco de dados replicado para processar SQL somente leitura, permitindo que mais processos sejam executados no sistema.

Configurar a replicação entre dois bancos de dados oferece tolerância a falhas contra contratempos inesperados. É considerada a melhor estratégia para obter alta disponibilidade durante desastres.

Neste artigo, vamos mergulhar nas diferentes estratégias que podem ser implementadas por desenvolvedores de back-end para replicação perfeita do PostgreSQL.

O que é replicação PostgreSQL?

A replicação do PostgreSQL é definida como o processo de copiar dados de um servidor de banco de dados PostgreSQL para outro servidor. O servidor de banco de dados de origem também é conhecido como servidor “primário”, enquanto o servidor de banco de dados que recebe os dados copiados é conhecido como servidor de “réplica”.

O banco de dados PostgreSQL segue um modelo de replicação simples, onde todas as gravações vão para um nó primário. O nó primário pode então aplicar essas alterações e transmiti-las aos nós secundários.

O que é failover automático?

Depois que a replicação de streaming físico for configurada no PostgreSQL, o failover poderá ocorrer se o servidor primário do banco de dados falhar. O failover é usado para definir o processo de recuperação, que pode demorar um pouco, pois não fornece ferramentas internas para definir o escopo das falhas do servidor.

Você não precisa depender do PostgreSQL para failover. Existem ferramentas dedicadas que permitem o failover automático e a comutação automática para o modo de espera, reduzindo o tempo de inatividade do banco de dados.

Ao configurar a replicação de failover, você praticamente garante alta disponibilidade, garantindo que as esperas estejam disponíveis se o servidor primário entrar em colapso.

Benefícios de usar a replicação do PostgreSQL

Aqui estão alguns dos principais benefícios de aproveitar a replicação do PostgreSQL:

• Migração de dados : você pode aproveitar a replicação do PostgreSQL para migração de dados por meio de uma alteração no hardware do servidor de banco de dados ou por meio da implantação do sistema.
• Tolerância a falhas : Se o servidor principal falhar, o servidor em espera pode atuar como um servidor porque os dados contidos para os servidores principal e em espera são os mesmos.
• Desempenho de processamento transacional online (OLTP) : Você pode melhorar o tempo de processamento de transações e o tempo de consulta de um sistema OLTP removendo a carga de consulta de relatório. O tempo de processamento da transação é a duração que leva para que uma determinada consulta seja executada antes que uma transação seja concluída.
• Teste do sistema em paralelo : Ao atualizar um novo sistema, você precisa ter certeza de que o sistema funciona bem com os dados existentes, daí a necessidade de testar com uma cópia do banco de dados de produção antes da implantação.

Como funciona a replicação do PostgreSQL

Geralmente, as pessoas acreditam que quando você está brincando com uma arquitetura primária e secundária, há apenas uma maneira de configurar backups e replicação, mas as implantações do PostgreSQL seguem uma das três abordagens a seguir:

1. Replicação em nível de volume para replicar na camada de armazenamento do nó primário para o secundário, seguida de backup no armazenamento blob/S3.
2. Replicação de streaming do PostgreSQL para replicar dados do nó primário para o secundário, seguido de backup no armazenamento blob/S3.
3. Fazer backups incrementais do nó primário para o S3 enquanto reconstrói um novo nó secundário do S3. Quando o nó secundário está nas proximidades do primário, você pode iniciar o streaming a partir do nó primário.

Abordagem 1: transmissão

A replicação de streaming PostgreSQL, também conhecida como replicação WAL, pode ser configurada sem problemas após a instalação do PostgreSQL em todos os servidores. Essa abordagem de replicação é baseada na movimentação dos arquivos WAL do banco de dados primário para o de destino.

Você pode implementar a replicação de streaming do PostgreSQL usando uma configuração primária-secundária. O servidor primário é a instância principal que manipula o banco de dados primário e todas as suas operações. O servidor secundário atua como instância suplementar e executa todas as alterações feitas no banco de dados primário, gerando uma cópia idêntica no processo. O primário é o servidor de leitura/gravação, enquanto o servidor secundário é meramente somente leitura.

Para essa abordagem, você precisa configurar o nó primário e o nó em espera. As seções a seguir elucidarão as etapas envolvidas em configurá-los com facilidade.

Configurando o nó primário

Você pode configurar o nó primário para replicação de streaming executando as seguintes etapas:

Etapa 1: inicializar o banco de dados

Para inicializar o banco de dados, você pode aproveitar o comando do initidb utility . Em seguida, você pode criar um novo usuário com privilégios de replicação utilizando o seguinte comando:

 CREATE USER REPLICATION LOGIN ENCRYPTED PASSWORD '';

O usuário terá que fornecer uma senha e nome de usuário para a consulta fornecida. A palavra-chave de replicação é usada para fornecer ao usuário os privilégios necessários. Uma consulta de exemplo seria algo assim:

 CREATE USER rep_user REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_pass'

Etapa 2: configurar as propriedades de streaming

Em seguida, você pode configurar as propriedades de streaming com o arquivo de configuração do PostgreSQL ( postgresql.conf ) que pode ser modificado da seguinte forma:

 wal_level = logical wal_log_hints = on max_wal_senders = 8 max_wal_size = 1GB hot_standby = on

Aqui está um pequeno pano de fundo sobre os parâmetros usados ​​no snippet anterior:

• wal_log_hints : Este parâmetro é necessário para o recurso pg_rewind que é útil quando o servidor em espera está fora de sincronia com o servidor primário.
• wal_level : você pode usar este parâmetro para habilitar a replicação de streaming do PostgreSQL, com valores possíveis incluindo minimal , replica ou logical .
• max_wal_size : Isso pode ser usado para especificar o tamanho dos arquivos WAL que podem ser retidos nos arquivos de log.
• hot_standby : Você pode aproveitar este parâmetro para uma conexão de leitura com o secundário quando estiver definido como ON.
• max_wal_senders : você pode usar max_wal_senders para especificar o número máximo de conexões simultâneas que podem ser estabelecidas com os servidores em espera.

Etapa 3: criar uma nova entrada

Depois de modificar os parâmetros no arquivo postgresql.conf, uma nova entrada de replicação no arquivo pg_hba.conf pode permitir que os servidores estabeleçam uma conexão entre si para replicação.

Normalmente você pode encontrar este arquivo no diretório de dados do PostgreSQL. Você pode usar o seguinte trecho de código para o mesmo:

 host replication rep_user IPaddress md5

Depois que o trecho de código é executado, o servidor primário permite que um usuário chamado rep_user se conecte e atue como o servidor em espera usando o IP especificado para replicação. Por exemplo:

 host replication rep_user 192.168.0.22/32 md5

Configurando o nó de espera

Para configurar o nó em espera para replicação de streaming, siga estas etapas:

Etapa 1: fazer backup do nó principal

Para configurar o nó em espera, aproveite o utilitário pg_basebackup para gerar um backup do nó primário. Isso servirá como ponto de partida para o nó em espera. Você pode usar este utilitário com a seguinte sintaxe:

 pg_basebackp -D -h -X stream -c fast -U rep_user -W

Os parâmetros usados ​​na sintaxe mencionada acima são os seguintes:

• -h : Você pode usar isso para mencionar o host principal.
• -D : Este parâmetro indica o diretório em que você está trabalhando no momento.
• -C : Você pode usar isso para definir os pontos de verificação.
• -X : Este parâmetro pode ser usado para incluir os arquivos de log transacionais necessários.
• -W : Você pode usar este parâmetro para solicitar uma senha ao usuário antes de vincular ao banco de dados.

Etapa 2: configurar o arquivo de configuração de replicação

Em seguida, você precisa verificar se o arquivo de configuração de replicação existe. Caso contrário, você pode gerar o arquivo de configuração de replicação como recovery.conf.

Você deve criar este arquivo no diretório de dados da instalação do PostgreSQL. Você pode gerá-lo automaticamente usando a opção -R no utilitário pg_basebackup .

O arquivo recovery.conf deve conter os seguintes comandos:

standby_mode = 'ligado'

primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<senha> application_name=”host_name”'

recovery_target_timeline = 'mais recente'

Os parâmetros usados ​​nos comandos acima mencionados são os seguintes:

• primary_conninfo : você pode usar isso para fazer uma conexão entre os servidores primário e secundário aproveitando uma string de conexão.
• standby_mode : Este parâmetro pode fazer com que o servidor primário inicie como standby quando ligado.
• recovery_target_timeline : Você pode usar isso para definir o tempo de recuperação.

Para configurar uma conexão, você precisa fornecer o nome de usuário, o endereço IP e a senha como valores para o parâmetro primary_conninfo. Por exemplo:

 primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'

Etapa 3: reinicie o servidor secundário

Por fim, você pode reiniciar o servidor secundário para concluir o processo de configuração.

No entanto, a replicação de streaming vem com vários desafios, como:

• Vários clientes PostgreSQL (escritos em diferentes linguagens de programação) conversam com um único endpoint. Quando o nó primário falhar, esses clientes continuarão tentando novamente o mesmo nome DNS ou IP. Isso torna o failover visível para o aplicativo.
• A replicação do PostgreSQL não vem com failover e monitoramento integrados. Quando o nó primário falha, você precisa promover um secundário para ser o novo primário. Essa promoção precisa ser executada de forma que os clientes gravem em apenas um nó primário e não observem inconsistências de dados.
• O PostgreSQL replica todo o seu estado. Quando você precisa desenvolver um novo nó secundário, o secundário precisa recapitular todo o histórico de mudança de estado do nó primário, que consome muitos recursos e torna caro eliminar nós na cabeça e criar novos.

Abordagem 2: Dispositivo de Bloco Replicado

A abordagem do dispositivo de bloco replicado depende do espelhamento de disco (também conhecido como replicação de volume). Nessa abordagem, as alterações são gravadas em um volume persistente que é espelhado de forma síncrona em outro volume.

O benefício adicional dessa abordagem é sua compatibilidade e durabilidade de dados em ambientes de nuvem com todos os bancos de dados relacionais, incluindo PostgreSQL, MySQL e SQL Server, para citar alguns.

No entanto, a abordagem de espelhamento de disco para a replicação do PostgreSQL precisa que você replique os dados de log e de tabela do WAL. Como cada gravação no banco de dados agora precisa passar pela rede de forma síncrona, você não pode perder um único byte, pois isso pode deixar seu banco de dados em um estado corrompido.

Essa abordagem normalmente é aproveitada usando Azure PostgreSQL e Amazon RDS.

Abordagem 3: WAL

WAL consiste em arquivos de segmento (16 MB por padrão). Cada segmento tem um ou mais registros. Um registro de sequência de log (LSN) é um ponteiro para um registro no WAL, informando a posição/local onde o registro foi salvo no arquivo de log.

Um servidor em espera aproveita os segmentos WAL — também conhecidos como XLOGS na terminologia PostgreSQL — para replicar continuamente as alterações de seu servidor primário. Você pode usar o log de gravação antecipada para garantir durabilidade e atomicidade em um DBMS ao serializar blocos de dados de matriz de bytes (cada um com um LSN exclusivo) para armazenamento estável antes de serem aplicados a um banco de dados.

A aplicação de uma mutação a um banco de dados pode levar a várias operações do sistema de arquivos. Uma questão pertinente que surge é como um banco de dados pode garantir a atomicidade no caso de uma falha do servidor devido a uma queda de energia enquanto estava no meio de uma atualização do sistema de arquivos. Quando um banco de dados é inicializado, ele inicia um processo de inicialização ou reprodução que pode ler os segmentos WAL disponíveis e compará-los com o LSN armazenado em cada página de dados (cada página de dados é marcada com o LSN do último registro WAL que afeta a página).

Replicação baseada em envio de log (nível de bloco)

A replicação de streaming refina o processo de envio de logs. Em vez de esperar pelo switch WAL, os registros são enviados à medida que são criados, diminuindo assim o atraso de replicação.

A replicação de streaming também supera o envio de logs porque o servidor em espera se vincula ao servidor primário pela rede, aproveitando um protocolo de replicação. O servidor primário pode enviar registros WAL diretamente por essa conexão sem depender de scripts fornecidos pelo usuário final.

Replicação baseada em envio de log (nível de arquivo)

O envio de logs é definido como a cópia de arquivos de log para outro servidor PostgreSQL para gerar outro servidor em espera reproduzindo arquivos WAL. Esse servidor está configurado para funcionar no modo de recuperação e seu único objetivo é aplicar quaisquer novos arquivos WAL à medida que eles aparecem.

Esse servidor secundário se torna um backup quente do servidor PostgreSQL primário. Ele também pode ser configurado para ser uma réplica de leitura, onde pode oferecer consultas somente leitura, também chamadas de espera ativa.

Arquivamento WAL Contínuo

A duplicação de arquivos WAL à medida que são criados em qualquer local que não seja o subdiretório pg_wal para arquivá-los é conhecido como arquivamento WAL. O PostgreSQL chamará um script fornecido pelo usuário para arquivamento, cada vez que um arquivo WAL for criado.

O script pode aproveitar o comando scp para duplicar o arquivo em um ou mais locais, como uma montagem NFS. Uma vez arquivados, os arquivos do segmento WAL podem ser aproveitados para recuperar o banco de dados a qualquer momento.

Outras configurações baseadas em log incluem:

• Replicação síncrona : antes que cada transação de replicação síncrona seja confirmada, o servidor primário aguarda até que os standbys confirmem que obtiveram os dados. O benefício desta configuração é que não haverá conflitos causados ​​por processos de escrita paralelos.
• Replicação multi-mestre síncrona : aqui, cada servidor pode aceitar solicitações de gravação e os dados modificados são transmitidos do servidor original para todos os outros servidores antes que cada transação seja confirmada. Ele aproveita o protocolo 2PC e adere à regra do tudo ou nada.

Detalhes do protocolo de streaming WAL

Um processo conhecido como receptor WAL, executado no servidor em espera, aproveita os detalhes de conexão fornecidos no parâmetro primary_conninfo de recovery.conf e se conecta ao servidor primário aproveitando uma conexão TCP/IP.

Para iniciar a replicação de streaming, o frontend pode enviar o parâmetro de replicação na mensagem de inicialização. Um valor booleano true, yes, 1 ou ON permite que o back-end saiba que ele precisa entrar no modo walsender de replicação física.

O remetente WAL é outro processo executado no servidor primário e é responsável por enviar os registros WAL para o servidor em espera à medida que são gerados. O receptor WAL salva os registros WAL no WAL como se fossem criados pela atividade do cliente de clientes conectados localmente.

Uma vez que os registros WAL atingem os arquivos de segmento WAL, o servidor em espera continua reproduzindo o WAL constantemente para que o primário e o de espera estejam atualizados.

Elementos da replicação do PostgreSQL

Nesta seção, você obterá uma compreensão mais profunda dos modelos comumente usados ​​(replicação de mestre único e multimestre), tipos (replicação física e lógica) e modos (síncrono e assíncrono) de replicação do PostgreSQL.

Modelos de replicação de banco de dados PostgreSQL

Escalabilidade significa adicionar mais recursos/hardware aos nós existentes para aprimorar a capacidade do banco de dados de armazenar e processar mais dados que podem ser obtidos horizontal e verticalmente. A replicação do PostgreSQL é um exemplo de escalabilidade horizontal que é muito mais difícil de implementar do que a escalabilidade vertical. Podemos alcançar escalabilidade horizontal principalmente por replicação de mestre único (SMR) e replicação de mestre múltiplo (MMR).

A replicação de mestre único permite que os dados sejam modificados apenas em um único nó, e essas modificações são replicadas em um ou mais nós. As tabelas replicadas no banco de dados de réplica não têm permissão para aceitar nenhuma alteração, exceto aquelas do servidor primário. Mesmo que o façam, as alterações não são replicadas de volta para o servidor primário.

Na maioria das vezes, o SMR é suficiente para o aplicativo porque é menos complicado de configurar e gerenciar, sem chances de conflitos. A replicação de mestre único também é unidirecional, pois os dados de replicação fluem principalmente em uma direção, do banco de dados primário para o de réplica.

Em alguns casos, o SMR sozinho pode não ser suficiente e pode ser necessário implementar o MMR. O MMR permite que mais de um nó atue como o nó primário. As alterações nas linhas da tabela em mais de um banco de dados primário designado são replicadas para suas tabelas equivalentes em todos os outros bancos de dados primários. Nesse modelo, os esquemas de resolução de conflitos são frequentemente empregados para evitar problemas como chaves primárias duplicadas.

Existem algumas vantagens em usar o MMR, a saber:

• No caso de falha do host, outros hosts ainda podem fornecer serviços de atualização e inserção.
• Os nós primários estão espalhados em vários locais diferentes, portanto, a chance de falha de todos os nós primários é muito pequena.
• Capacidade de empregar uma rede de longa distância (WAN) de bancos de dados primários que podem estar geograficamente próximos a grupos de clientes, mantendo a consistência de dados em toda a rede.

No entanto, a desvantagem da implementação do MMR é a complexidade e a dificuldade de resolver conflitos.

Várias ramificações e aplicativos fornecem soluções de MMR, pois o PostgreSQL não oferece suporte nativo. Essas soluções podem ser de código aberto, gratuitas ou pagas. Uma dessas extensões é a replicação bidirecional (BDR), que é assíncrona e é baseada na função de decodificação lógica do PostgreSQL.

Como o aplicativo BDR reproduz transações em outros nós, a operação de repetição pode falhar se houver um conflito entre a transação que está sendo aplicada e a transação confirmada no nó receptor.

Tipos de replicação do PostgreSQL

Existem dois tipos de replicação do PostgreSQL: replicação lógica e física.

Uma simples operação lógica “initdb” realizaria a operação física de criar um diretório base para um cluster. Da mesma forma, uma simples operação lógica “CREATE DATABASE” realizaria a operação física de criar um subdiretório no diretório base.

A replicação física geralmente lida com arquivos e diretórios. Ele não sabe o que esses arquivos e diretórios representam. Esses métodos são usados ​​para manter uma cópia completa de todos os dados de um único cluster, geralmente em outra máquina, e são feitos no nível do sistema de arquivos ou no nível do disco e usam endereços de bloco exatos.

A replicação lógica é uma maneira de reproduzir entidades de dados e suas modificações, com base em sua identidade de replicação (geralmente uma chave primária). Ao contrário da replicação física, ela lida com bancos de dados, tabelas e operações DML e é feita no nível do cluster de banco de dados. Ele usa um modelo de publicação e assinatura em que um ou mais assinantes são inscritos em uma ou mais publicações em um nó publicador .

O processo de replicação começa tirando um instantâneo dos dados no banco de dados do editor e, em seguida, copiando-o para o assinante. Os assinantes extraem dados das publicações que assinam e podem republicar dados posteriormente para permitir replicação em cascata ou configurações mais complexas. O assinante aplica os dados na mesma ordem que o publicador para que a consistência transacional seja garantida para publicações em uma única assinatura, também conhecida como replicação transacional.

Os casos de uso típicos para replicação lógica são:

• Enviando alterações incrementais em um único banco de dados (ou um subconjunto de um banco de dados) para assinantes à medida que ocorrem.
• Compartilhando um subconjunto do banco de dados entre vários bancos de dados.
• Acionar o disparo de alterações individuais à medida que chegam ao assinante.
• Consolidando vários bancos de dados em um.
• Fornecer acesso a dados replicados para diferentes grupos de usuários.

O banco de dados do assinante se comporta da mesma forma que qualquer outra instância do PostgreSQL e pode ser usado como editor para outros bancos de dados definindo suas publicações.

Quando o assinante for tratado como somente leitura pelo aplicativo, não haverá conflitos de uma única assinatura. Por outro lado, se houver outras gravações feitas por um aplicativo ou por outros assinantes no mesmo conjunto de tabelas, podem surgir conflitos.

O PostgreSQL suporta ambos os mecanismos simultaneamente. A replicação lógica permite um controle refinado sobre a replicação de dados e a segurança.

Modos de replicação

Existem basicamente dois modos de replicação do PostgreSQL: síncrona e assíncrona. A replicação síncrona permite que os dados sejam gravados no servidor primário e secundário ao mesmo tempo, enquanto a replicação assíncrona garante que os dados sejam gravados primeiro no host e depois copiados no servidor secundário.

Na replicação de modo síncrono, as transações no banco de dados primário são consideradas completas somente quando essas alterações forem replicadas para todas as réplicas. Os servidores de réplica devem estar todos disponíveis o tempo todo para que as transações sejam concluídas no primário. O modo síncrono de replicação é usado em ambientes transacionais de ponta com requisitos de failover imediatos.

No modo assíncrono, as transações no servidor primário podem ser declaradas concluídas quando as alterações forem feitas apenas no servidor primário. Essas alterações são então replicadas nas réplicas posteriormente. Os servidores de réplica podem permanecer fora de sincronia por um determinado período, chamado de atraso de replicação. No caso de uma falha, pode ocorrer perda de dados, mas a sobrecarga fornecida pela replicação assíncrona é pequena, portanto é aceitável na maioria dos casos (não sobrecarrega o host). O failover do banco de dados primário para o banco de dados secundário demora mais do que a replicação síncrona.

Como configurar a replicação do PostgreSQL

Nesta seção, demonstraremos como configurar o processo de replicação do PostgreSQL em um sistema operacional Linux. Para esta instância, usaremos o Ubuntu 18.04 LTS e o PostgreSQL 10.

Vamos cavar!

Instalação

Você começará instalando o PostgreSQL no Linux com estas etapas:

1. Primeiramente, você teria que importar a chave de assinatura do PostgreSQL digitando o comando abaixo no terminal:

    wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -

2. Em seguida, adicione o repositório PostgreSQL digitando o comando abaixo no terminal:

    echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list

3. Atualize o Índice do Repositório digitando o seguinte comando no terminal:

    sudo apt-get update

4. Instale o pacote PostgreSQL usando o comando apt:

    sudo apt-get install -y postgresql-10

5. Por fim, defina a senha para o usuário do PostgreSQL usando o seguinte comando:

    sudo passwd postgres

A instalação do PostgreSQL é obrigatória tanto para o servidor primário quanto para o secundário antes de iniciar o processo de replicação do PostgreSQL.

Depois de configurar o PostgreSQL para ambos os servidores, você pode passar para a configuração de replicação do servidor primário e secundário.

Configurando a replicação no servidor principal

Execute estas etapas depois de instalar o PostgreSQL nos servidores primário e secundário.

1. Primeiramente, faça login no banco de dados PostgreSQL com o seguinte comando:

    su - postgres

2. Crie um usuário de replicação com o seguinte comando:

    psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"

3. Edite pg_hba.cnf com qualquer aplicativo nano no Ubuntu e adicione a seguinte configuração: comando de edição de arquivo

    nano /etc/postgresql/10/main/pg_hba.conf

   Para configurar o arquivo, use o seguinte comando:

    host replication replication MasterIP/24 md5

4. Abra e edite postgresql.conf e coloque a seguinte configuração no servidor primário:

    nano /etc/postgresql/10/main/postgresql.conf

   Use as seguintes definições de configuração:
   

    listen_addresses = 'localhost,MasterIP'

    wal_level = replica

    wal_keep_segments = 64

    max_wal_senders = 10

5. Finalmente, reinicie o PostgreSQL no servidor principal primário:

 systemctl restart postgresql

Agora você concluiu a configuração no servidor primário.

Configurando a replicação no servidor secundário

Siga estas etapas para configurar a replicação no servidor secundário:

1. Faça login no PostgreSQL RDMS com o comando abaixo:

    su - postgres

2. Pare o serviço PostgreSQL de funcionar para nos permitir trabalhar nele com o comando abaixo:

    systemctl stop postgresql

3. Edite o arquivo pg_hba.conf com este comando e adicione a seguinte configuração:
   Comando Editar
   

    nano /etc/postgresql/10/main/pg_hba.conf

   Configuração
   

    host replication replication MasterIP/24 md5

4. Abra e edite postgresql.conf no servidor secundário e coloque a seguinte configuração ou descomente se estiver comentado: Comando de edição
   
   Configuração
   

    nano /etc/postgresql/10/main/postgresql.conf

    listen_addresses = 'localhost,SecondaryIP'

    wal_keep_segments = 64

    wal_level = replica

    hot_standby = on

    max_wal_senders = 10

   SecondaryIP é o endereço do servidor secundário

5. Acesse o diretório de dados do PostgreSQL no servidor secundário e remova tudo:

    cd /var/lib/postgresql/10/main

    rm -rfv *

6. Copie os arquivos do diretório de dados do servidor primário do PostgreSQL para o diretório de dados do servidor secundário do PostgreSQL e escreva este comando no servidor secundário:

    pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U

    replication --wal-method=fetch

7. Digite a senha do PostgreSQL do servidor primário e pressione enter. Em seguida, adicione o seguinte comando para a configuração de recuperação: Comando de edição
   

    nano /var/lib/postgresql/10/main/recovery.conf

   Configuração
   

    standby_mode = 'on' primary_conninfo = 'host=MasterIP port=5432 user=replication password=YOUR_PASSWORD' trigger_file = '/tmp/MasterNow'

   Aqui, YOUR_PASSWORD é a senha do usuário de replicação no servidor primário que o PostgreSQL criou

8. Uma vez que a senha foi definida, você teria que reiniciar o banco de dados PostgreSQL secundário desde que foi interrompido:

 systemctl start postgresql

Testando sua configuração

Agora que realizamos as etapas, vamos testar o processo de replicação e observar o banco de dados do servidor secundário. Para isso, criamos uma tabela no servidor primário e observamos se a mesma se reflete no servidor secundário.

Vamos lá.

1. Como estamos criando a tabela no servidor primário, você precisa fazer login no servidor primário:

    su - postgres psql

2. Agora criamos uma tabela simples chamada 'testtable' e inserimos dados na tabela executando as seguintes consultas PostgreSQL no terminal:

    CREATE TABLE testtable (websites varchar(100)); INSERT INTO testtable VALUES ('section.com'); INSERT INTO testtable VALUES ('google.com'); INSERT INTO testtable VALUES ('github.com');

3. Observe o banco de dados PostgreSQL do servidor secundário fazendo login no servidor secundário:

    su - postgres psql

4. Agora, verificamos se a tabela 'testtable' existe e podemos retornar os dados executando as seguintes consultas do PostgreSQL no terminal. Esse comando essencialmente exibe a tabela inteira.

    select * from testtable;

Esta é a saída da tabela de teste:

 | websites | ------------------- | section.com | | google.com | | github.com | --------------------

Você deve ser capaz de observar os mesmos dados que o do servidor primário.

Se você vir o acima, então você executou com sucesso o processo de replicação!

Quais são as etapas de failover manual do PostgreSQL?

Vamos analisar as etapas para um failover manual do PostgreSQL:

1. Falha no servidor primário.
2. Promova o servidor em espera executando o seguinte comando no servidor em espera:

    ./pg_ctl promote -D ../sb_data/ server promoting

3. Conecte-se ao servidor em espera promovido e insira uma linha:

    -bash-4.2$ ./edb-psql -p 5432 edb Password: psql.bin (10.7) Type "help" for help. edb=# insert into abc values (4,'Four');

Se a inserção funcionar bem, então o standby, anteriormente um servidor somente leitura, foi promovido como o novo servidor primário.

Como automatizar o failover no PostgreSQL

Configurar o failover automático é fácil.

Você precisará do gerenciador de failover EDB PostgreSQL (EFM). Depois de baixar e instalar o EFM em cada nó primário e em espera, você pode criar um cluster EFM, que consiste em um nó primário, um ou mais nós em espera e um nó testemunha opcional que confirma as afirmações em caso de falha.

O EFM monitora continuamente a integridade do sistema e envia alertas por e-mail com base nos eventos do sistema. Quando ocorre uma falha, ele alterna automaticamente para o modo de espera mais atualizado e reconfigura todos os outros servidores em espera para reconhecer o novo nó primário.

Ele também reconfigura os balanceadores de carga (como pgPool) e impede a ocorrência de “split-brain” (quando dois nós pensam que são primários).

Resumo

Devido às grandes quantidades de dados, escalabilidade e segurança tornaram-se dois dos critérios mais importantes no gerenciamento de banco de dados, especialmente em um ambiente de transações. Embora possamos melhorar a escalabilidade verticalmente adicionando mais recursos/hardware aos nós existentes, isso nem sempre é possível, geralmente devido ao custo ou às limitações de adicionar novo hardware.

Portanto, a escalabilidade horizontal é necessária, o que significa adicionar mais nós aos nós de rede existentes, em vez de aprimorar a funcionalidade dos nós existentes. É aqui que a replicação do PostgreSQL entra em cena.
Para proteger a integridade do seu site, é vital criar proteções contra a possibilidade de tempo de inatividade ou perda de dados. Saiba mais neste guia Click to Tweet
Neste artigo, discutimos os tipos de replicações do PostgreSQL, benefícios, modos de replicação, instalação e failover do PostgreSQL entre SMR e MMR. Agora vamos ouvir de você.

Qual você costuma implementar? Qual recurso de banco de dados é o mais importante para você e por quê? Adoraríamos ler seus pensamentos! Compartilhe-os na seção de comentários abaixo.