Replicação assíncrona em PostgreSQL 9.6

Replicação assíncrona em PostgreSQL 9.6

A replicação de dados tem como propósito garantir a alta disponibilidade de dados. Caso o servidor responsável por receber e alterar dados falhe – seja por problemas de hardware, queda de serviço ou desastres (incêndio no datacenter) – é crucial que tenhamos um servidor standby. Este, por sua vez, deve ter todos os dados que foram inseridos no servidor principal e deve ser igualmente capaz de aceitar tanto as requisições de escrita, quanto as de leitura realizadas pelos clientes.

Neste artigo iremos demonstrar como criar um sistema de replicação master/slave em PostgreSQL 9.6.

Instalação

O sistema operacional utilizado é Debian 9 (Stretch), mas o artigo é aplicável para suas variações (Ubuntu, Linux Mint, etc).

Primeiramente, instale o Postgresql 9.6:

sudo apt install postgresql

Por padrão, a instalação cria um cluster de dados no diretório /var/lib/postgresql, mas para fins didáticos iremos criar uma instância em um diretório customizado.

Crie uma instância PostgreSQL

Como usuário postgres, crie um cluster através do utilitário initdb com o nome “master“:


root@stretch:/home/vagrant# su - postgres
postgres@stretch:~/master$ /usr/lib/postgresql/9.6/bin/initdb -D master

Após executar estes comandos, todos os datafiles iniciais necessários para o funcionamento do PostgreSQL e os arquivos de configuração estarão localizados no diretório master:


postgres@stretch:~/master$ ls -lh
total 112K
-rw------- 1 postgres postgres 4 Jun 5 23:41 PG_VERSION
drwx------ 5 postgres postgres 4.0K Jun 5 23:41 base
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 global
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_clog
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_commit_ts
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_dynshmem
-rw------- 1 postgres postgres 4.4K Jun 5 23:41 pg_hba.conf
-rw------- 1 postgres postgres 1.6K Jun 5 23:41 pg_ident.conf
drwx------ 4 postgres postgres 4.0K Jun 5 23:41 pg_logical
drwx------ 4 postgres postgres 4.0K Jun 5 23:41 pg_multixact
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_notify
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_replslot
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_serial
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_snapshots
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_stat
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_stat_tmp
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_subtrans
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_tblspc
drwx------ 2 postgres postgres 4.0K Jun 5 23:41 pg_twophase
drwx------ 3 postgres postgres 4.0K Jun 5 23:41 pg_xlog
-rw------- 1 postgres postgres 88 Jun 5 23:41 postgresql.auto.conf
-rw------- 1 postgres postgres 22K Jun 5 23:41 postgresql.conf

Para iniciar essa nova instância, utilize o comando pg_ctl:


/usr/lib/postgresql/9.6/bin/pg_ctl -D master -l master/master.log -o '-p5433' start

Onde “-D” se refere ao diretório onde os arquivos de configuração estão localizados, “-l” define o nome e diretório do log a ser gerado, “-o ‘-p5433′” define em qual porta o serviço receberá requisições e start para enviar o sinal de inicialização do cluster.

Observação: Caso se queira modificar por definitivo qual porta será utilizada ao iniciar a instância master, basta modificar o arquivo master/postgresql.conf, removendo o comentário ‘#’ da linha 63 e modificando o parâmetro port para o número da porta desejada.

A partir deste ponto temos uma instância PostgreSQL escutando por requisições na porta 5433.
O próximo passo é alterar os parâmetros necessário para realizar um backup binário do cluster master.

pg_basebackup

pg_basebackup é o utilitário mais prático para realizar backups binário de um cluster PostgreSQL.
Para utilizá-lo, no entanto, é necessário criar um usuário com credenciais de replicação.

Crie o usuário ‘replication‘ com o seguinte comando:

createuser -P --replication -p 5433 replication
Enter password for new role: replication
Enter it again: replication

Observação: em ambientes produtivos, utilize uma senha segura.

Em seguida, é necessário adicionar o usuário ‘replication‘ à relação de conexões autorizadas no arquivo pg_hba.conf.

Adicione a seguinte linha:
# Arquivo master/pg_hba.conf
host replication replication 127.0.0.1/32 md5

Observação: habilitamos apenas acesso via localhost para fins didáticos. Para autorizar acesso de IPs externos, novas entradas para os mesmos também devem ser especificados neste arquivo.

As alterações só terão efeito após executarmos a função pg_reload_conf():

psql -c "select pg_reload_conf();"

Precisamos especificar no cluster o número de conexões de replicação autorizadas.

