Pgpool-II

Wagner Antonio Pereira1 , Lucas Henrique Pereira2 , Michel Gomes de Souza3

1
Departamento de Ciência da Computação
Universidade Tecnológica Federal do Paraná (UTFPR)
Campus Campo Mourão – Via Rosalina Maria Dos Santos, 1233
CEP 87301-899 – Caixa Postal: 271
Campo Mourão – PR – Brasil
wagnerj@alunos.utfpr.edu.br, lucas.pereiracm@gmail.com, michels@alunos.utfpr.edu.br

Abstract. This article aims to present Pgpool-II, a program for PostgreSQL, in

which it is an important tool for load balancing, data replication and connection
management, the article brings some important facts about its use, both benefits
by using some practical examples for better understanding.

Resumo. Este artigo tem como objetivo apresentar o Pgpool-II, um programa

para o PostgreSQL, na qual é uma importante ferramenta para balanceamento
de carga, replicação de dados e gerenciamento de conexões, o artigo traz al-
guns fatos importantes sobre seu uso, tanto benefı́cios em sua utilização como
malefı́cios, aplicando alguns exemplos práticos para melhor entendimento.

1. Introdução
Em um mundo onde cada vez mais informação importante está adentrando e sendo dis-
ponibilizada na internet, é de extrema importância garantir a disponibilidade do mesmo,
para isso os banco de dados e programas usam de técnicas para prevenirem a super lotação
de acessos, o controle de conexões e o balanceamento de dados entre vários servidores,
culminando assim em um melhor desempenho, o Pgpool-II tem um papel importante para
a execução e funcionamento desses metodos.
Pgpool-II é recomendado para grandes empresas que possuem uma base de da-
dos muito grande e precisa que essa base tenha uma alta disponibilidade, e confiança,
mas também é recomendo a aplicações que podem escalar muito rápido, porque uma vez
que o pgpool-II está sento utilizado, fazer a replicação dos dados para um ou mais ser-
vidores é muito fácil dado que o Pgpool-II fica executando entre o servidor e um cliente
PostgreSQL, comunicando através do protocolo de backend e frontend, sendo assim um
aplicativo de banco de dados (frontend) acha que o Pgpool-II é o servidor PostgreSQL
real, e o servidor (backend) vê o Pgpool-II como um de seus clientes.
Tornando assim o programa transparente tanto para o servidor quanto para o cli-
ente. Sendo assim uma importante ferramenta para balanceamento de carga (Load Ba-
lancing), replicação de dados (Replication) e gerenciamento de conexões (Automated fail
over, Connection Pooling, Limiting Exceeding Connections).[Pgpool. ]

1.1. Pool de Conexões

Para qualquer operação entre uma aplicação e um banco de dados antes de tudo é ne-
cessário estabelecer uma conexão entre eles, esta conexão geralmente é feita utilizando
o protocolo TCP/IP, esse processo ira demandar de custos para a maquina do servidor
para ser aberta e ser fechada. Esses custos são requisições constante, sendo assim quando
milhares de clientes fazem essa requisição a tendencia do servidor é ficar mais lento.
Uma técnica simples para evitar esse ”abre-fecha”de conexões é manter um nu-
mero estipulado de conexões que sempre estarão abertas em um ”pool”de conexão e sim-
plesmente reutiliza-las quando necessário, dessa forma diminuindo tanto o gasto de re-
cursos quanto a diminuição do tempo de resposta da sua aplicação. [Valle ]
O Pgpool-II por sua vez mantém conexões estabelecidas com os servidores Post-
greSQL e as reutiliza sempre que uma nova conexão com as mesmas propriedades (ou
seja, nome de usuário, banco de dados, versão de protocolo) é incluı́da.
Fazendo assim a redução da sobrecarga de conexão e melhorando o rendimento
geral do sistema. A Figura 1 demostra de uma forma simplificada o processo dessa
funcionalidade.[Pedrosa ]
A variável responsavel pelo numero máximo de conexões no pool é a max pool,
seu valor padrão é 4, mas o número de conexões dos processos Pgpool-II para os back-
ends pode atingir num init children * max pool no total. Este parâmetro só pode ser
definido no inı́cio do servidor.
A Figura 1 apresenta a utilização do Pool de Conexão conforme as exemplifica
nos proximos passos.

1. Um cliente com o nome ”user1”solicita a conexão com o banco de dados db1.