Definimos este valor no parâmetro max_wal_senders. Como o pg_basebackup utiliza duas conexões em seu andamento, definimos este número no arquivo master/postgresql.conf:
# Arquivo master/postgresql.conf
max_wal_senders = 2

Para disponibilizar a replicação, o parâmetro wal_level também deve ser modificado.
Ele dita as características contidas nos logs de transação. Para que o nível de escrita no log de transação possa ser consumido por servidores slave, seu valor deve ser ‘replica‘:

# Arquivo master/postgresql.conf
wal_level = replica

Os dois últimos parâmetros a ser modificados não se referem a replicação em si, mas sim com backups PITR. Para entender o funcionamento destes parâmetros, acesse este link: PITR em PostgreSQL 9.6

Altere o parâmetros archive_mode e archive_command:

# Arquivo master/postgresql.conf
archive_mode = on
archive_command = 'exit 0'

E então, podemos reiniciar o cluster:

$ /usr/lib/postgresql/9.6/bin/pg_ctl -D master -l master/master.log -o '-p5433' restart

A partir deste ponto, o pg_basebackup já pode ser utilizado.

Neste artigo, alguns parâmetros a mais foram usados:

-R cria automaticamente o arquivo recovery.conf, essencial para a parametrização da replicação de dados;

-P mostra o progresso do andamento dá cópia em execução.

Execute o comando abaixo e insira a senha configurada para o usuário ‘replication‘:

$ pg_basebackup -D slave -h 127.0.0.1 -p5433 -U replication -P

Uma cópia do cluster master será criada no diretório ‘slave‘.

Hot_standby:

Muitas vezes, utilizamos um banco de dados slave para que realize queries apenas de leitura (SELECTS).
Para habilitar este recurso, altere o parâmetro hot_standby:

# Arquivo slave/postgresql.conf
hot_standby = on

Inicie a instância slave:
$ /usr/lib/postgresql/9.6/bin/pg_ctl -D slave -l slave/slave.log -o '-p5434' start

TESTANDO A REPLICAÇÃO:

A replicação pode ser testada ao inserirmos dados no servidor master e analisar se os mesmos foram replicados
no servidor slave:

# MASTER
psql -p5433
create table a (a int);
CREATE TABLE

# SLAVE
postgres@stretch:~$ psql -p5434
psql (9.6.7)
Type “help” for help.

postgres=# \dt
List of relations
Schema | Name | Type | Owner
——–+——+——-+———-
public | a | table | postgres
(1 rows)

Note que nenhum dado pode ser inserido no servidor slave:

# SLAVE
postgres@stretch:~$ psql -p5434
psql (9.6.7)
Type "help" for help.

postgres=# create table b (b int);
ERROR: cannot execute CREATE TABLE in a read-only transaction

Caso seja necessário promover o servidor slave à master, executamos o comando a seguir:

$ /usr/lib/postgresql/9.6/bin/pg_ctl -D slave -o '-p5434' promote
server promoting

Observação: Uma vez promovido, o ex-slave não pode ser rebaixado à sua condição anterior automaticamente.

 

CURSOSCONSULTORIA    CONTATO

Anterior Construindo uma API em Python com: Flask, Decorators e Pytest para validação de cartão de crédito
Próxima Meetup - Como a transformação digital está afetando a carreira e as ferramentas dos profissionais de T.I

About author

Arlindo Neto
Arlindo Neto 7 posts

Arlindo Neto é administrador de banco de dados apaixonado por PostgreSQL. Cursa Ciência da Computação. Atua com foco em banco de dados open-source, possuindo 3 anos de experiência profissional em análise e engenharia de dados. Acumula experiência em projetos envolvendo PostgreSQL, MariaDB, MySQL e MongoDB. No momento vem atuando com Python, com ênfase em aplicações para Big Data. Possui expertise como professor, desenvolvendo e aplicando cursos sobre Linux e tecnologias Open Source, detém certificação EnterpriseDB PostgreSQL 9.6

View all posts by this author →

Você pode gostar também

Banco de Dados

Alta Disponibilidade do MySQL com InnoDB Cluster

Alta disponibilidade é um recurso que os bancos de dados  —  sejam eles relacionais ou não (NoSQL) —  devem possuir para serem respeitados no mercado. A topologia master-slave já é

Banco de Dados

Como restaurar a senha de root do MySQL

Em muitas situações é necessário resgatar a senha para o usuário root no banco de dados MySQL. Entre elas, a mais comum é a necessidade de prestar manutenção a um

Banco de Dados

Instalação do MySQL 8 em Debian e CentOS

Ao tentar instalar o MySQL – o banco de dados open-source mais popular do mundo – você pode ser surpreendido no final do processo ao obter o MariaDB. Este fork