2. Não a conexões existentes com as mesmas caracterı́sticas, então o Pgpool-II atri-
bui uma nova conexão.
3. Depois de usar o banco de dados o cliente ”user1”libera a conexão, entretanto o
PgPool-II mantém a sua conexão no Pool para ser reutilizado posteriormente.
4. O cliente ”user1”deseja conectar novamente ao banco de dados ”db1”. Como esta
conexão já existe no Pool de Conexões com as mesmas caracterı́sticas, o PgPool-II
permite que o cliente a reutilize.
5. Um outro cliente ”user2”deseja fazer a conexão com o banco de dados ”db2”,
então é enviado uma solicitação, como não existe no pool, uma nova conexão com
essas caracterı́sticas é criada pelo Pgpool-II. Após utilizado a conexão é mantida
aberta no pool para futuras conexões.
6. Um cliente utilizando o nome de usuario ”user3”solicita a conexão com o banco
de dados ”db3”. Como não existe uma conexão com essas caracterı́sticas na pool,
uma nova conexão é providenciada pel Pgpool-II, mas como o limite de conexões
aberta já foi atingido, o programa encera a conexão mais antiga e abre essa nova
no seu lugar com suas devidas caracterı́sticas.
7. Após seu uso, a conexão é mantida aberta como as anteriores para ser reutilizada
acaso precise.

1.2. Failover Automático

É quando um dos servidores de banco de dados ficar inativo ou ficar instável, o Pgpool-
II o desanexará e continuará as operações usando o restante dos servidores de banco de
dados.
 Figura 1. Representação simplificada de uma Pool de Conexão

O Pgpool faz isso atráves de sinais Heartbeat, o que é um sinal, enviado através
de pacotes UDP periodicamente, e quando esses pacotes não são mais recebidos pelo
PgPool, ele assume que aquele servidor não está mais ativo, e então faz automaticamente,
começa a enviar as requisições que estavam sendo enviadas a aquele servidor para outro
servidor. Quando um servidor volta a funcionar esses sinais voltaram a serem enviados e
o Pgpool-II vai voltar a enviar requisições a aquele servidor
Failover Automático é recomendado a serviços que precisam de uma alta disponi-
bilidade e também de uma alta confiabilidade, ou seja o sistema não pode parar e se parar
tem que ser pelor menor tempo possı́vel,

1.3. Replicação
A replicação possibilita a criação de um backup em tempo real em dois ou mais clus-
ters do PostgreSQL, para que o serviço possa continuar sem interrupção se um desses
clusters falhar. O Pgpool-II tem replicação integrada (replicação nativa). No entanto, o
usuário pode usar recursos de replicação externa, incluindo a replicação de streaming do
PostgreSQL.
O Pgpool-II permite por sua vez escalar um sistema de até 128 nós, considerando
 Figura 2. Arquitetura de um sistema com Pgpool-II

que foi ativada a funcionalidade de replicação do Pgpool-II, o modo de funcionamento

será a replicação de cada instrução SQl enviado de cada Cliente para o Pgpool-II para
todos os nós pertencentes ao sistema, assim como demonstra a na Figura 2.
Todos os nós existentes ficarão em um estado de consistência semelhantes,
e em caso de falha de um deles, o restante consegue garantir a continuidade do
serviço.[Pgpool a]

1.3.1. Tipo de Replicação

Existem quatro modos de execução diferentes no Pgpool-II: modo de replicação de strea-

ming, modo de replicação lógica, modo mestre escravo (modo slony), modo de replicação
nativa e modo Raw.
Em qualquer modo, o Pgpool-II fornece pool de conexões, failover automático.
Os arquivos de configuração de amostra para cada modo ja são fornecidos.
1.3.2. Replicação de Streaming

È o chamado fluxo de dados, antes tinha que esperar um arquivo completo para ser arqui-
vado e depois replicado, agora com Streaming não é necessário mais esperar este arquivo
estar finalizado, pois cada vez que uma transação esta finalizada a mesma já pode ser
transmitida para os escravos. Assim replicando todo o cluster.

1.3.3. Replicação Lógica

Este modo é recomendado caso precise de replicações com mais granularidades ou seja,
replicar apenas algumas tabelas, em vez de todo o cluster.
Neste modo, o PostgreSQL é responsável pela sincronização das tabelas. Como
a replicação lógica não replica todas as tabelas, é responsabilidade do usuário replicar a
tabela que poderia ter balanceamento de carga. Isso significa que, se uma tabela não for
replicada, o Pgpool-II poderá acessar tabelas desatualizadas.

1.3.4. Replicação Mestre-Escravo

O servidor primário (mestre) executa o banco de dados ativo, que trata as operações de
escrita e leitura, enquanto o servidor secundário (escravo) opera com uma cópia desse
banco de dados e trata apenas operações somente de leitura. Por isso, se o servidor prin-
cipal falhar, o sistema vai executar os dados do contêiner escravo.[MARKOVA ]

1.3.5. Replicação Nativa

A vantagem é que a sincronização é feita de maneira sı́ncrona: a gravação no banco

de dados não retorna até que todos os servidores PostgreSQL concluam a operação de
gravação. No entanto, você pode obter um efeito semelhante usando o PostgreSQL 9.6
ou posterior com synchronous commit = remote apply sendo definido na replicação de
streaming.
Se você puder usar a configuração, é altamente recomendável usá-la em vez
do modo de replicação nativa, pois é possı́vel evitar algumas restrições no modo de
replicação nativa.

1.3.6. Modo Raw

No modo raw, o Pgpool-II não se preocupa com a sincronização do banco de dados. É

responsabilidade do usuário fazer que toda as configurações necessarios para a replicação.
Neste modo o balanceamento de carga não é possı́vel neste modo

1.4. Balanceamento de Carga

O Pgpool-II aproveita o recurso de replicação para reduzir a carga em cada servidor Post-
greSQL.
 Ele faz isso distribuindo consultas SELECT entre os servidores disponı́veis, me-
lhorando a taxa de transferência geral do sistema. Em um cenário ideal, o desempenho de
leitura pode melhorar proporcionalmente ao número de servidores PostgreSQL.
O balanceamento de carga funciona melhor em um cenário em que há muitos
usuários executando muitas consultas somente leitura ao mesmo tempo. Também só é
possı́vel utilizar o balanceamento de carga, se houver a replicação de dados entre os ser-
vidores

1.5. Limite de Acesso de Conexões

Limite de Acesso de Conexões serve para quando há um limite no número máximo de
conexões simultâneas com o PostgreSQL, e novas conexões são rejeitadas quando esse
número é atingido.
Aumentar esse número máximo de conexões, no entanto, aumenta o consumo
de recursos e tem um impacto negativo no desempenho geral do sistema. O Pgpool-II
também tem um limite no número máximo de conexões, mas as conexões extras serão
enfileiradas em vez de retornar um erro imediatamente.

1.6. Watchdog
Watchdog é um recurso muito importante do pgpool-II, é um subprocesso implementado
para adicionar alta disponibilidade. Watchdog é usado para resolver o ponto único de
falha coordenando vários nós do Pgpool-II trocando informações entre si. Se o nó se
tornar um nó mestre, ele inicializará o status de backend localmente.
Quando um status de nó de backend é alterado por failover, o watchdog notifica
as informações para outros nós do Pgpool-II e as sincroniza. Basicamente os recursos
disponiveis no WatchDog são:

1.6.1. Verificação de vida do serviço pgpool

O watchdog monitora as respostas do serviço pgpool em vez do processo. Ele envia con-
sultas para o PostgreSQL via pgpool que está sendo monitorado pelo watchdog e o wat-
chdog verifica a resposta. Além disso, o watchdog monitora as conexões com servidores
de fluxo ascendente (servidores de aplicativos, etc.) do pgpool.

1.6.2. Monitoramento mútuo de processos de vigilância

Os processos do watchdog trocam informações nos servidores monitorados para manter

as informações atualizadas e permitir que os processos do watchdog se monitorem mutu-
amente.

1.6.3. Alterando o estado ativo/standby no caso de certas falhas detectadas

Quando uma falha do Pgpool-II é detectada, o watchdog notifica os outros watchdogs

dele. Se este for o Pgpool-II ativo, os watchdogs decidem o novo Pgpool-II ativo votando
e mudando o estado ativo/standby.
 1.6.4. Atribuição automática de endereços IP virtuais sı́ncrona à comutação de ser-
vidores

Quando um servidor pgpool em espera promove a ativação, o novo servidor ativo ativa a
interface IP virtual. Enquanto isso, o servidor ativo anterior desativa a interface IP virtual.
Isso permite que o pgpool ativo funcione usando o mesmo endereço IP, mesmo quando
os servidores são comutados.

2. Instalação e Configuração
A seguir será apresentado os passos para uma correta instalação e configuração do Pgpool-
II. A versão do PostgreSQL foi a 9.6 em um sistema Debian Linux 9. Antes de tudo
algumas dependências devem estar instaladas, como o pacote contrib do postresql, libpq5,
libpq-dev, o gcc e o make.
Comando 1. Instalando Dependencias
1 # apt-get install postgresql-contrib gcc make libpq-dev
libpq5

2.1. Instalação
Primeiro entre no site oficial do pgpool (http://www.pgpool.net) clique na areá de down-
loads e selecione o arquivo .tar.gz que irá baixar.
Comando 2. Baixando os arquivos.
1 # wget http://www.pgpool.net/mediawiki/images/pgpool-II
-4.0.1.tar.gz

Neste caso baixaremos a ultima versão disponı́vel do pgpool. Após o download

deveremos descompactar o arquivo com o seguinte comando:
Comando 3. Descompactando os arquivos.
1 # tar xf pgpool-II-4.0.1.tar.gz

Feito isso entre na pasta do arquivo extraı́do e execute:

Comando 4. Criando os arquivos e os instalando.
1 # ./configure
2 # make
3 # make install

Você também pode customizar a montagem e instalação com comandos adicionais

como : --prefix=caminho para selecionar um caminho diferente do padrão e --
with-pgsql=path para determinar o local onde as bibliotecas do PostgreSQL estão
instalas, caso as mesmas estejam em um lugar diferente especificado pelo pg config.
Os arquivos podem ser encontrados depois de instalados no diretório /etc/pgpool-
II ou no /usr/local/etc dependendo da sua distribuição.
 2.2. Configuração
Para configurar o pgpool devemos editar o arquivo pgpool.conf que é onde fica todos os
parametros disponiveis.
Na primeira instalação o pgpool cria um arquivo exemplo do pgpool.conf que
deveremos renomear.
Comando 5. Renomeando o exemplo.
1 # cd /usr/local/etc
2 # cp pgpool.conf.sample pgpool.conf

Para permitir que o pgpool fique acessı́vel para toda a rede, devemos modificar
no arquivo pgpool.conf a linha listen addresses = ’localhost’ para listen addresses = ’*’,
tambem mude o parametro socket dir.
Comando 6. Editando o Arquivo pgpool.conf
1 # vi pgpool.conf

Comando 7. Parametro para mudar no pgpool.conf

1 # - pgpool Connection Settings -
2 listen_addresses = ’*’
3 port = 9999
4 socket_dir = ’/var/run/postgresql/’

A porta que o pgpool será iniciado é a 9999, como se nessa porta um banco de dados
PostgreSQL estive-se rodando normalmente, ela será usada como ponte para a replicação
para os diversos nós existentes.
Para ativar a funcionalidade de replicação de dados e balanceamento de carga, no
mesmo arquivo mude os seguintes parametros.
Comando 8. Parametro para mudar no pgpool.conf
1 replication_mode = true
2 load_balance_mode = true

Agora iremos editar o arquivo pcp.conf. Este arquivo é utilizado para armazenar
o usuário e senha que o pgpool vai utilizar para se conectar ao banco de dados, e seus
registros tem o formato:
USERID:MD5PASSWD
Comando 9. Exemplo de como usar:
1 postgres:e8a48653851e28c69d0506508fb27fc5

3. Exemplos Práticos
Nesta seção iremos aplicar alguns exemplos praticos para melhor entendimentos dos con-
ceitos abordados pelo PgPool-II.
 3.1. Replicação
Iremos fazer um exemplo para a função de replicação disponı́vel no PgPool. A Figura 3
representa uma visão geral do que iremos fazer no exemplo. [Pgpool a][Charly ]

Figura 3. Visão geral do exemplo

No arquivo pgpool.conf iremos criar a configuração dos clusters/nós:

Comando 10. Criando um backend para os custers/nós.
1 backend_hostname0 = ’localhost’
2 backend_port0 = 5433
3 backend_weight0 = 1
4 backend_data_directory0 = ’/var/lib/postgresql/[versao]/[
no1]’
5

6 backend_hostname1 = ’localhost’
7 backend_port1 = 5434
8 backend_weight1 = 1
9 backend_data_directory0 = ’/var/lib/postgresql/[versao]/[
no2]’

Iremos criar 2 clusters/nós com diferentes portas, mas com o mesmo nome de host. Feito
isso devemos criar as pastas para cada cluster criado no pgpool.conf com pg createcluster.
 Comando 11. Criando os custers/nós.
1 sudo -u postgres
2 pg_createcluster 9.6 [no1]
3 pg_createcluster 9.6 [no2]

Para listar os clusters/nós criados use o comando pg lsclusters.

Comando 12. Listando os custers/nós.
1 pg_lscluster

Iremos trocar as portas dos clusters/nós, para isso acesse a pasta /etc/post-
gresql/9.6/, nesta pasta conterá todos os clusters criados até então. Acesse e modifique a
porta de cada cluster nos arquivos postgresql.conf dos respectivos.
Comando 13. Modificando as portas dos custers/nós.
1 cd /etc/postgresql/9.6/[no1]
2 vim postgresql.conf

Comando 14. Modifiando o arquivo postgresql.conf do no1.

1 port = 5433

Logo após acesse e modifique o arquivo pg hba.conf mudando o metodo de

autenticação para trust.
Comando 15. Modifiando o arquivo pgh ba.conf dono1.
1 # Database administrative login by Unix domain socket
2 local all postgres
trust
3

4 # TYPE DATABASE USER ADDRESS

METHOD
5

6 # "local" is for Unix domain socket connections only

7 local all all
trust
8 # IPv4 local connections:
9 host all all 127.0.0.1/32
trust
10 # IPv6 local connections:
11 host all all ::1/128
trust

Você deverá repetir esses passos para cada cluster/nó criado, lembrando que no
nosso exemplo o no2 devera receber a porta 5434. Feito isso inicie os clusters/nós com o
comando:
Comando 16. Iniciando o no1.
1 pg_ctlcluster 9.6 [no1] restart
 Aonde [no1] substituia pelo nome de todos os clusters/nós criados. Agora iremos
criar a posta do pgpool dentro do run.
Comando 17. Iniciando o no1.
1 sudo mkdir /var/run/pgpool
2 sudo chmod 777 /var/run/pgpool
3 sudo chown postgres /var/run/pgpool

Feito isso inicialize o pgpool:

Comando 18. Iniciando o pgPool.
1 pgpool -n -d > /tmp/pgpool.log 2>&1 &

Os seus nós já estão com replicação e balanceamento de carga, para testar iremos
inserir um banco de dados na porta 9999 que é a porta aonde esta localizado o servidor
pgpool.
Logue com o seu usuario postgres.
Comando 19. Logando com o usuario postgres.
1 su - postgres

Agora iremos criar um banco de dados e inserir no servidor pgpool, que irá replicar
essa modificações para o resto do nós.
Comando 20. Criando um Banco de dados.
1 createdb -p 9999 teste_replicacao

Entre na porta 9999 com o psql.

Comando 21. Conectando ao pgpool.
1 psql -p 9999
2 \c teste_replicacao

Você irá entrar no banco teste replicacao e agora ira criar uma tabela.
Comando 22. Inserindo uma tabela.
1 create table telefone(
2 int integer,
3 nome varchar(50)
4 );

Para ver se foi efetivado a criação desta tabela digite.

Comando 23. Ver a Relação das Tabelas.
1 teste_replicacao=# \dt
2 List of relations
3 Schema | Name | Type | Owner
4 --------+----------+-------+----------
 5 public | telefone | table | postgres
6 (1 row)

Feito isso pressione CTRL+D ou para sair e voltar ao terminal logado com o
usuario postgres.
Agora iremos verificar se foi replicado aos outros banco de dados.
Escolha uma das portas que você colocou para beckend, aqui escolheremos a porta
5434.
Comando 24. Inserindo um Banco de dados.
1 psql -p 5434

Para verificar se o banco de dados esta mesmo criado digite.

Comando 25. Listando os Banco existentes.
1 \l

Deve aparecer uma lista com os banco de dados, e nele o teste replicacao também.
Portanto assim a configuração esta completa.
Comando 26. Listando os Banco existentes.
1 List of databases
2 Name | Owner | Encoding | Collate |
3 ------------------+----------+----------+-------------+
4 postgres | postgres | UTF8 | en_US.UTF-8 |
5 template0 | postgres | UTF8 | en_US.UTF-8 |
6 | | | |
7 template1 | postgres | UTF8 | en_US.UTF-8 |
8 | | | |
9 teste_replicacao | postgres | UTF8 | en_US.UTF-8 |
10 (4 rows)

Caso queira acessar o banco de dados testez replicacao é só digitar.

Comando 27. Entrando no Banco de Dados.
1 \c teste_replicacao

3.2. Balanceamento de Carga

O pgPool permite balanceamento de carga de consultas(selects) e com um teste
simples podemos verificar como essa carga esta sendo dividida usando o comando
pgbench.[Pgpool b]
Mas para isso devemos popular nosso banco de dados criado com o seguinte co-
mando.
Comando 28. Populando o banco de dados para o teste.
1 pgbench -i -s 3 -p 9999 teste_replicacao
 Assim você terá varios dados disponivel para teste a partir de agora. Com o mesmo
comando iremos fazer o teste de consulta.
Comando 29. Comando generico para criar varias consultas.
1 pgbench -p NumeroPorta -c quantidadeClientes -S -T tempo
nomeDb

Comando 30. Aplicando o comando para gerar varias consultas.

1 pgbench -p 9999 -c 10 -S -T 100 teste_replicacao

Isso efetuara um teste de carga em seu banco. Para verificar o resultado digite o
seguinte comando.
Comando 31. Comando enerico para Verificar o resultado do Load Balance.
1 psql -p NumeroPorta -c "show pool_nodes" NomeDb

Comando 32. Verificando o resultado do Load Balance.

1 psql -p 9999 -c "show pool_nodes" teste_replicacao

Esse comando retornara os nodes com a quantidade de consultas realizadas nos

respectivos.
Comando 33. Resultados do Load Balance.
1 node_id |hostname|port|status|lb_weight|role |select_cnt|
2 ---------+---------+----+------+---------+------+---------+
3 0 |localhost|5432| up |0.500000 |master|151388 |
4 1 |localhost|5433| up |0.500000 |slave |100928 |
5 (2 rows)

3.3. FailOver Automatico

Agora iremos fazer um teste de FailOver Automatico que consiste e recuperar a con-
sistência se um dos nós cair direcionando o trafico para outro nó.
Primeiro de tudo iremos ver quais são nossos nós/clusters disponı́vel digitando o
seguinte comando.
Comando 34. Verificando Nós Disponivels.
1 psql -p 9999 -c "show pool_nodes" teste_replicacao

Esse comando retornara os nodes com algumas informações.

Comando 35. Resultados .
1 node_id |hostname|port|status|lb_weight|role |select_cnt|
2 ---------+---------+----+------+---------+------+---------+
3 0 |localhost|5432| up |0.500000 |primary|0 |
4 1 |localhost|5433| up |0.500000 |standby|0 |
5 (2 rows)
 Note que temos dois nós, um que esta com a porta 5432 que esta com a coluna
role como primary e otro nó na porta 5433 que esta com a coluna role como standby, ou
seja o nó primário irá ser o 5432.
A partir de agora iremos parar o serviços do nó cuja porta é 5423 ou seja o nó
primário com o seguinte comando.

Comando 36. Parando de executar o serviço do nó cuja porta é 5432 .

1 pg_ctlcluster 9.6 [no1] stop

Aonde o nó1 é o nome do nó/cluster. Depois de parar o cluster/nó, o failover

ocorrera e o cluster/nó da porta 5433 se torna o novo banco de dados principal ou seja
primary.

Comando 37. Resultados .

1 node_id |hostname|port|status|lb_weight|role |select_cnt|
2 ---------+---------+----+------+---------+------+---------+
3 0 |localhost|5432| up |0.500000 |standby|0 |
4 1 |localhost|5433| up |0.500000 |primary|0 |
5 (2 rows)
Referências
Charly. Replicação sincrona com postgresql e pgpool.
http://javadevilopers.blogspot.com/2009/06/
replicacao-sincrona-com-postgresql-e.html
Acessado: 01/11/2018.
MARKOVA, T. Replicação assı́ncrona mestre-escravo para bancos de dados postgresql
em um clique.
https://imasters.com.br/data/replicacao-assincrona-mestre-escravo-par
Acessado: 18/11/2018.
Pedrosa, B. I. Postgresql alta disponibilidade - pgpool.
https://issuu.com/bruno.isau/docs/postgresql_pgpool2
Acessado: 08/11/2018.
Pgpool. Basic configuration example.
http://www.pgpool.net/docs/latest/en/html/example-basic.
html#EXAMPLE-CONFIGS-REPLICATION
Acessado: 04/11/2018.
Pgpool. Testing load balance.
http://www.pgpool.net/docs/latest/en/html/
tutorial-testing-load-balance.html
Acessado: 12/11/2018.
Pgpool. What is pgpool-ii?
http://www.pgpool.net/docs/latest/en/html/intro-whatis.
html
Acessado: 30/10/2018.
Valle, M. E. D. Connection pool.
https://www.devmedia.com.br/connection-pool/5869
Acessado: 28/11/2018.