Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Amorim Weverton Rufino De / weverton.geek@gmail.
com
4Linux
também é
consultoria, suporte
e desenvolvimento.
Você já deve nos conhecer pelos melhores cursos de linux do Brasil mas a
4Linux também é consultoria, suporte e desenvolvimento e executou alguns
dos mais famosos projetos do Brasil utilizando tecnologias “open software”.
Você sabia que quando um cidadão faz uma aposta nas loterias, saca dinheiro em
um ATM (caixa eletrônico), recebe um SMS com o saldo de seu FGTS ou simula o valor
de um financiamento imobiliário no “feirão” da casa própria, ele está usando uma
infraestrutura baseada em softwares livres com consultoria e suporte da 4Linux?
Serviços
Consultoria: Suporte Linux e Open Source: Desenvolvimento de Software:
Definição de Arquitetura, tunning em Contratos com regimes de atendi- Customização visual e funcional de
banco de dados , práticas DEVOPS, mento – preventivo e/ou corretivo - softwares Open Source, consultoria para
metodologias de ensino on-line, em horário comercial (8x5) ou de a construção de ambiente ágeis de
soluções open source ( e-mail, monito- permanente sobre-aviso (24x7) para Integração Contínua (Java e PHP) e
ramento, servidor JEE), alocação de ambientes de missão crítica. Suporte mentoria para uso de bibliotecas, plata-
especialistas em momentos de crise e emergencial para ambientes construí- formas e ambientes Open Source.
auditoria de segurança. dos por terceiros. Parceiro Oficial Zend.
Parceiros Estratégicos
Saiba mais
www.4linux.com.br/suporte
contato@4linux.com.br
Amorim Weverton Rufino De / weverton.geek@gmail.com
Características e Instalação
do PostgreSQL
Curso 801
Administração
PostgreSQL com
Alta Performance e
Alta Disponibilidade
Versão 4.1
Características
Características e Instalaçãodo
e Instalação doPostgreSQL
MySQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características e Instalação do PostgreSQL
Objetivos da Aula
 Conhecer a Origem do PostgreSQL

 Instalar o PostgreSQL;
 Ver as Características;
 Trabalhar com psql
 Criar um Banco de Dados;
 Comando SELECT
 Setup do repositório no Debian
 Filtros (WHERE, AND)
 Setup do repositório no Centos
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Origem do PostgreSQL
Microsoft
Sybase Corp Informix IBM
Tandem -NonStop SQL PostgreSQL
Berkeley POSTGRES Postgres95
Berkeley INGRES
CA Ingres Corp.
1970 1984 1987 1995 2016
Tudo começou como INGRES

Em 1973 estava começando o projeto System R da IBM, quando dois cientistas
da Universidade da Califórnia Berkeley, Michael Stonebraker e Eugene Wong, se
interessaram pelo projeto e decidiram por eles mesmos desenhar um sistema de
bancos de dados relacionais, a primeira versão do INGRES foi disponibilizada em
1974, já com uma pequena comunidade de usuários e manutenção do código fonte.
Apesar de seguir os conceitos e premissas do System R de grande porte da IBM,
o INGRES era primordialmente usado no Unix para máquinas DEC.
Os derivados
O INGRES era vendido em código fonte, disponível em fitas por uma pequena
taxa. Em torno de 1.000 cópias circulavam principalmente em universidades.
Vários bancos de dados comerciais utilizaram em seu princípio partes do
código do INGRES, principalmente por causa dos estudantes que participaram do
projeto original em Berkeley e que se juntaram ou fundaram as companhias que os
desenvolveram:
●
Início dos anos 80, Tandem Computers - Non-Stop SQL
●Meados dos anos 80, Sybase Corporation - Sybase
●Em 1992 a Microsoft licenciou alguns produtos Sybase – SQL Server
●Em 1997 a Informix adquiriu os demais direitos – Sybase
●Em 2000 a IBM tornou-se proprietária da Informix – Sybase
INGRES hoje
Stonebraker e Wong criaram a RTI-Ingres. Em 1994 o então Ingres se tornou
propriedade da Computer Associates. Em 2004 alguns componentes do Ingres foram
liberados sob três licenças diferentes de código livre.
Em 2005 foi criada a Ingres Corporation. Ela mantém suporte ativo ao código
fonte e usuários até hoje.
Pronúncia e Suporte do PostgreSQL
Pronúncia e escrita
 PostgreSQL ou Postgres - CORRETO

 Postgri, Postigré, Postgrês, Postigris – ERRADO
Suporte da Comunidade
 www.postgresql.org/community
 www.postgresql.org.br/comunidade
Finalmente, PostgreSQL
●1996 O Postgres95 foi rebatizado como PostgreSQL, muitos usuários

carinhosamente ainda o chamam por Postgres, talvez pela herança do nome original
e facilidade da pronúncia. A comunidade aceita ambas as denominações PostgreSQL
e Postgres, é assim que pode ser escrito.
●
1997 PostgreSQL 6.0 com a inclusão do MVCC(Multiversion Concurrencu Control) e
novos datatypes de data, hora e tipos e geométricos.
● 2000 PostgreSQL 7.0 WAL(Write Ahead Log), schemas, indexação por texto.
●
2005 PostgreSQL 8.0 Suporte para Microsoft Windows, tablespaces, PITR.
●2010 PostgreSQL 9.0 Amadurecimento do PL/pgSQL, suporte completo a Windows

64 bits, implementação do VACUUM FULL, ferramenta de upgrade pg_upgrade para
versões 8.3 e 8.4 para a versão 9.0, explain funciona para JSON, XML e YAML e
evoluções nas metodologias de replicação.
Características do PostgreSQL
 Banco de dados ACID;

 Licença BSD;
 Suporte ao padrão ANSI-SQL:2008;
 Possui replicação nativa;
 Bando de Dados Multi-Plataforma;
 Diversas ferramentas da comunidade.
6
Características atuais
O PostgreSQL é considerado o banco de dados livre mais avançado do mundo
por várias razões. Suporta largamente o padrão ANSI-SQL 2008 e respeita a norma
ACID. É altamente extensível, tem vários tipos de índices para diversas aplicações.
Pode ser instalado na maioria dos sistemas operacionais tipo Unix como Linux,
Solaris, AIX, HP-UX, família BSD, Mac OS X, True 64, etc. Atualmente conta também
com porte nativo para Windows.
A licença utilizada é a BSD, que permite a redistribuição comercial em formato

binário, original ou alterada, do programa ou da documentação, desde que seja
mantida a citação original dos desenvolvedores, do código original da Universidade
da Califórnia e a ausência de garantias.
A maioria das linguagens de programação modernas preveem interface nativa

para o PostgreSQL. Para as linguagens que não possuem interface nativa pode ser
feito o acesso através da interface ODBC. Aplicações Java contam com driver JDBC 3
e 4.
Existem centenas de projetos livres e comerciais relacionados à administração,

monitoramento, interfaceamento e extensão do PostgreSQL. Existe tradução para 24
idiomas.
Características do PostgreSQL - ACID
Atomicidade Consistência
Isolamento Durabilidade
ACID é uma característica fundamental para os bancos de dados, pois fecha

todos os pontos a fim de garantir uma transação correta. As características são:
Atomicidade: Garantir o início, meio e fim da transação a fim de que a transação só

seja efetuada por completa ou não seja executada, garantir que a transação não seja
executada parcialmente.
Consistência: Com a execução de várias transações em paralelo nenhuma transação

pode permitir que o banco de dados fique inconsistente. Significa garantir que, em
todo o momento, os dados estarão consistentes tanto antes, quanto durante e após
cada transação.
Isolamento: As transações executadas em paralelo não podem interferir nas

transações concorrentes durante a execução. Essa garantia é dada por “locks” no
banco.
Durabilidade: Após a conclusão da transação o banco precisa garantir que o dado

fique íntegro mesmo que haja qualquer tipo de falha no banco de dados. O
PostgreSQL usa um mecanismo de escrita em disco para essa garantia.
Versionamento do PostgreSQL
Atualizações minoritárias
 9.5.X (terceiro número da versão);

 Correção de BUGs;
 Correções de Segurança;
Atualizações majoritárias
 X.X (primeiro ou segundo numero da versão)

 Novas funcionalidades
Versionamento
Sendo um projeto comunitário, o PostgreSQL provê atualizações através do
site oficial www.postgresql.org. Se o pacote instalado for fornecido diretamente pelo
seu S.O., verifique as opções de atualização disponíveis.
As versões do PostgreSQL são divididas em majoritárias e minoritárias. As
versões majoritárias são identificadas pelos primeiros dois números da versão,
também chamadas de série. As versões minoritárias são identificadas pelo último
número da versão.
Uma versão majoritária é lançada a cada, aproximadamente, um ano, após
extensivos testes Novas versões majoritárias costumam incluir novas
funcionalidades ao PostgreSQL, que são normalmente discutidas nas listas
internacionais de discussão, na página wiki do Roadmap e debatidas e aprovadas
na reunião de desenvolvedores, que ocorre em paralelo ao evento PgCon, no
Canadá, no mês de maio de cada ano.
Um exemplo de versão minoritária disponível atualmente (em maio de 2015)
é a 9.4.1, significando que têm todas as funcionalidades da série 9.4.x, sendo que
existe somente 1 versão de correção foi lançada.
As versões majoritárias atualmente disponíveis para download estão
disponíveis no link: https://www.postgresql.org/ftp/source/
Nota
Atualmente (2016) as versão suportadas são da 9.1 até a 9.6, versão anteriores a
9.1 não são mais suportadas pela comunidade, nestes casos é extremamente
recomendável a atualização para uma das versões mais novas e suportadas.
Formas de instalação do PostgreSQL
 Instalação do fornecedor do SO;

 Utilização do repositório do site postgresql.org;
 Pacotes em postgresql.org (“rpm” e “deb”);
 Compilar código fonte;
Instalação do fornecedor do S.O.

● Está pronto para instalar, costuma ser a forma mais fácil e rápida;
● As flags utilizadas na compilação geralmente são as default;
● Todo sistema operacional possui uma estrutura de diretórios definida por seus
desenvolvedores;
● A versão do PostgreSQL será fixada pelo fornecedor ou comunidade.
Pacotes em www.postgresql.org
● Não estão disponíveis para todos os S.O. ou todas as variantes e versões do S.O.;
● Em alguns casos, é a única opção disponível (ex. Windows);
● Têm suporte da comunidade;
● São compiladas com as flags definidas pela comunidade.
Compilar o código fonte

● Maior grau de dificuldade;
●
Exige a presença do compilador C e código fonte das bibliotecas necessárias;
● Permite a maior customização;
● Permite a instalação de qualquer uma das versões disponíveis do PostgreSQL.

Instalação do PostgreSQL no Debian
# aptget
# dpkg
10
A comunidade PostgreSQL oferece pacotes no site www.postgresql.org. As

seguintes características estão presentes:
● Não estão disponíveis para todos os S.O. ou todas as variantes e versões do S.O.
●
Para distribuições GNU/Linux estão disponíveis repositórios para apt e yum,
distribuições recentes baseadas em Debian e Red Hat, respectivamente. Os
repositórios são completos e disponibilizam todas as versões suportadas do
PostgreSQL, bem como módulos contrib e outras ferramentas acessórias em
versões atuais como o PgAdmin 3, Slony, etc.
● Existe o one-click installer para Linux disponibilizado pela empresa EnterpriseDB.
O one-click installer, instala o PostgreSQL no diretório /opt e é compatível com a

maioria das distribuições recentes.
●
Para alguns sistemas operacionais, os pacotes disponíveis na comunidade são a
única opção disponível, como Windows e Mac OS X.
● Os pacotes da comunidade tem suporte pelos meios oficiais da comunidade
PostgreSQL como a documentação, FAQ, listas de discussão e wiki.

● São compiladas com as flags padrão, definidas pela comunidade.
Instalação do Repositório PostgreSQL no Debian
Execute os comandos abaixo nos servidores: dbmaster e standby1
1 Servidores dbmaster e standby1 inserir o repositório:

1# vim /etc/apt/sources.list
+ deb http://apt.postgresql.org/pub/repos/apt/ jessiepgdg main
2 Realize o download da chave do PostgreSQL e adicionar ao apt:
2# wget https://www.postgresql.org/media/keys/ACCC4CF8.asc
3# aptkey add ACCC4CF8.asc
3 Atualize a lista de pacotes do repositório:

4 # aptget update
11
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Debian
Execute os comandos abaixo nos servidores: dbmaster e standby1
1 Instale o pacote com o comando apt-get install conforme segue:

# aptget install postgresql9.6
1
2 Liste o conteúdo do diretório dos binários do PostgreSQL:
2 # ls l /usr/lib/postgresql/9.6/bin
3 Localize os binários dos programas abaixo:

3# whereis pg_dump
4# whereis psql
4 Liste as conexões da porta default do PostgreSQL:

5 # netstat an | grep 5432
12
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Stop e Start do PostgreSQL no Debian
1 No servidor dbmaster realizar listar os processos do PostgreSQL:

1# ps ef | grep postgresql
2# systemctl status postgresql
2 Comandos para parar o PostgreSQL:

3# /etc/init.d/postgresql stop # Como “root”
4$ /usr/lib/postgresql/9.6/bin/pg_ctl stop # Como “postgres”
3 Comandos para iniciar o PostgreSQL:

5# /etc/init.d/postgresql start # Como “root”
6$ /usr/lib/postgresql/9.6/bin/pg_ctl start # Como “postgres”
4 Comando para reload do PostgreSQL:

7# service postgresql reload
13
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Centos
# rpm # yum
14
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Instalação do PostgreSQL no Centos
Execute os comandos abaixo no servidor standby2
1 Realize a instalação do repositório com o comando abaixo:

1# rpm ivh
https://yum.postgresql.org/9.6/redhat/rhel7
x86_64/pgdgcentos969.63.noarch.rpm
2 Liste os repositórios do PostgreSQL e realize a instalação:
2# yum list postgres*
3# yum install postgresql96server
2 Localize os binários da instalação:
4# whereis pg_dump
5# whereis psql
15
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Criando um Cluster no PostgreSQL - Centos
No CentOS o cluster do PostgreSQL não foi criado, então vamos criar:
Execute os comandos abaixo no servidor standby2:
1 Crie um cluster no diretório default do Centos:
1 # /usr/pgsql9.6/bin/postgresql96setup initdb
2 Faça com que o serviço do PostgreSQL inicie no boot do SO:
2# systemctl enable postgresql9.6
3# systemctl start postgresql9.6
3 Valide as conexões de rede com o comando ss:

4# ss a | grep 5432
5# ss putan | grep 5432
16
O diretório de base onde residirá o cluster pode ser definido na variável de

ambiente \$PGDATA. Caso a variável exista e esteja correta, não será necessário passar
o parâmetro -D no utilitário initdb nem nos demais utilitários que precisam do diretório do
cluster.
O diretório deve ser de propriedade do usuário que gerenciará o cluster

(normalmente postgres) e deve estar vazio, caso contrário o initdb emitirá um erro e não
criará o cluster.
O cluster do PostgreSQL poderá conter quantos bancos de dados forem

desejados. Um cluster poderá ter vários usuários, cada um com permissões de acesso
diferentes. Cada cluster tem apenas um arquivo de configuração e um arquivo de
autenticação baseada em servidor. Uma única máquina pode ter vários clusters
PostgreSQL.
Vários clusters poderão estar rodando ao mesmo tempo, como várias instâncias,
se estiverem configurados para “escutarem” em portas TCP diferentes, definidos no
arquivo de configuração ou linha de inicialização da instância.
Compilando o PostgreSQL
 O procedimento é manual;
 Procedimento mais complexo;
 É necessário instalar pacotes de compilação;
 É necessário ter um entendimento sobre a
arquitetura do PostgreSQL;
17
Em situações específicas se faz necessário a compilação do PostgreSQL,

quando o servidor a ser instalado não tem acesso a internet por exemplo, é
necessário instalar todos os pacotes manualmente além da compilação do
PostgreSQL.
Num ambiente corporativo o ideal é padronizar os parâmetros de compilação,
assim como os procedimentos adotados pois, os procedimentos e diretórios podem
ser customizados, principalmente quando o sistema operacional se diverge.
Outro ponto importante é em relação a documentação, para facilitar o
troubleshooting o ideal é todos os diretórios default e opções de compilação fiquem
devidamente documentados afim de facilitar a administração do ambiente por outro
DBA.
Compilando a versão 9.2.1

Execute os comandos abaixo no servidor witness:
1 Faça o download de uma versão antiga do PostgreSQL:
1# wget
https://ftp.postgresql.org/pub/source/v9.2.1/postgresql
9.2.1.tar.gz
2 Instale os pacotes necessários:
3# aptget update
3# aptget install buildessential libreadline6dev
zlib1gdev
3 Descompacte o pacote do postgres 9.2.1 e faça a compilação:
4# tar vzxf postgresql9.2.1.tar.gz
5# cd postgresql9.2.1
6# ./configure prefix=/var/lib/postgresql/9.2
7# make
8# make install
18
Procedimentos básicos da compilação
1) Realizar o download do código fonte no site postgresql.org
2) Instalar os pacotes para compilação de acordo com o SO, ex: gmake, build-
essential, libreadline6-dev, zlib1g-dev, etc.
3) Configurar os parâmetros de compilação e instalar os pacotes.
As flags de compilação podem ser encontradas ao executar o comando a seguir:

# ./configure –help
Com esse comando é possível ver a lista das flags, dentre as flags de compilação
mais utilizadas estão:
--bindir=DIR
--sysconfdir=DIR
--with-blocksize=BLOCKSIZE
--with-pam
--with-ldap

4 Faça os ajustes para inicialização no linux:
1# cp contrib/startscripts/linux /etc/init.d/postgresql
2# chmod +x /etc/init.d/postgresql
3# vim /etc/init.d/postgresql
+ prefix=/var/lib/postgresql/9.2
+ PGDATA="/var/lib/postgresql/9.2/main"
4# updaterc.d postgresql defaults
5 Ajuste o path e as Libs do PostgreSQL:

5# sh c "echo 'PATH=/var/lib/postgresql/9.2/bin/:\
$PATH'> /etc/profile.d/pg.sh"
6# sh c "echo 'export PATH'>> /etc/profile.d/pg.sh"
7# ldconfig /var/lib/postgresql/9.2/lib/
19
4) Criar e editar arquivos de inicialização utilizando o script de inicialização já

disponibilizado com os binários do PostgreSQL.
É necessário também editar o prefixo e o PGDATA para adequar a nossa compilação.
O comando “update-rc.d” é um comando linux utilizado para acrescentar um serviço
no serviço de inicialização do Linux, o comando descrito informa ao Linux que o
PostgreSQL agora é um processo que deve ser inicializado automaticamente sempre
que houver um start do SO assim como quando houver um shutdown no ambiente, o
PostgreSQL será parado de uma forma segura com o shutdown padrão (fast).
5) Adicionar os binários do PostgreSQL no PATH.


6 Crie o usuário e os diretórios:
1# useradd shell /bin/bash d /var/lib/postgresql postgres
2# mkdir /var/lib/postgresql/9.2/main/
3# chown R postgres. /var/lib/postgresql/
7 Com o usuáro postgres, crie e inicialize o cluster:
1# su postgres
2$ initdb D /var/lib/postgresql/9.2/main/
3$ pg_ctl D /var/lib/postgresql/9.2/main l logfile start
8 Com o psql, verifique a versão atual instalada:
4 =# select version();
20
6) Criar usuário postgres e o diretório do cluster e ajustar permissões.
7) Criar e inicializar o PostgreSQL

Usuário postgres SO e Cluster

 Não são o mesmo usuário!!
Usuário do SO: postgres
 Usuário do SO criado na instalação do PostgreSQL;

 É o dono dos diretórios do PostgreSQL;
 Responsável por executar os processos do PostgreSQL;
Usuário do Cluster: postgres
 Usuário com permissões de DBA;

 Não deve ser usado pelos DBAS;
21
O usuário postgres
Não é uma boa prática rodar servidores como root ou administrador,

portanto, é interessante ter um usuário de sistema operacional não privilegiado
para tal. Geralmente é utilizado o usuário postgres para ser o dono dos diretórios e
processos do PostgreSQL. Outro usuário pode ser utilizado mas, neste curso,
utilizaremos o usuário postgres.
Quando o cluster é criado, um usuário postgres também existirá. Ele é,

inicialmente, superusuário do cluster.
O usuário postgres não tem senha no cluster, e recomenda-se que

permaneça assim. Também se recomenda que o usuário postgres do sistema
operacional não tenha senha (senha nula, sem acesso).
O usuário postgres do banco de dados não pode ser removido. Com ele, é
possível fazer uma recuperação de outros usuários em caso de emergência. Não
se recomenda que se utilize regularmente o usuário postgres para as tarefas
administrativas do banco de dados, muito menos utilizá-lo para tarefas de usuário
ou aplicações.
Para as tarefas administrativas que necessitem de superusuário,

recomenda-se criar novos superusuários com outros nomes, senhas seguras e
permissões de autenticação restritas (todos estes tópicos serão cobertos durante o
curso).
Utilizando o psql para gerenciamento do PostgreSQL
1 No Servidor dbmaster mudar para usuário postgres e entrar no psql:

1# su – postgres
2$ psql
2 Execute os comandos básicos:

3 =# \db Listar Tablespaces
4 =# \l Listar Bancos de dados
5 =# \dn Listar Schemas
6 =# \dt Listar tabelas
7 =# \h Ajuda para syntax dos comandos
8 =# \? Lista de atalhos de comandos
9 =# \q –Sair do psql
22
Segue exemplos de comandos disponíveis no PSQL:

Geral:
\q sair do psql
\watch [SEC] execute query every SEC seconds
Ajuda:
\? [commands] show help on backslash commands
\h [NAME] help on syntax of SQL commands, * for all commands
Query Buffer:
\e [FILE] [LINE] edit the query buffer (or file) with external editor
\s [FILE] display history or save it to file
Input/Output:
\i FILE execute commands from file
\o [FILE] send all query results to file or |pipe
Informações:
\d[S+] NAME describe table, view, sequence, or index
\dp [PATTERN] list table, view, and sequence access privileges
Formatação:
\x [on|off|auto] toggle expanded output (currently off)
Conexão:
\c {[DBNAME|- USER|- HOST|- PORT|-] | conninfo} conectar a um Banco
Sistema Operacional:
\timing [on|off] monitorar tempo de execução
\! [COMMAND executar comandos interativos no shell
Large Objects:
\lo_import FILE [COMMENT] importação de grandes objetos
COMPILAÇÃO
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Introdução ao Comando SELECT
 Função: Selecionar informações no banco;

 Recursos de filtro com WHERE;
 Recursos de múltiplas tabelas com JOIN;
 Pose ser usado vários SELECT's na mesma consulta;
 Auxilia na carga e exportação de dados;
 Pode ser usado com operadores.
24
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Syntax SELECT | WHERE
 Selecionar coluna 2 e 3 da tabela:

SELECT coluna1, coluna2 FROM tabela;
 Selecionar todos os campos da tabela:

SELECT * FROM tabela;
 Selecionar todas as colunas onde a coluna1 for igual a 10:

SELECT * FROM tabela WHERE coluna1 = 10;
25
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Comandos Básicos com SELECT
1 Selecione todos os registros da tabela pg_database:

1 postgres=# select * from pg_database;
2 Selecione apenas as colunas datname e datctype da tabela:

2 postgres=# select datname, datctype from pg_database;
3 Utilize a função COUNT para contar todos os registros da tabela:
3 postgres=# select count(*) from pg_database;
26
Syntax básica do comando SELECT:

Selecionando todos os campos da tabela:
SELECT * FROM nome_base.nome_tabela;
Selecionando somente as colunas1 e coluna2 da tabela:

SELECT coluna1, coluna2 FROM nome_base.nome_tabela;
Contando todos os registros da tabela:

SELECT count(*) FROM nome_base.nome_tabela;
Usando Filtros com WHERE/ AND/ LIKE/ =
1 Selecione na tabela pg_type os types quem começam com “n”:

1postgres=# select typname from pg_type
where typname like 'n%';
2 Selecione os campos name e setting da tabela pg_settings onde

o campo setting seja igual a “psql”:
2postgres=# select name, setting from pg_settings
where setting = 'psql';
3 Selecione os campos table_owner e table_name da tabela pg_tables
onde o schemaname seja igual a ‘pg_catalog’ e o table_name
termine com a letra c:
3postgres=# select tableowner, tablename from pg_tables
where schemaname = 'pg_catalog'
and tablename like '%c';
27
SELECT com utilização de Filtros:

Selecionando os registros da colunna que começam com a letra “A”:
SELECT * FROM nome_base.nome_tabela
WHERE nome_coluna LIKE 'A%';
Selecionando os registros da coluna que terminam com a letra “A”:

WHERE nome_coluna LIKE '%A';
Selecionando os registros que contém exatamente a palavra 'exata';

WHERE nome_coluna = 'exata';
Selecione os registros que contém a pavra 'texto' na coluna1 e o campo2 contém

'sim':
WHERE nome_coluna1 LIKE '%texto%'
AND nome_coluna2 = 'sim';
Recapitulando
 Conhecer a Origem do PostgreSQL

 Instalar o PostgreSQL;
 Ver as Características;
 Trabalhar com psql
 Criar um Banco de Dados;
 Comando SELECT
 Setup do repositório no Debian
 Filtros (WHERE, AND)
 Setup do repositório no Centos
28
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
Estrutura Física eeLógica
Instalação
do do MySQL
PostgreSQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Estrutura Física e Lógica do PostgreSQL
Objetivos da Aula
Conhecer o diretório de dados  Conhecer a estrutura lógica do

PostgreSQL
do PostgreSQL
 Conceito de Cluster  Criar Schemas

 Conceito de Tablespaces  Criar Tabelas
 Detectar OID;  Conceitos de índices
30
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Estrutura do PostgreSQL
Entidades Físicas e Lógicas
Cluster
Tablespace Tablespace
TBL IDX TBL IDX TBL IDX TBL IDX
Schema Schema Schema Schema
Database Database
31
Cluster: É equivalente a uma instância de banco de dados que é composta pela infra
(processos, diretórios e arquivos) que dá sustentação os dados do PostgreSQL.
Tablespace: É o local de armazenamento dos dados do PostgreSQL.
Database: É o conjunto de objetos que dá sustentação aos dados que estarão

presentes no PostgreSQL..
Schema: É uma segmentação lógica de tabelas e índices.
Tabelas: São objetos onde as tuplas serão armazenadas.
Índices: São objetos que faz o mapa das tuplas presentes nas tabelas.
Conceito de Cluster
 Cluster no PostgreSQL é equivalente a uma instância;

 Composição lógica: tablespace(s), databases e schema(s);
 Composição física: diretórios, arquivos e links (alguns casos);
 Initdb é o utilitário de criação do Cluster do PostgreSQL;
 O Cluster é criado por default na instalação por pacotes Debian;
32
initdb e o cluster do PostgreSQL
O initdb é o primeiro utilitário de administrador que apresentaremos. Ele

permite criar um novo cluster limpo do PostgreSQL.
Chamamos de Cluster PostgreSQL o diretório onde os bancos de dados
residem, e tem esse nome por ser um “agregado de bancos de dados”. Cada
instância PostgreSQL roda sobre um cluster exclusivo para ela.
O nome cluster pode causar confusão em muitas pessoas, pois é comumente
utilizado no Brasil para identificar “aglomerados de servidores”. A palavra cluster em
inglês significa simplesmente “aglomerado” e, no caso do PostgreSQL, um cluster é
um aglomerado de bancos de dados.
No Debian GNU/Linux, o utilitário initdb é chamado automaticamente pela
instalação pelo aptitude, criando um cluster. Mesmo assim, o utilitário está disponível
em /usr/lib/postgresql/[versão]/bin/initdb caso o administrador decida criar novos
clusters utilizando a instalação padrão do PostgreSQL do Debian.
Para iniciar um cluster:

initdb D /diretorio
● O diretório deve ser de propriedade do usuário postgres;
●
O diretório precisa estar vazio;
● Pode ser criado mais de um Cluster por servidor em portas e diretórios diferentes;
Criando um novo cluster
# /usr/pgsql-9.6/bin/postgresql96-setup initdb -D <path>
# /usr/pgsql-9.6/bin/postgresql96-setup pg_ctl -D <path>
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Localização dos diretórios do Cluster
 Dados = “/var/lib/postgresql/[versão]/main”;
 Configuração = “/etc/postgresql/[versão]/main”;
 Dados e Conf = “/var/lib/pgsql/[versão]/data”;
34
No Debian, o instalador automaticamente criará um cluster de bancos de dados em:

/var/lib/postgresql/[versão]/main
●Os arquivos de configuração estarão em:
/etc/postgresql/[versão]/main
●Um arquivo de inicialização estará em:
/etc/rc2.d/
No Centos o cluster foi criado manualmente sendo dados e configuração em:

/var/lib/pgsql/[versão]/data
●Um arquivo de inicialização estará em:
/usr/pgsql9.5/bin/postgres
Alguns Diretórios do Cluster
1 Veja o conteúdo do diretório abaixo do servidor standby2:

# ls la /var/lib/pgsql/9.6/data
1
 base = local de criação dos databases;

 global = local do catalogo das tabelas do cluster;
 pg_clog = posição das transações (commit);
 pg_log = diretório de logs do PostgreSQL;
 pg_multixact = dados MVCC e locks;
 pg_stat_tmp = arquivos temporários de statísticas;
 pg_xlog = local dos logs de transação WAL;
35
● base - Subdiretório Contém um subdiretório para cada banco de dados em uso;

● global - Subdiretório. Contém o catalogo do PostgreSQL, conjunto de tabelas de
uso de todo o cluster, como a pg_class;
●pg_clog - Subdiretório. Contém dados sobre o estado da finalização das transações,
commit;
●pg_multixact - Subdiretório. Contém dados sobre o estado multitransacional.
Usado para shared row locks;
●
pg_stat_tmp - Subdiretório. Arquivos temporários do sub-sistema de
estatísticas;
●pg_subtrans - Subdiretório. Dados de estado de sub-transações;
●pg_twophase - Subdiretório Contém arquivos de estado para prepared transactions;
●pg_xlog - Sub-diretório. Contém os logs de transação, chamados de arquivos WAL
(Write Ahead Log);

Alguns arquivos do Cluster
1 Veja o conteúdo do diretório abaixo do servidor standby2:

1# ls la /var/lib/pgsql/9.6/data
 PG_VERSION = versão majoritária do PostgreSQL;
 pg_hba.conf = arquivo de configurações de autenticação;
 pg_ident.conf = mapa de relacionamento entre usuarios;
 postgresql.auto.conf = utilizado pelo “ALTER SYSTEM”;
 postgresql.conf = arquivo de configurações do Postgres;
 postmaster.opts = comando de inicialização do Postgres;
 postmaster.pid = numero do processo do Postgres;
36
● PG_VERSION - Arquivo. Contém a versão majoritária do PostgreSQL utilizada no

cluster, por exemplo, 9.5;
●postmaster.opts - Arquivo. Contém as opções de linha de comando da última
inicialização do PostgreSQL neste cluster;

●
postmaster.pid - Arquivo de trava. Contém o PID e ID do segmento de memória
compartilhada (pode não estar presente se o servidor não estiver rodando);
Os arquivos postgresql.conf, pg_hba.conf, e pg_ident.conf normalmente ficam no
diretório do cluster, mas isso é opcional desde a versão 8.0:
●postgresql.conf – Arquivo de configuração geral do PostgreSQL;
●pg_hba.conf – Arquivo de autenticação baseada em servidor, com as permissões
por usuário, banco de dados, máscara de rede, tipo de autenticação ou suas

combinações;
●
pg_ident.conf – Mapa de relacionamento entre usuários de sistema e de banco de
dados. Vazio por padrão.
Conceito de Tablespace
 Área definida para armazenar dados;

 Utilizada para distribuir carga de IO;
 Tablespace default é “pg_default”;
 Pode ser criada em um diretório;
 O usuário “postgres” deve possuir permissões;
 A tablespace só pode ser criada por superusuário;
Versões anteriores a 9.1 é necessário criar um link no
SO para redirecionar a tablespace.
37
Tablespace
É um recurso do PostgreSQL que permite a alocação de objetos do banco de

dados em localizações físicas separadas, é considerada uma estrutura física. Cada
tablespace reside em um diretório próprio, sendo que esse diretório pode ser
exatamente o ponto de montagem de um disco ou LUN independente.
O diretório onde uma tablespace será criada deve ser propriedade do usuário
postgres.
O recurso de tablespaces é muito útil para a distribuição física dos bancos de
dados e seus objetos, pois aqueles objetos mais acessados e que,
consequentemente, têm uma carga de acesso a disco mais alto, podem ser alocados
em recursos específicos de I/O como discos e até mesmo controladoras separadas.
Objetos que ocupam muito espaço físico e dependem de manutenção
específica também podem se beneficiar deste recurso, uma vez que pode ser alocado
exclusivamente em um sistema de discos e de arquivos que permita essa
flexibilidade.
Por padrão, o PostgreSQL coloca todos os dados na tablespace pg_default.
Um banco de dados pode ter sua tablespace padrão alterada, de forma que todos os
novos objetos, se não indicada na criação, irão para a tablespace padrão.
O diretório pg_tblspc do cluster do PostgreSQL conterá links simbólicos para
todas as tablespaces criadas no cluster. As tablespaces são comuns a todo o cluster.
Criando uma tablespace no PostgreSQL

Execute os comandos abaixo no servidor dbmaster:
1 Crie o diretório que será utilizado para os dados da tablespace:

1# mkdir /tbsdexter
2# chown postgres. /tbsdexter
3# chmod 700 /tbsdexter
2 Com o usuário “postgres” entre no postgres e crie uma tablespace:

4# su postgres
5$ psql
6=# CREATE TABLESPACE tbsdexter LOCATION '/tbsdexter';
3 Liste as tablespaces:
7 =# \db
38
Tablespace e o DBA
É trabalho do DBA identificar os objetos que precisam dessas necessidades

especiais, dimensionar e configurar as tablespaces necessárias. Os objetos que
podem ser movidos para tablespaces são bancos de dados inteiros, tabelas
selecionadas ou índices selecionados.
A criação de tablespaces é segura, podendo ser realizada a qualquer
momento, sem concorrência ou overhead significativo, sem causar impactos em
ambientes de produção.
● Para criar uma nova tablespace no psql:

CREATE TABLESPACE [nome] LOCATION '/diretorio/tablespace';
Conceito de Database / Banco de Dados
 Um Cluster pode possuir vários Databases;

 Os Bancos de Dados são independentes;
 O Database é criado em uma Tablespace existente;
 A Base de Dados só pode ser criada por superusuário;
 Um Banco de Dados posui um dono/owner;
39
Bancos de dados (Databases)
Databases são as maiores entidades lógicas do cluster do PostgreSQL. Todas

as outras entidades lógicas, estarão contidas em databases. Utilizaremos a
nomenclatura em português "banco de dados" para se referir a elas.
É importante notar que tablespaces são entidades físicas, portanto não faz
sentido dizer que uma tablespace está dentro de um banco de dados, embora um
banco de dados possa estar "contido" em uma tablespace, outros objetos como
tabelas e índices isolados também podem. Não misturar as entidades físicas com as
lógicas.
Todo cluster pode, e normalmente irá, possuir vários bancos de dados. Um

cluster recém criado conta com pelo menos três bancos de dados (postgres,
template0 e template1), sendo que, para ser utilizado em produção, pelo menos mais
um banco de dados será, via de regra, criado pelo DBA.
Todos os objetos lógicos como tabelas, índices, chaves, funções, visões,

gatilhos e etc são totalmente independentes entre os bancos de dados, assim como
as permissões de acesso.
Quando várias aplicações compartilham o mesmo cluster, idealmente,

deveriam ocupar bancos de dados independentes.
Databases Template[0|1] e postgres
postgres
 Catálogos do sistema;
 Dicionário de dados;
template1
 Utilizado como template na criação de um database;
 Pode ser customizado para criação dos Dbs;
template0
 Backup do template1;
 Jamais deve ser alterado;
40
Todo cluster do PostgreSQL terá, inicialmente, os seguintes bancos de dados já

criados:
postgres
O banco de dados "postgres" está disponível para ser utilizado como primeira
conexão ao cluster, logo após ser criado. Ele pode ser removido, desde que existam
outros bancos de dados disponíveis para conexão. Não se recomenda utilizar o banco
"postgres" no cotidiano para conter seus objetos de banco de dados, porém, ele pode
permanecer no cluster como um banco de conexão de emergência caso não se
lembre o nome de outros bancos disponíveis.
template1
O banco de dados template1 é o modelo que é utilizado por padrão na criação
de novos bancos de dados. Neste banco de dados, o administrador pode criar novos
objetos e fazer outras modificações, que serão automaticamente copiados para os
novos bancos de dados criados a partir de então.
template0
O banco de dados template0 é um modelo, similar ao template1, porém
recomenda-se jamais mexer nele ou removê-lo. Em caso de necessidade de se criar
um novo banco template1, por exemplo, pode-se utilizar este "modelo mínimo"
template0, e a única forma de criar um banco template0 é recriando o cluster.
Criando um database no PostgreSQL

1 Crie o banco de dados dbdexter na tablespace tbsdexter:

1 =# CREATE DATABASE dbdexter TABLESPACE tbsdexter;
2 Crie um superusuário chamado aluno e torne ele dono do dbdexter:

2=# CREATE USER aluno SUPERUSER PASSWORD '4linux';
3=# ALTER DATABASE dbdexter OWNER TO aluno;
3 Consulte o id da tablespace onde fica o banco de dados dbdexter:

4=# SELECT datname, dattablespace
FROM pg_database WHERE datname = 'dbdexter';
4 Liste os diretórios:
5=# \! ls la /var/lib/postgresql/9.6/main/pg_tblspc
41
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Conceito de Schemas
 Utilizado para segmentar um Database;

 Separar objetos dentro de uma mesma Base;
 Facilidade no permissionamento;
 Schema padrão dos Databases é o public;
 É necessário especificar schema.tabela;
42
Schemas
Schemas são subdivisões de bancos de dados que podem ser comparadas a

diretórios de um sistema operacional, embora não possam ser aninhados (schema
dentro de outro schema), só há um nível de profundidade.
São úteis para criar uma separação de objetos de aplicações diferentes que
compartilham o mesmo banco de dados, gerenciar grupos e usuários similares de
objetos diferentes e organizar bancos de dados com muitas tabelas.
Afim de permitir que tabelas fora do schema default sejam acessadas sem a
nomenclatura citada acima pode-se alterar o search_path padrão para o schema que
se deseja trabalhar automaticamente.
SET search_path = '[nome do schema]';
Objetos de mesmo nome no mesmo banco de dados podem coexistir em schemas

diferentes, para criar schemas no psql:
CREATE SCHEMA [nome];
Após a criação do schema, será obrigatório referir-se às tabelas com uma

nomenclatura completa schema.tabela em todos os comandos, para tabelas fora do
schema default;
Tabelas e índices
Tabelas
 Objeto de armazenagem de dados;

 Baseado em colunas de diversos tipos;
 Podem ser referenciadas;
Índices
 Mapa dos dados da tabela;

 Baseado em uma ou mais colunas da tabela;
 O padrão utiliza uma “árvore balanceada” (btree);
43
Tabelas
● Tabelas é uma estrutura com uma ou mais colunas utilizada para armazenamento
de dados;
● Para cada coluna de uma tabela um tipo de dado a ser inserido deve ser
associado;
● Uma ou mais colunas podem ser referenciadas entre as tabelas;
● As permissões de acesso podem ser individualisadas por tabela;
●
O PostgreSQL é responsável pelo gerenciamento das versões das tuplas
armazenadas nas tabelas.
Índices
● Índices são estruturas associadas a uma ou mais colunas de uma tabela com
intenção de tornar buscas mais eficientes;

● Criados implicitamente durante a criação de tabelas para a sua chave primária;
● Cabe ao DBA identificar quais colunas precisam ou não de índices e qual tipo de
índice deve ser utilizado;

● O tipo de índice padrão no PostgreSQL é o btree ou “balanced tree”; este tipo de
índice é balanceado e requer pouca manutenção.

● Para criar um índice basta seguir esta sintaxe:
CREATE INDEX [ nome do indice ] ON [ tabela ] ( [ colunas ] )
● Para recriar índices:
REINDEX [ indice | tabela | database ]
Criando schemas e tabelas no PostgreSQL

1 Crie os schemas secretaria e financeiro banco de dados dbdexter:

1=# \c dbdexter
2=# CREATE SCHEMA secretaria;
3=# CREATE SCHEMA financeiro;
2 Crie uma tabela em cada schema:
4=# CREATE TABLE secretaria.turma (id int);
5=# CREATE TABLE financeiro.mensalidade (pagamento boolean);
3 Verifique a estrutura criada:

6=# \dn
7=# \dt+ financeiro.*
8=# \dt+ secretaria.*
44
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Criando índices no PostgreSQL
Syntax:
CREATE INDEX nome_indice
ON tabela (coluna);
1 Crie um índice no campo id da tabela turma do schema secretaria:

1 =# CREATE INDEX idx_turma_id ON secretaria.turma (id);
2 Crie uma tabela chamada turma no schema financeiro:
2 =# CREATE TABLE financeiro.turma (descricao text);
45
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
OIDs e o Armazenamento Físico
Conceito: Identificador único de

um objeto no PostgreSQL
 Todo objeto possui um identificador único(OID);

 Linhas de tabelas podem possuir OID;
 OID é útil para mapear locais físicos dos objetos;
 OIDs não devem ser usados por usuários e aplicações;
 Arquivos de dados são segmentados em 1GB(default);
46
OIDs são os identificadores de objetos do PostgreSQL. OIDs são números seriais

únicos, por tipo de objeto, dentro de um cluster. Bancos de dados, tabelas, índices e
tablespaces sempre terão um OID. Linhas de tabelas terão um OID único em cada
tabela, desde que a tabela seja criada com a opção WITH OIDS. Embora os OIDs
sejam visíveis para usuários e aplicações, não é uma boa prática referir-se aos
objetos pelo OID, deixando a cargo do PostgreSQL administrar esses valores.
A utilidade do OID para o administrador é identificar os objetos dentro do layout
físico do cluster em disco, permitindo algumas ações de manutenção, por exemplo,
mover tablespaces de um diretório para outro ou medir o espaço físico ocupado por
um banco de dados ou tabela (embora o PostgreSQL ofereça funções que retornem
esses valores). Não há utilidade prática para os OIDs de linhas, por isso a criação de
tabelas com OIDs de linha foi tornada opcional nas versões mais recentes do
PostgreSQL, devendo ser usada apenas para retrocompatibilidade de sistemas
legados.
Para visualizar OIDs, vamos utilizar os catálogos de sistema do PostgreSQL,
executando comandos diretamente no psql.
O PostgreSQL armazena os dados em arquivos binários, chamados de
datafiles. São arquivos como outros quaisquer, com permissão de acesso exclusivo
para o usuário postgres (podendo ser outro usuário, se o PostgreSQL for iniciado de
forma diferente) .
Cada tabela ou índice terá pelo menos um arquivo de dados, que pode ser
encontrado no diretório base do cluster ou numa tablespace, se o objeto estiver lá.
Se necessário, mais de um arquivo será gerado para o mesmo objeto. O
PostgreSQL trabalha por padrão com pedaços de 1GB por causa de limitações em
alguns sistemas de arquivos legados.
Os objetos podem ser encontrados nos datafiles utilizando o seu OID.
Detectando OID no PostgreSQL

1 Selecione o OID do banco de dados dbdexter:

1=# SELECT datid FROM pg_stat_database
WHERE datname='dbdexter';
2 Localize o local físico do banco de dados:

=# \! ls la /tbsdexter/PG*/
2
3 Conecte no database dbdexter e verifique o OID da tabela alunos:

3=# SELECT relid, relname FROM pg_stat_all_tables
WHERE relname = 'mensalidade';
4=# \! ls la /tbsdexter/PG*/<dbOID>/<tabOID>
4 Selecione o OID usando conversão no PostgreSQL:

5 =# SELECT 'financeiro.turma'::regclass::integer;
47
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Recapitulando
Conhecer o diretório de dados  Conhecer a estrutura lógica do

PostgreSQL
do PostgreSQL
 Conceito de Cluster  Criar Schemas

 Conceito de Tablespaces  Criar Tabelas
 Detectar OID  Conceitos de índice
48
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
Gerenciamento e Instalação do MySQL
do PostgreSQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Gerenciamento do PostgreSQL
Objetivos da Aula
 Formas de STOP do PostgreSQL;

 Conhecer o pg_hba.conf
 Usuarios e Roles
 Auditando usuários
 DCL - Data Control Language
50
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
STOP no Cluster do PostgreSQL

Pelo PostgreSQL
 Pode ser feito utilizando o pg_ctl;

 Stop Smart – Mais seguro;
 Stop Fast(default) – Seguro porém agressivo;
 Stop Immediate – Inseguro e Agressivo;
Pelo PostgreSQL
 Pode ser feito utilizando o KILL;
51
Lembre-se que você tem:

● Arquivos abertos
● Conexões de rede
● Transações em andamento
●
Semáforos
● Memória compartilhada
Não desejamos parar nossos bancos de dados nunca, mas é claro que várias
situações podem requerer esta tarefa. Um SGBD como o PostgreSQL terá:
Arquivos abertos – centenas ou até milhares de arquivos estão abertos em
disco quando bancos de dados estão transacionando.
Conexões de rede – sockets estão em uso, com clientes locais e/ou remotos
conectados.
Transações estão em andamento – a norma ACID prevê que as coisas
comecem, acontecem e terminem, tudo isso tem um intervalo de tempo.
Semáforos estão alocados – SGBDs multiprocesso utilizam o recurso de
semáforos do sistema operacional para controlar os processos que estão ocupando o
tempo de CPU e a comunicação entre eles.
Memória compartilhada está alocada – o desenho multiprocesso faz com que
uma área de memória esteja alocada para compartilhamento de todos os processos.
Considerando os itens acima, ao parar o cluster todos os recursos devem ser
liberados corretamente, caso contrário, o sistema operacional poderá não funcionar a
contento após uma parada do SGBD por esgotamento de recursos. O cluster pode
até não conseguir mais ser inicializado.
Tipos de STOP no Cluster

Smart | SIGTERM | kill -15
 Aguardará o encerramento das sessões;
 Incluindo processos de backup;
Fast | SIGINT | kill -2
 Finaliza e faz rollback de todas as transações;
 Realiza o Checkpoint;
Immediate | SIGQUIT | kill -3
 Dá um KILL em todas as transações;
 É equivalente a uma falha no servidor;
 A próxima inicialização irá ler os WAL files;
52
Parada smart
É a forma de parada mais segura, porém nem sempre viável, ao receber uma
solicitação de parada smart, o PostgreSQL aguardará que todas as transações
correntes sejam finalizadas, todas as sessões (conexões) abertas sejam encerradas
e, caso exista, um backup em andamento também será aguardado.
O uso da parada smart em ambientes complexos pode ser difícil ou até
impossível. Servidores de aplicação, pools de conexão, middlewares entre os
usuários e o banco de dados, scripts de automação rodando e até mesmo se algum
usuário deixou o psql ou pgAdmin abertos podem fazer com que o cluster não pare.
Será então necessário que todas as aplicações e clientes sejam parados
primeiro para que, em seguida, possa ser utilizada a parada smart.
Parada fast
A parada fast é a forma padrão de stop, ao receber uma solicitação de parada

fast, o PostgreSQL encerrará as transações correntes com um rollback, encerrará
sessões abertas e qualquer backup em andamento. Os recursos de sistema
operacional como semáforos e memória compartilhada serão liberados se a parada
for concluída com sucesso.
Note que uma parada fast, ao enviar o rollback das transações correntes, pode
fazer com que uma aplicação tenha comportamento inesperado se não estiver
preparada para tal. Esteja ciente de que a aplicação foi preparada para tratar esse
caso.
Parada immediate
Só deve ser utilizada em último caso. A parada immediate faz tudo o que a parada
fast faz, só que encerra todos os processos abruptamente, sem liberar corretamente os
recursos do sistema operacional. É equivalente a uma falha catastrófica.
Ao ser iniciado novamente, o PostgreSQL fará a releitura dos arquivos WAL
presentes no diretório pg_xlog, para garantir a gravação correta de todas as transações
finalizadas até o momento da parada.
A parada immediate tem utilidade caso o servidor esteja passando por problemas,
por exemplo, processos presos, e a parada fast não estiver funcionando.
Pode ser necessário utilizar comandos do sistema operacional para liberar
recursos não liberados pela parada, especialmente semáforos do Solaris.
Os seguintes sinais podem ser enviados ao processo postgres:

SIGTERM – equivale à parada smart
SIGINT – equivale à parada fast
SIGQUIT – equivale à parada immediate
SIGHUP | kill -1 – equivale ao reload
Utilizar o pg_ctl é mais prático e seguro.
Uso do kill
Os sinais de kill devem ser enviados ao processo pai postgres, nunca aos demais.
Caso um sinal de kill inadequado seja enviado a um processo de conexão (backend)
todo o seu cluster poderá falhar catastroficamente por corrupção da memória
compartilhada.
O processo postgres é o orquestrador e pai dos demais processos (que são forks
dele), portanto, ele possui rotinas capazes de interpretar os sinais kill. O pg_ctl faz todo
esse trabalho, por isso, prefira utilizá-lo sempre.
Ao instalar o PostgreSQL a partir dos pacotes disponibilizados de forma integrada

às distribuições Debian e Red Hat, bem como suas derivadas, scripts especializados são
disponibilizados para controlar o cluster. Prefira utilizar os scripts específicos das
distribuições sempre que disponíveis e isso for possível.
Nas distribuições Debian e suas derivadas, utilize como root o comando:

/etc/init.d/postgresql [start | stop | restart | reload | status]
Nas distribuições Red Hat 6 ou superior e suas derivadas, utilize como root o comando:
service postgresql-X.Y [start | stop | restart | reload | status | enable | disable]
Onde X.Y é a versão do PostgreSQL.

Utilização do pg_ctl
1 O pg_ctl não está no path, crie um link para que ele fique acessível:
1 # ln s /usr/lib/postgresql/9.6/bin/pg_ctl /bin/
2 Com o usuário postgres faça o stop smart e acompanhe os logs:
2 $ pg_ctl stop D /etc/postgresql/9.6/main m smart
3 Inicie o banco com o pg_ctl, faça o stop fast e veja os logs:
3$ pg_ctl start D /etc/postgresql/9.6/main
4$ pg_ctl stop D /etc/postgresql/9.6/main m fast
4 Inicie, faça o stop immediate, inicie e acompanhe os logs:
6$ pg_ctl stop D /etc/postgresql/9.6/main m immediate
54
Por isso o PostrgreSQL implementa várias formas de parada: smart, fast e

immediate, também é possível utilizar os sinais de kill que estão disponíveis no Linux
e toda a família Unix e derivados.
Utilizando o pg_ctl
O pg_ctl é a forma preferida para controlar o início e parada dos clusters
PostgreSQL, pois ele implementa uma série de facilidades ao administrador como
escolha dos sinais corretos nos processos corretos. O pg_ctl pode ser facilmente
implementado também em scripts.
Já foi mostrado nos capítulos anteriores o uso do pg_ctl para iniciar os clusters.
Para pará-los, a sintaxe será:
pg_ctl -m [modo] -D /dir/cluster stop
Se o modo for omitido, será utilizado o modo fast por padrão.
O reload não parará o cluster, apenas recarregará os arquivos de configuração.
Mais adiante veremos quais configurações podem ser alteradas e recarregadas sem
parada do cluster.
Não se deve passar a opção -m (modo) quando a intenção for fazer recarga de
arquivos de configuração (reload). Na recarga, não há qualquer indisponibilidade do
cluster, tudo continua funcionando normalmente.
Para parar e iniciar (restart) o cluster, ao invés de executar o pg_ctl duas vezes,
pode-se utilizar:
pg_ctl -m [modo] -D /dir/cluster restart
Existe também uma forma de apenas recarregar os arquivos postgresql.conf e
pg_hba.conf, chamada reload:
pg_ctl -D /dir/cluster reload
Processo de Autenticação PostgreSQL
55
Processo de Autenticação:
Os clientes do PostgreSQL fazem uma requisição do processo postmaster que
por sua vez realiza algum dos 3 tipos de autenticação que são:
Socket: No próprio Servidor via socket.

127.0.0.1: No próprio Servidor via rede de loopback (127.0.0.1)
listen_addresses: A partir de outro servidor ou interface de rede.
pg_hba.conf:
O Postmaster ao receber a requisição só encaminhará a requisição ao
PostgreSQL criando um processo em background caso a conexão de origem estejam
de acordo com as configurações que são carregadas do pg_hba.conf, essas
informações são carregadas de 2 formas diferentes:
1) Durante a inicialização do PostgreSQL;

2) Durante o RELOAD das configuraões.
Ajustando o PostgreSQL para Autenticação
Parâmetros (postgresql.conf):
port = 5432
Porta do PostgreSQL
hba_file = '/etc/postgresql/9.6/main/pg_hba.conf'
Define o local do arquivo “pg_hba.conf”, esse arquivo contém as
regras para que o client possa realizar uma tentativa de conexão.
listen_addresses = 'localhost'
Parâmetro que contém os IPs que poderão “escutar” a porta do
PostgreSQL.
56
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Arquivo pg_hba.conf
 Designar permissões antes da conexão com o Banco

 Gerenciar métodos de autenticação
 Determinar regras de conexão ao banco
 Gerar lista com regras mais restritivas primeiro
57
Para quê serve o pg_hba.conf
Como visto anteriormente nas permissões, é possível designar restrições e

liberações específicas por usuário para praticamente tudo dentro do cluster do
PostgreSQL. Essas configurações são aplicadas dentro do cluster, ou seja, um
usuário que tentar acessar um recurso não permitido já terá se conectado de alguma
forma ao banco de dados e as verificações serão feitas em catálogo.
O arquivo pg_hba.conf, acrônimo de Host-Based Authentication – autenticação
baseada em host, tem como função limitar os acessos antes mesmo que algum tipo
de conexão seja feita ao cluster.
Arquivo pg_hba.conf separação por colunas

TIPO DATABASE USUÁRIO CIDR-ADDRESS MÉTODO OPÇÕES
local all usuário desnecessário trust

reject
host sameuser joao,maria 172.20.143.89/32 password
IP único md5
hostssl samerole +grupo 172.20.143.0/24 ident
Rede pequena peer
hostnossl @arq_lista @arq_lista 10.6.0.0 ldap
255.255.0.0 pam
cert
58
Campo TYPE ou TIPO

Conexão por Unix Domain Sockets, ou seja, conexão por socket do sistema
operacional, sem o uso de rede ou da interface loopback (localhost).
O psql tentará se conecta por socket local se não for especificada a opção -h.
Os aplicativos baseados em libpq têm o mesmo comportamento. Na opção -h pode
ser também passado o diretório do socket.
local
●Conexão por Unix Domain Sockets;
●
Nem todos os clientes aceitarão conectar-se por este método;
●O psql tentará se conecta por socket local se não for especificada a opção -h;
●Se nenhuma linha do pg_hba.conf contiver este valor, a conexão por socket será
totalmente desativada.
host
●TCP/IP remoto ou local;
●Não criptografadas ou por SSL;
●Verificar listen_address do arquivo postgresql.conf.
hostssl
●Similar à opção host, somente SSL.
●O PostgreSQL deve estar compilado com suporte a SSL (biblioteca OpenSSL
disponível);
●Deve estar ativa em postgresql.conf;
●Todas as cifras da biblioteca OpenSSL.
hostnossl
●Exatamente o oposto de hostssl;
●
Somente conexões não criptografadas serão aceitas.
Campo DATABASE
●Especificar diretamente banco de dados;
●
Separar múltiplos valores por vírgulas;
●"all" representará todos os bancos;
●"sameuser" usuários do banco de mesmo nome;
●
"samerole" usuários pertencentes a grupo de mesmo nome do banco.
●"@" seguido do nome do arquivo, arquivo de lista.
Campo USER
●Especificar usuário;
●
Separar múltiplos valores por vírgulas;
●Papel de grupo, precedido por "+", todos os usuários pertencentes ao grupo poderão
se valer de tentativas de conexão;

●
Especificar um arquivo com lista de valores, utilizando "@".
Campo CIDR-ADDRESS
Funciona com IPV4 e IPV6;
Depende do sistema operacional para IPV6;
Utilizar um registro IPV4 e outro IPV6 mesmo que haja equivalência.Esta é a única
coluna que pode conter de zero a dois valores separados por espaço, sendo aceitas.
Para linhas do tipo local, este campo não deve ser especificado (nenhum valor na
coluna, coluna ignorada)
Para registros host, hostssl e hostnossl, este campo pode conter:
Endereços tipo CIDR-address (um valor na coluna), por exemplo:
172.20.143.89/32 um único host
172.20.143.0/24 rede pequena
10.6.0.0/16 rede grande
201.0.0.0/8 internet, todos os IPs começando por 201
0.0.0.0/0 toda a internet
Campo METHOD
Quando a tentativa de conexão coincidir com toda a combinação dos campos
anteriores, o PostgreSQL utilizará o método de conexão especificado neste campo.
Se este método aprovar a tentativa (como usuário e senha válidos), o usuário
se conectará ao banco de dados. Caso contrário, a conexão será recusada e, como já
citado acima, não haverá outras tentativas de conexão existentes no arquivo
pg_hba.conf abaixo desta linha.
trust
●Menos seguro;
●Permitirá a conexão incondicionalmente, por qualquer pessoa, preenchendo os
requisitos dos outros campos;

●Nenhuma senha será solicitada.
reject
●
Rejeitar a conexão incondicionalmente;
●Útil para excluir hosts;
●Método utilizado para realizar blacklist.
md5
●Senha criptografada;
●
Viajará criptografada pela rede;
●Preferido para conexões não SSL;
●É o método mais usado na prática.
password
●Requererá uma senha não criptografada;
●A senha viaja sem criptografia pela rede;
●Não utilize em redes não privadas.
Ident → peer
●
Usuário do S.O é o mesmo do Postgres;
●TCP/IP, servidor ident, não recomendado;
●Socket, verificará pelo S.O.;
●
Não pede senha;
●Em Solaris a partir do PostgreSQL 8.4;
●Interessante para muitos usuários locais.
gss: Autenticação tipo Single Sign On com Kerberos.

sspi: Disponível para PostgreSQL no Windows, permite autenticação Single Sign On.
krb5: Autenticação tipo Single Sign On com Kerberos versão 5.
ldap: Autenticar usando LDAP. Configurações adicionais são necessárias.
radius: Autenticar usando um servidor RADIUS.
cert: Autenticar usando os certificados SSL existentes. Nenhuma senha será
solicitada. A cn do certificado deve ser o nome do usuário. O cliente deve possuir o
certificado válido e correspondente. O servidor deve possuir o certificado raiz da
autoridade que emitiu o certificado do cliente.
pam: Autenticar usando PAM, disponível em alguns sistemas operacionais como
Linux e Solaris .Para os métodos baseados em Kerberos, NTLM, LDAP, RADIUS,
certificados e PAM, o usuário deverá previamente existir no catálogo do PostgreSQL,
e ser o mesmo do serviço externo. Apenas o par usuário/senha será verificado junto
ao serviço externo para permissão de conexão.
Ajustando Primeiro nível de acesso do PostgreSQL

1 Edite o arquivo postgresql.conf permitindo acessos remotos:

1# vim /etc/postgresql/9.6/main/postgresql.conf
+ listen_addresses = '*'
2 Agora vamos dar permissões na base dbdexter no pg_hba:

2# vim /etc/postgresql/9.6/main/pg_hba.conf
+ host dbdexter dexter 192.168.200.30/32 md5
+ host dbdexter dexter 192.168.56.1/32 md5
+ host dbdexter suporte 192.168.200.30/32 ldap
3 Reinicie o serviço do postgresql:

3 # service postgresql restart
61
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Usuários e Roles
Usuário
 Usuário pode ser membro de uma role | grupo;
 Deve possuir senha criptografada;
 Pode definir tempo de expiração e lock;
Roles
 Roles: Superuser, Create role, Create DB, Replication;
 Role tem o mesmo conceito que grupo;
 Uma role pode ser atribuida a qualquer usuário;
 Roles são usadas para agilizar a concessão de privilégios;
62
Criação de usuários
O PostgreSQL trabalha com permissões em um esquema de roles - papéis.

Todo usuário é um papel.
Principais roles
SUPERUSER: Privilégios de DBA assim como o usuário “postgres”.
CREATEDB: Privilégio para criação de Databases.
CREATEROLE: Privilégios para criação e remoção de Roles / Usuários.
LOGIN: Privilégios com permissões de LOGIN no Postgres.
REPLICATION: Privilégios de replicação de dados.
Criando Usuários e Roles

Execute os comandos abaixo no dbdexter:
1 Crie os usuários conforme exemplos:
1=# CREATE ROLE dexter WITH PASSWORD '4linux';
2=# CREATE GROUP consulta;
2 Verifique os usuários, faça alterações e depois valide novamente:

3=# \du
4=# ALTER USER dexter WITH LOGIN;
5=# ALTER USER consulta RENAME TO desenvolvedores;
6=# ALTER USER dexter SET lock_timeout TO 100;
7=# \du
3 Valide o login com o usuário dexter:
8=# SHOW lock_timeout; \q
9$ psql Udexter h127.0.0.1 dbdexter c "SHOW lock_timeout;"
63
Syntax de criação de usuários:
Criar um usuário:
CREATE USER nome_usuario [WITH rule_option] WITH PASSWORD;
Criar um usuário já com a opção de login:

CREATE USER nome_usuario WITH LOGIN;
Criar um usuário pertencente a uma role e com limite de conexões:

CREATE USER usuarioA WITH ROLE usuarioB CONNECTION LIMIT 10;
Syntax de alteração de usuários:
Alterar a senha do usuário:

ALTER USER nome_usuario WITH PASSWORD 'nova_senha';
Alterar um parâmetro default:

ALTER USER nome_usuario CONNECTION LIMIT 100;
Auditando usuários
 Customizar parametros de logs do postgresql.conf;

 log_connections – Auditar conexões realizadas;
 log_disconnections – Auditar conexões finalizadas;
 log_hostname – Auditar hostname conectado;
 log_statement – Auditar comandos executados ex:ddl;
 log_line_prefix – Formato da geração do LOG;
64
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Ajustando os logs para Auditoria

1 Edite o arquivo postgresql.conf para auditar os usuários:

+ log_connections = on
+ log_disconnections = on
+ log_hostname = on
+ log_line_prefix = '%t [%p]: [%l1] db=%d,user=%u@%r %x:%v '
+ log_statement = 'ddl'
2 Reinicie o serviço do postgresql:
2 # systemctl restart postgresql
65
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
DCL - Data Control Language
Conceito:
Comandos de
➢ GRANT – Conceder privilégios.
controle e
privilégios a dados. ➢ REVOKE – Revogar privilégios.
Syntax:
GRANT [SELECT|INSERT...] ON schema.tabela TO usuário;
REVOKE [DELETE|UPDATE...] ON schema.tabela FROM usuário;
66
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Algumas permissões
 GRANT [dmls] ON TABLE [tab] TO role;

 GRANT ALL PRIVILEGES ON DATABASE TO role;
 GRANT CREATE ON TABLESPACE tbs_name TO role;
 GRANT EXECUTE ON FUNCTION func_name TO role;
 GRANT role1 TO role2 WITH ADMIN OPTION;
67
GRANT {{SELECT|INSERT|UPDATE|DELETE|TRUNCATE|REFERENCES|TRIGGER}
[,...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column [, ...] )
[,...] | ALL [ PRIVILEGES ] ( column [, ...] ) }
ON [ TABLE ] table_name [, ...]
GRANT {{CREATE|CONNECT|TEMPORARY|TEMP} [,...] | ALL [ PRIVILEGES ] }
ON DATABASE database_name [, ...]
GRANT { EXECUTE | ALL [ PRIVILEGES ] }
ON { FUNCTION function_name ( [ [ argmode ] [ arg_name ] arg_type
[, ...] ] ) [, ...]
| ALL FUNCTIONS IN SCHEMA schema_name [, ...] }
GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
ON SCHEMA schema_name [, ...]
GRANT { CREATE | ALL [ PRIVILEGES ] }
ON TABLESPACE tablespace_name [, ...]
GRANT role_name [, ...] TO role_name [, ...] [ WITH ADMIN OPTION ]
Concedendo privilérios
1 Faça os procedimentos com o usuário dexter conforme segue:
1# psql Udexter h127.0.0.1 dbdexter
2=> select * from secretaria.alunos;
2 Abra outra sessão com o usuário aluno e dê permissões ao

usuário dexter a partir da base dbdexter:
3=# GRANT USAGE ON SCHEMA secretaria TO dexter;
4=# GRANT SELECT ON TABLE secretaria.alunos TO dexter;
3 Volte ao passo 1, execute select nas tabelas alunos e cursos:
4 Agora na sessão 2 dê permissão em todo o schema:

5=# GRANT SELECT ON ALL TABLES IN SCHEMA secretaria TO dexter;
68
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Recomendações Gerais
 Mínimo privilégio possível sempre;

 Sempre auditar ambientes produtivos;
 Não utilizar usuário compartilhado;
 Manter permissões atualizadas;
69
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Gerenciamento do PostgreSQL
Recapitulando
 Formas de STOP do PostgreSQL;

 Conhecer o pg_hba.conf
 Usuarios e Roles
 Auditando usuários
 DCL - Data Control Language
70
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Fundamentos de SQL e Carga de Dados
Objetivos da Aula
 Surgimento do SQL
 Operações DDL e DML
 Funções do PostgreSQL
 Carga de Dados
 Importação e exportação de CSV
71
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
SQL - Structured Query Language
 Linguagem utilizada no PostgreSQL

 Usada amplamente pelos bancos de dados Relacionais;
 Foi criado pela IBM na década de 70 ;
 Normatizado pela ANSI e ISO;
 Versão 2015 sendo revisada;
72
Conceitos:
SQL é uma linguagem de consulta estruturada padrão dos bancos de dados
relacionais, sendo muitas de suas características inspiradas em álgebra relacional.
A IBM criou o SQL e rapidamente foi se expandindo. Em um dado momento,
houve a necessidade de uma padronização, que foi realizada pela ANSI (American
National Standards Institute) e pela ISO.
Timeline Padrão ANSI/ISO:

1992 = Foi realizada uma revisão e dado o nome de SQL-92.
1999 = Inserção de expressões regulares de espelhamento, queries recursivas e
gatilhos(triggers).
2003 = Características XML, sequências padronizadas e colunas com valores
generalização.
2008 = Realiza-se uma nova revisão e é definido o padrão default da versão 9.5 do
PostgreSQL.
2015 = Revisão mais recente que está sendo homologada.
DDL - Data Definition Language
Conceito:
Comandos de definição estrutural de objetos, ou

seja, comandos de criação, alteração ou remoção
de objetos no banco de dados.
➢ CREATE [TABLE, VIEW, TRIGGER, etc]

➢ ALTER [TABLE, INDEX ,etc]
➢ DROP [TABLE, INDEX, VIEW,etc]
➢ RENAME
➢ TRUNCATE
73
DDL - Data Definition Language - Linguagem de Definição de Dados: Uma DDL

permite ao utilizador definir tabelas novas e elementos associados. A
maioria dos bancos de dados SQL comerciais tem extensões proprietárias no DDL.
Os comandos básicos da DDL são poucos:
CREATE - cria um objeto (uma tabela, por exemplo) dentro da base de dados.
DROP - apaga um objeto do banco de dados.
Alguns sistemas de banco de dados usam o comando ALTER, que permite ao usuário
alterar um objeto, por exemplo, adicionando uma coluna a uma tabela existente.
Outros comandos DDL são:
CREATE TABLE – Cria uma tabela;

CREATE INDEX – Cria um índice;
CREATE VIEW – Cria uma view;
ALTER TABLE – Altera uma tabela;
ALTER INDEX – Altera um índice;
DROP TABLE – Apaga uma tabela;
DROP VIEW – Apaga uma view;
DROP INDEX – Apaga um índice;
RENAME TABLE – Renomeia uma tabela.
Datatypes – Tipos de Dados - PostgreSQL
Datatype: Características de cada coluna da tabela,

abaixo os mais utilizados pelo PostgreSQL:
Tipo Descrição
INTEGER INT, BIGINT, SMALLINT, números inteiros
NUMERIC Campo numérico inteiros e não inteiros
TIMESTAMP Data e tempo
BOOLEAN VERDADEIRO ou FALSO
CHAR Caracteres ex CHAR(8) reserva o espaço de 8 caracteres
VARCHAR Caracteres até um determinado limite
TEXT Para campos de texto com muitos caracteres
UUID Campo para inserir UUID único
JSON Dados de JSON em forma de texto
POINT Campo para dados geométricos num plano
74
Datatypes ou Tipos de Dados

São os tipos de dados aceitos em uma coluna dentro do banco de dados. Os
bancos de dados relacionais possuem vários tipos de dados em que uma coluna pode
ser formatada. Esses tipos de dados são bastante variáveis, porém alguns são
comuns entre a grande maioria dos bancos de dados relacionais. Seguem os
datatypes do PostgreSQL::
Name Aliases Description

bigint int8 signed eight-byte integer
bigserial serial8 autoincrementing eight-byte integer
bit [ (n) ] fixed-length bit string
bit varying [ (n) ] varbit variable-length bit string
boolean bool logical Boolean (true/false)
box rectangular box on a plane
bytea binary data ("byte array")
character [ (n) ] char [ (n) ] fixed-length character string
character varying [ (n) ] varchar [ (n) ] variable-length character string
cidr IPv4 or IPv6 network address
circle circle on a plane
Name Aliases Description

date calendar date (year, month, day)
double precision float8 double precision floating-point number (8
bytes)
inet IPv4 or IPv6 host address
integer int, int4 signed four-byte integer
interval [ fields ] [ (p) ] time span
json textual JSON data
jsonb binary JSON data, decomposed
line infinite line on a plane
lseg line segment on a plane
macaddr MAC (Media Access Control) address
money currency amount
numeric [ (p, s) ] decimal [ (p, s) ] exact numeric of selectable precision
path geometric path on a plane
pg_lsn PostgreSQL Log Sequence Number
point geometric point on a plane
polygon closed geometric path on a plane
real float4 single precision floating-point number (4
bytes)
smallint int2 signed two-byte integer
smallserial serial2 autoincrementing two-byte integer
serial serial4 autoincrementing four-byte integer
text variable-length character string
time [ (p) ] [ without time time of day (no time zone)
zone ]
time [ (p) ] with time zone timetz time of day, including time zone
timestamp [ (p) ] [ without date and time (no time zone)
time zone ]
timestamp [ (p) ] with time timestamptz date and time, including time zone
zone
tsquery text search query
tsvector text search document
txid_snapshot user-level transaction ID snapshot
uuid universally unique identifier
xml XML data
Prática DDL
1 Crie a tabela teste no schema secretaria do banco dbdexter:

1=# \c dbdexter
2=# CREATE TABLE secretaria.teste (id int, nome

varchar(50), idade decimal, email varchar(45));
2 Renomeie a tabela teste para alunos:
3=# ALTER TABLE secretaria.teste RENAME TO alunos;
3 Acrescente o campo senha na tabela alunos:

4=# ALTER TABLE secretaria.alunos ADD senha varchar(45);
4 Remova a tabela turma do schema secretaria:

5=# DROP TABLE secretaria.turma;
76
Syntax dos comandos:
Criar tabela:
CREATE TABLE nome_tabela (coluna1 [TYPE], coluna2 [TYPE]);
Criar tabela temporária:

Tabela temporária dura o tempo da sessão corrente, somente a sessão corrente
conseguirá trabalhar com a tabela temporária e o término da sessão implica no DROP
da tabela temporária.
CREATE TEMPORARY TABLE nome_tabela_temp (coluna1 [TYPE]);
Renomear tabela:
Mesmo renomeando a tabela o OID é mantido.
ALTER TABLE nome_atual RENAME TO nome_novo;
Adicionar nova coluna:

ALTER TABLE tabela ADD nova_coluna [TYPE];
Remover tabela:
DROP TABLE nome_tabela;
Criar índice:
CREATE INDEX nome_indice ON tabela (coluna);
DML - Data Manipulation Language
Conceito:
Comandos de consultas e manipulação de dados
do banco de dados, inserções, atualizações,
remoção de registros mantendo a estrutura de
dados inalterada.
➢ SELECT – Comando de consultas de dados*
➢ INSERT – Comando de inserção de dados
➢ UPDATE – Comando de atualização de dados
➢ DELETE – Comando de remoção de dados

77
DML - Data Manipulation Language – Linguagem de Manipulação de Dados
O DML é utilizado para realizar inclusões, consultas, alterações e exclusões de

dados presentes em linhas. Estas tarefas podem ser executadas em várias linhas de
diversas tabelas ao mesmo tempo. Os comandos são:
SELECT * FROM [tabela] – Seleciona dado(s) na tabela;
Pode ser usado para auxilisar alterações dos dados.
INSERT INTO [tabela] VALUES [valores] – Inserção de valor(es);
UPDATE [tabela] SET [coluna] = [valor] – Atualiza registro(s);
DELETE FROM [tabela] – Remove um ou mais registros.

Prática DML
1 Insira um registro na tabela secretaria.alunos informando as colunas:

1=# INSERT INTO secretaria.alunos (id, nome, idade, email)
VALUES (1, 'Jose Silva', 28, 'jose.silva@dexter.com.br');
2 Insira um registro na tabela secretaria.alunos:
2=# INSERT INTO secretaria.alunos VALUES (2, 'Maria Santos',
20, 'maria.santos@dexter.com.br', 'SdeWd43dfSS4');
3 Atualize o campo senha do aluno de id 1:
3=# UPDATE secretaria.alunos SET senha = 'D34Dsw'
WHERE id = 1;
4 Remova o registro de id 2 da tabela alunos:
4=# DELETE FROM secretaria.alunos WHERE id = 2;
78
Syntax dos comandos:
Inserir um registro declarando as colunas:

INSERT INTO tabela (coluna1,coluna2) VALUES (valor1,valor2);
Inserir um registro declarando valor para todas as colunas:

INSERT INTO tabela VALUES (valor1, valor2, valor3);
Atualizar registro(s):
UPDATE tabela SET coluna = [valor]
[WHERE campo = condição];
Remover registro(s):
DELETE FROM tabela
[WHERE campo = condição];
Utilizando SELECT para inserir dados:

INSERT INTO tabela VALUES (SELECT * FROM outra_tabela);
Utilizando SELECT para remover dados:

DELETE FROM tabela WHERE coluna IN (SELECT * FROM outra_tabela);
Utilizando SELECT para atualizar dados:

UPDATE tabela SET coluna = valor WHERE ID = (SELECT id FROM
outra_tabela WHERE coluna = valor);
Algumas funções no PostgreSQL
1 Função CAST para converter un campo numeric em integer:

1=# SELECT CAST(283.84 AS INTEGER);
2 Função COALESCE para ver o primeiro argumento não nulo:

2=# SELECT COALESCE(NULL, 8, 2, 3);
3 Funções GREATEST | LEAST para valores máximos e mínimos:

3=# SELECT GREATEST(28,53,1,23,36);
4=# SELECT LEAST(28,53,1,23,36);
4 Função LENGTH para contar caracteres:

5=# SELECT LENGTH('4LINUX');
5 Função INITCAP para deixar aas primeiras letras maiúsculas:

6=# SELECT INITCAP('joel sanTANA');
79
Funções no PostgreSQL:
Há diversas funções disponíveis no PostgreSQL, essas funções são utilizadas

afim de auxiliar nas consultas e facilitar buscas e alterações de dados, há diversos
tipos como, conversão, filtros, numéricos, comparação, substituição etc.
A utilização dessas funções são bastante práticas e simples melhorando a
produtividade tanto do Desenvolvedor quanto do DBA.
Trabalhando com Carga de Dados
 Pode ser feita a partir de arquivos CSV ou texto

 Utilizar COPY ao invés de INSERT;
 Realizar transações por Blocos;
 Aumentar Shared Buffers;
 Desabilitar fsync somente para a carga inicial;
80
A carga de dados no PostgreSQL podem ser feitas de diversas formas

diferentes, INSERTS, COPY, dump, CSV, etc, porém vale a pena reforçar que uma
grande carga de dados ao ser realizada deve ser bem avaliada pois a forma de
inserção interfere diretamente na performance da carga de dados, até mais do que os
parâmetros utilizados no PostgreSQL.
Trabalhando com Carga de Dados

1 Crie o banco de dados bi e crie as tabelas para carga de dados:

1=# CREATE DATABASE bi;
2=# \c bi
3=# CREATE TABLE carga_insert (id int, valor text);
4=# CREATE TABLE carga_bloco (id int, valor text);
5=# CREATE TABLE carga_copy (id int, valor text);
6=# CREATE TABLE carga_csv (id int, valor text);
2 Meça os tempos de carga para cada situação:
6$ time psql bi < /opt/insert_comum_10k.sql
7$ time psql bi < /opt/insert_blocos_10k.sql
8$ time psql bi < /opt/insert_copy_10k.sql
81
Exportação e Importação de CSV

3 Exporte os dados da tabela carga_insert para um arquivo CSV:

1$ time psql d bi A F ";" c "select * from carga_insert;" >
insert_csv_10k.csv
4 Também é possível exportar para HTML:
2$ time psql d bi A H c "select * from carga_insert;" >
exemplo.html
5 Apague a primeira e a última linha do arquivo insert_csv_10k.csv
6 Faça a importação dos dados na tabela carga_csv:

6$time psql d bi c "COPY carga_csv (id, valor)
FROM '/var/lib/postgresql/insert_csv_10k.csv' WITH
DELIMITER AS ';';"
82
Fundamentos de SQL e Carga de Dados
Recapitulando
 Surgimento do SQL
 Operações DDL e DML
 Funções do PostgreSQL
 Carga de Dados
 Importação e exportação de CSV
83
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
CaracterísticasInterno
Funcionamento e Instalação do MySQL
e Parametrização
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Funcionamento Interno e Parametrização
Objetivos da Aula
 Conhecer a arquitetura por trás de um DML;
 Conceitos de Memória Compartilhada;
 Aprender sobre a integridade do PostgreSQL;
 Parametrização dos WAL files;
 Função do Checkpoint;
 Alterar parâmetros com ALTER SYSTEM;
85
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Processos do PostgreSQL
86
Processos do PostgreSQL:
O processo supervisor gerencia uma coleção de bancos de dados de uma

máquina. Esta coleção é chamada de agrupamento - cluster de banco de dados.
O processo supervisor gerencia vários processos servidor, sendo um processo
para cada conexão. Para ajudar o processo supervisor nessa tarefa de gerência,
alguns subprocessos, ilustrados na figura do próximo slide, desempenham as
seguintes tarefas:
Processos responsáveis pelo funcionamento do PostgreSQL, os processos em
vermelho, são os processos fundamentais para o funcionamento do PostgreSQL, os
em amarelo são processos importantes, porém não vitais, e os processos em verde
são os processos chamados pelos clients.
Background Writer: Escreve continuamente no disco o que está nos buffers

compartilhados de memória (shared buffers); apenas um processo com este nome
deve existir por cluster.
Checkpointer: Processo responsável pela gerência dos checkpoints, despejo
completo de buffers da memória para o disco e gerenciamento da rotação dos logs
adiantados de transação; este processo foi criado a partir da versão 9.2,
anteriormente o controle de checkpoints era feito pelo ``background writer'' e o
processo ''checkpointer'' não existia; apenas um processo com este nome deve existir
por cluster.
WAL Writer: faz a escrita dos logs adiantados de transação, toda vez que uma escrita
(modificação de dados) ocorre; é responsável pela garantia de que os dados escritos
estejam efetivamente em disco; apenas um processo com este nome deve existir por
cluster.
Statistics collector: Coleta estatísticas sobre o uso dos objetos dos bancos de
dados; apenas um processo com este nome deve existir por cluster.
Logger: Coleta todas mensagens da saída de erro e escreve em arquivos de log;
também gerencia a rotação desses arquivos de acordo com tempo e/ou tamanho;
apenas um processo com este nome deve existir por cluster, podendo não existir
dependendo da configuração.
Archiver: Arquiva os log de transação (WAL) em um local especificado, normalmente
para fins de backup contínuo; apenas um processo com este nome deve existir por
cluster, podendo não existir dependendo da configuração.
Autovacuum launcher: Dispara execuções de processos `àutovacuum worker''
quando apropriado; apenas um processo com este nome deve existir por cluster,
podendo não existir dependendo da configuração.
Autovacuum worker: Processos que fazem as rotinas de manutenção ANALYZE e
VACUUM automaticamente. Eles se conectam ao banco de dados e tabela
determinados pelo processo `àutovacuum launcher'', e fazem esses trabalhos;
nenhum ou vários processos com este nome podem existir por cluster dependendo do
momento.
Mapa de execução do DML
88
●
A estrutura do servidor PostgreSQL é modular. Na figura são apresentados os
principais módulos e o caminho que os comandos SQL percorrem ao serem
executados. Os comandos DML - Data Manipulation Language, tais como SELECT e
UPDATE, utilizam pelo menos os módulos analisador (parser), reescritor (rewriter),
otimizador (optimizer) e executor.
●Outros comandos são tratados de maneira diferente porque não precisam dos
módulos de reescrita, otimização e execução, e são tratados pelo módulo Utility

Commands.
As funções desempenhadas por esses módulos são descritas a seguir:
Parser: Faz a análise léxica e sintática de consultas SQL. A análise léxica produz uma
sequência de tokens (palavras chave) que serão utilizados durante a análise sintática
para produzir uma árvore (query tree) a partir de um conjunto de regras predefinidas.
Os tokens e sintaxe de um comando devem obedecer à especificação da linguagem
SQL;
Rewriter: Reescreve a árvore verificando a existência das tabelas, visões e colunas

necessárias à consulta solicitada.
Optimizer: Com a árvore validada pelo rewriter, tenta produzir um plano ótimo. O
optimizer traça os possíveis caminhos para execução de uma consulta e escolhe
aquele que tem o menor custo dos planos avaliados. Em consultas com muitas
junções, o planejador poderia gastar muitos recursos para determinar um plano ótimo
e utiliza um algoritmo mais rápido que não analisa todas as possibilidades, mas
oferece um plano bom
Executor: Executa o plano escolhido pelo optimizer e retorna o resultado ao cliente;
Utility Commands: Executa comandos DDL – Data Definition Language, como

CREATE e DROP, comandos DCL – Data Control Language, como GRANT e
REVOKE, e comandos diversos como COPY, CLUSTER e SAVEPOINT;
Access Method: Contém a API para manipular os diversos tipos de métodos de

acesso a dados suportados (B+-Tree, Hash, GiST e GIN). É utilizado por outros
módulos como Catalog, Optimizer e Executor;
Buffer Manager: Gerencia os buffers de memória compartilhada;
Catalog: É o local onde o PostgreSQL armazena metadados, como as informações

sobre tabelas e colunas, bem como informações para auxiliar na manutenção do
SGBD. O catálogo do sistema são tabelas e visões. Por exemplo, a adição de uma
coluna em uma tabela modifica o catálogo para que ele reflita a definição atual da
tabela;
Utilities: Contém rotinas de suporte tais como tipos de dados embutidos, funções
embutidas, rotinas de erro, rotinas de cache, rotinas de ordenação, gerenciador de
memória, gerenciador de funções e rotinas de suporte a codificação multibyte;
Lock Manager: Gerencia as travas (locks) entre as diversas sessões;
Transaction Manager: Gerencia as transações executados no SGBD. Os comandos

BEGIN, COMMIT, ROLLBACK, SAVEPOINT, ROLLBACK TO e RELEASE (chamados
às vezes de DTL – Data Transaction Language) são utilizados neste módulo para
alterar o estado do sistema.
Fluxo de dados - Leitura
Leitura(1) tenta realizar a leitura em cache;

Leitura(2) faz a leitura em disco;
90
Quando uma operação de consulta ou escrita é realizada ela interage com

diversos processos até chegar a base de dados. Em ambos os casos tudo começa
com a aplicação abrindo uma nova conexão que chega ao processo supervisor do
PostgreSQL.
Este cria um fork de si mesmo para atender esta conexão, esse fork age como
um processo de backend que trata a conexão, as transações e realiza o parsing das
operações.
Se for uma operação de leitura, seu primeiro passo após a interpretação do

comando é consultar a memória compartilhada, se ele encontrar a informação
necessária lá então ele a usará para retornar a requisição. No caso de não encontrar
a informação no cache o próprio backend vai até o cluster e obtêm a informação de lá
dos arquivos de dados. A Figura ilustra este tipo de comportamento.
Funcionamento Interno do PostgreSQL
91
Escrita definitiva no cluster:

● Checkpoint – Meio mais natural de ocorrer
● Background writer – Faz escrita de páginas em menor escala (páginas menos
utilizadas).
Escrita(1): Background escreve no arquivo de WAL;

Escrita(2): Background escreve no Shared Buffers;
Escrita(3): Background escreve direto na Tablespace;
Escrita(4): BGWriter escreve os dados do Shared Buffer em Disco em menor escala;
Escrita(5): Se necessário o Checkpoint escreve os dados do Shared Buffer em disco;
No caso de uma operação de escrita, o fluxo é mais complicado devido aos

vários passos que o backend realiza. Ao receber qualquer operação de modificação
de dados, o primeiro passo é enviar ao WAL writer, o processo responsável pela
gravação dos logs adiantados de transação no diretório pg_xlog.
Somente após sua confirmação, o backend tenta usar o cache para gravar
essa modificação. Se o backend não conseguir gravar no cache caso ele esteja cheio,
o próprio backend gravará as informação no diretório do cluster.
WAL (Write-Ahead Logging)
Conceito: Arquivos de log das transações

executadas, por segurança, cada ação no
banco de dados é registrada nesse log.
 Logs de transações binários de 16MB(default);

 São arquivos de “REDO”;
 Gravação e leitura feita por páginas de 8k(default);
 Garante a durabilidade da Transação
92
WAL (Write-Ahead Logging)
Todos os arquivos de dados no PostgreSQL, logs adiantados de transação

(WAL) e blocos de memória, são dividido em páginas, cada página contendo exatos 8
kB na compilação padrão.
O tamanho das páginas pode ser alterado, mas é necessário recompilar o
PostgreSQL. Para a maioria das aplicações, não existem ganhos significativos em
alterar o tamanho das páginas.
Nas aplicações em que isso apresentar algum ganho, é importante notar que
para a restauração de backup e criação de réplicas os binários devem ser compilados
exatamente da mesma forma.
Os logs de transação, arquivos WAL, são arquivos comuns, binários, com 16
MB cada na compilação padrão. Embora seja possível alterar o tamanho dos arquivos
WAL, isso não traz benefícios, pois o tamanho da área total ocupada pelos arquivos
WAL pode ser controlada por outros parâmetros de configuração, e os arquivos WAL
atuam em conjuntos de segmentos.
Quando o PostgreSQL escreve ou lê dados do disco, isto é feito por páginas.
Na escrita, se o parâmetro full_page_writes estiver desligado, pode existir escrita
parcial de páginas, o que não é recomendado na maioria dos casos.
Alguns Parâmetros do WAL

wal_buffers = 1 (default 4MB)
Buffers para escrita em WAL;
wal_writer_delay = 200ms
Delay da escrita em millisegundos;
wal_level = minimal
Nível de detalhe dos arquivos de WAL
1 Altere o parâmetro wal_buffers para 8M:

+ wal_buffers = 8MB
2 Reinicie o postgresql e valide conforme segue:

4 =# SHOW wal_buffers;
93
wal_buffers;
● Área de memória compartilhada;

● Buffer onde os dados a serem gravados no WAL são armazenados inicialmente;
●
Atualmente usar -1, uma espécie de auto tuning, que normalmente representa 3%
dos “shared buffers”.
Antes de serem gravados fisicamente em disco, os dados dos logs de
transação são armazenados em uma área de memória compartilhada denominada
wal_buffers, a qual tem seu conteúdo gravado em disco a cada commit.
O tamanho desta área é definido na opção wal_buffers o que por padrão nas
últimas versões do PostgreSQL utiliza o valor -1, o qual representa um espécie de
auto tuning pois dessa forma seu tamanho é de aproximadamente 3% o valor dos
shared buffers.
Aumentar este valor pode ajudar em servidores onde existem muitas
transações concorrentes, porem o aumento excessivo pode causar picos de IO
devido a grande quantidade de dados sendo gravados de uma única vez. Na maioria
dos casos o valor automático é suficiente.
Shared Buffers
Conceito: Área da memória compartilhada

utilizada para cache de leitura e escrita
 Memória compartilhada alocada na inicialização;

 Área de buffer/chache de Leitura e Escrita;
 Divididos em blocos limpos(=disco) e sujos(<> disco);
 Recomenda-se não utilizar mais de 40% RAM do server;
 Valores acima de 8GB não traz ganhos significativos;
94
WAL e o Shared Buffers
O PostgreSQL, por ser um banco de múltiplos processos, utiliza uma área de

memória compartilhada denominada shared buffer para cache de leitura e escrita.
Devido a escrita ser realizada nos “shared buffers” é necessário ter garantias
do que foi gravado, pois os dados estão em memoria e ainda não foram persistidos
em disco. Esta garantia é obtida através dos logs adiantados de transação
denominados WAL (Write Ahead Log).
Shared Buffers
Os shared buffers, conforme citado anteriormente, são uma região de memória
compartilhada utilizada como buffer/cache de escrita e leitura comum a todos os
backends. Esta região tem seu tamanho limitado ao definido na opção
shared_buffers.
Ao iniciar o PostgreSQL, este segmento de memória sera totalmente alocado.
O sistema operacional deve estar configurado para aceitar a quantidade de memória
compartilhada especificada aqui.
O valor padrão típico é 128MB, mas este valor pode ser menor devido a
algumas configuração do ser sistema operacional. Esse valor também pode ser
definido em unidades de memória (kB, MB ou GB). Para bom desempenho em
produção, este valor deve ser aumentado, pois o valor padrão vem definido somente
para permitir a inicialização do banco. Este assunto será abordado em capítulo futuro.
De maneira geral recomenda-se que o tamanho dos shared buffers não
ultrapassem 40% do tamanho da memoria RAM, e também não ultrapassem a faixa
dos 4GB a 8GB. Existem limitações em ambiente Windows que tornam o uso de
grandes quantidades de shared buffer inviável. Em testes realizados, valores maiores
que 256MB causaram degradação do desempenho.
Ajustando parâmetros com ALTER SYSTEM

1 Altere o parâmetro shared_buffers com o comando ALTER SYSTEM:

1 =# ALTER SYSTEM SET shared_buffers = '256MB';
2 Agora valide se a alteração surtiu efeito:
2=# SHOW shared_buffers;
3=# \! cat /etc/postgresql/9.6/main/postgresql.conf |
grep shared_buffers
3 Reinicie o postgresql e valide conforme segue:
4=# SHOW shared_buffers;
5=# \! cat /etc/postgresql/9.5/main/postgresql.conf | grep

shared_buffers
6=# \! cat /var/lib/postgresql/9.5/main/postgresql.auto.conf
95
Parâmetros de configuração:
ALTER SYSTEM
A versão 9.4 do PostgreSQL adicionou uma nova cláusula SQL chamada ALTER
SYSTEM. Com este comando, você pode editar diretamente as configurações do
arquivo posqtgresql.conf. Se faz necessário em alguns parâmetros a reinicialização
do Postgresql, ou reload dependendo do contexto.
Alterar um parâmetro com ALTER SYSTEM:

ALTER SYSTEM SET parametro = ‘valor’;
Exibir um parâmetro:
SHOW parametro;
Shared Buffers e o BGWriter
Processo responsável pela escrita dos

blocos sujos do Shared Buffers em Disco.
bgwriter_delay = 200ms
Intervalo de execuções do BGWriter em milisegundos.
bgwriter_lru_maxpages = 200
Quantidade máxima de páginas por rodada do BGWriter.
bgwriter_lru_multiplier = 2.0
Fator de multiplicação onde (qtd paginas anterior * lru_multiplier);
96
O background writer (também chamado de bgwriter) é um processo responsável pela

escrita dos bloco sujos (dirty) dos shared buffers no disco. O objetivo é que processos
backends não tenham que aguardar por escritas em disco, o background writer fará
isso.
Como visto anteriormente o bgwriter utiliza o algoritmo de LRU (Least Recently
Used) para decidir quais blocos devem ser gravados. Ele é ativado em intervalos de
tempo definidos pela opção bgwriter_delay.
Para evitar picos de IO, existe um número máximo de páginas que podem ser
escritas por rodada, este número é definido na opção bgwriter_lru_maxpages'.
A cada rodada o bgwriter define a quantidade de páginas a serem gravadas,
baseado na média das paginas removidas em rodadas anteriores junto com um
multiplicador que é definido na opção bgwriter_lru_multiplier. Este multiplicador
permite que o número previsto seja igual à média anterior (1.0), menor que a média
anterior (< 1.0) ou maior que a média anterior (> 1.0).
Utilizar o multiplicador prevê uma proteção contra picos de atividade do banco
de dados, pois mais buffers limpos serão deixados no cache. O número máximo de
buffers em bgwriter_lru_maxpages será, todavia, sempre respeitado.
Valores muito baixos nos parâmetros do background writer reduzem o I/O
causado por ele, mas tornará mais provável que os processos de sessão do
PostgreSQL façam escritas por eles mesmos, prejudicando o desempenho de escrita
do PostgreSQL.
Ajustando o BGWriter para bancos Transacionais

1 Edite o arquivo postgresql.conf ajustanto o bgwriter:
+ bgwriter_delay = 100ms
+ bgwriter_lru_maxpages = 300
+ bgwriter_lru_multiplier = 3.0
2 Faça o reload do serviço do postgresql:

2 # service postgresql reload
97
Utilizar shared buffers muito grandes podem denegrir o desempenho do banco, pois o
bgwriter terá de varrer uma quantidade de blocos muito grande, o que vai levar a um
tempo mais longo de execução e assim desperdiçar recursos sem necessidade.
O PostgreSQL foi desenhado pensando na utilização do cache do sistema de

arquivos do sistema operacional, por isso que nem sempre é necessário alocar
grandes quantidades de shared buffer para se obter bom desempenho.
O uso maior de shared_buffers normalmente é desejado em ambientes de

maior taxa de modificações de dados, enquanto nos ambientes de maior leitura (mais
SELECT), prefere-se deixar mais memória disponível pro cache do próprio sistema
operacional.
WAL e Checkpointer
Faz a escrita dos dados Shared Buffers em Disco

permitindo a remoção dos arquivos de WAL antigos.
checkpoint_timeout = 5min
Limite de tempo para execução do Checkpoint;
max_wal_size = 1GB
Limite de tamanho da área de WAL para execução do Checkpoint;
min_wal_size = 80MB
Tamanho mínimo da área de WAL para execução do Checkpoint;
checkpoint_completion_target = 0.5
Fator de escala de tempo de execução de checkpoint;
checkpoint_warning = 30s
Intervalo mínimo entre checkpoints caso ultrapasse um log é gerado.
98
Quando o número de segmentos disponíveis se esgota, ocorre um checkpoint,

que é o ponto onde os dados em shared buffer serão efetivamente gravados em disco
para que seja possível eliminar os segmentos atuais e criar novos.
Os checkpoints são necessários, pois sem eles haveria a necessidade de
manter todos os logs de transação indefinidamente:
●Ponto onde os dados em “shared buffer” serão efetivamente gravados em disco, para
que seja possível eliminar os segmentos atuais e criar novos;

●
Necessários, pois sem eles os WAL não poderiam ser eliminados.
●Quando esgota o tempo definido na variavel checkpoint_timeout;
Dica: será exibido log caso ocorram mais de uma vez no período definido na opção:
checkpoint_warning;
LOG: checkpoints are occurring too frequently (x seconds apart)
O ideal é que os checkpoints ocorram preferencialmente por esgotamento do
tempo, pois caso ocorram por falta de segmentos com muita frequência podem
prejudicar o desempenho, devido a carga de I/O gerada na gravação dos “shared
buffers” em disco.
Uma dica será exibida no log do PostgreSQL caso os checkpoints ocorram em
períodos inferiores à opção “checkpoint_warning”
Aumentar o número de segmentos pode ajudar no desempenho do banco,
porém, deve-se tomar o cuidado de não aumentar demais, pois quando ocorrer um
crash o tempo de recuperação sera muito grande devido a necessidade de aplicar
todos estes segmentos.
Verifique seu tempo de SLA e faça testes para saber a quantidade de
segmentos aceitável no seu ambiente.
Alterando o Checkpoint
1 Verifique o numero do processo do checkpointer:

1 # ps ef | grep checkpointer
2 Veja agora quem está lendo o pg_xlog:

2 # lsof | grep pg_xlog
3 Altere o parâmetro checkpoint_timeout:

3=# SHOW checkpoint_timeout;
4=# ALTER SYSTEM SET checkpoint_timeout = 200;
5=# SELECT pg_reload_conf();
6=# SHOW checkpoint_timeout;
99
Com o intuito de suavizar picos de I/O durantes os checkpoints o PostgreSQL

utiliza uma técnica espalhamento da gravação em determinado tempo. Este tempo é
uma fração do tempo (em caso de checkpoint por tempo) ou número de segmentos
(em caso de checkpoint por esgotamento de segmentos) que levaram o checkpoint a
ocorrer, esta fração é definida na opção “checkpoint_completion_target”.
Utilizando o valor default:
Se o Checkpoint ocorreu por tempo;

●checkpoint_timeout = 300;
●checkpoint_completion_target = 0.5;
O tempo de gravação será espalhada em:

300 * 0.5 → 150 segundos.
Após as alterações:
Se o Checkpoint ocorreu por tempo;

●checkpoint_timeout = 200;
●checkpoint_completion_target = 0.5;
O tempo de gravação será espalhada em:

200 * 0.5 → 100 segundos.
WAL - fsync
Fsync
Garante a escrita em disco (não fica no chache do SO);
Por default é habilitado para garantir a escrita em disco;
Desabilitar ou alterar o “wal_sync_method” não é recomendado.
fsync = on
Habilita ou desabilita o fsync;
wal_sync_method = fsync
Métodos de sincronia da escrita dos arquivos de WAL;
full_page_writes = on
Cada escrita ocupa uma página inteira, desabilitar esse parâmetro
pode comprometer a integridade dos dados na recuperação.
100
Afim de se assegurar de que toda gravação de WAL esteja gravada fisicamente

em disco, a cada gravação é executado um “fsync”, para garantir que nada fique em
cache do S.O. ou discos.
É possível desabilitar este comportamento na opção “fsync” e com isso

aumentar consideravelmente o desempenho de escrita, porém o risco de perda de
dados é altíssimo. Recomenda-se que nunca se desabilite esta opção, exceto em
casos bem específicos que serão mostrados posteriormente.
-fsync é uma chamada de sistema operacional utilizada para garantir que dados
estejam gravados fisicamente em disco, eliminando a possibilidade dos dados ficarem
apenas em cache para posterior gravação.
Esta chamada só retorna sucesso após ter escrito todos dados fisicamente em
disco. Desta informação conclui-se que é muito importante que os discos do banco de
dados tenham alto desempenho, para que a chamada retorne o mais rápido possível,
aumentando a capacidade transacional do banco de dados.
A chamada “fsync”' possui algumas variantes dependendo do S.O. , o PostgreSQL

permite a escolha de qual chamada utilizar na opção wal_sync_method'. As opções
possíveis são:
●open_datasync: Opção para Solaris;

●
fdatasync: Recomendado para bom desempenho em Solaris e Linux(Versão maior
que 2.6.18);
●fsync_writethrough: Força escrita sem cache de controladora, quando suportado;
●fsync: Padrão POSIX, esta presente na maioria dos S.O.;
●open_sync: Recomendado para bom desempenho em Linux até a versão 2.6.18 do
kernel;
É importante escolher o método mais adequado para o seu S.O. para o melhor
desempenho e segurança dos dados em disco.
Caso seja selecionado um método que não esta disponível no S.O. o

PostgreSQL não inicia e emite um aviso no log.
Em caso de uma queda durante uma gravação de pagina modificada é possível que
após a recuperação do arquivo existam uma mistura de dados antigos e novos. Para
evitar que isto aconteça, o PostgreSQL, por padrão, efetua gravação de paginas
completas por vez, independente da quantidade de dados a serem gravados.
Armazenar toda página garante que ela poderá ser recuperada corretamente
mas o preço para isso é o aumento da quantidade de dados escritos pelo log de
transação. Este comportamento pode ser desativado através da opção
full_page_writes', porém apesar de melhor desempenho, os riscos são similares ao de
desativar o fsync', e por isso não é recomendada sua desativação.
As garantias de gravação podem ser desligadas em situações controladas,

como em cargas massivas de dados, sempre que for possível ou aceitável "perder"
alguns dados recentes. Sempre que for executar operações desse tipo, faça
imediatamente antes delas um backup de base ou dump que permita restaurar seus
dados da forma como estavam antes da atividade.
WAL – Commits Síncronos e Assíncronos
Síncrono
Depois da escrita em WAL a transação é confirmada;
Assíncrono
Depois da escrita em WAL a transação é confirmada;
Aglomera commits em frações de microsegundos;
synchronous_commit = on
Level de sincronia entre o commit e a escrita em WAL.
commit_delay = 0
Delay entre os commits em microsegundos.
commit_siblings = 5
Métodos de sincronia da escrita dos arquivos de WAL;
102
Por padrão o PostgreSQL efetua commits síncronos, o que significa que a

transação só é efetivada após o log da transação estar efetivamente gravado em
disco. Este comportamento pode ser desativado através da opção
synchronous_commit' o que leva a gravação dos logs serem de forma assíncrona, ou
seja, a transação é efetivada antes de que exista garantia que esteja gravada em log
de transação.
Quando em modo assíncrono a gravação deve ocorrer no período de até três

vezes o valor definido na opção wal_writer_delay a qual define o intervalo entre as
rodadas do WAL writer.
Assim como o fsync, este parâmetro cria um risco de perda de transações

efetivadas. Somente desabilite este parâmetro se você confia no sua infraestrutura ou
se a performance é mais importante do que a durabilidade de transações.
Esse parâmetro pode ser alterado a qualquer momento. Então é possível

efetivar algumas transações de maneira síncrona ou assíncrona; para isso, basta, por
exemplo, definir SET LOCAL synchronous_commit TO off dentro de uma transação
para efetivá-la de modo assíncrono.
Commit Assincrono:
●
Aglomerar transações concorrentes em único “fsync”;
●Commit atrasado;
●O tempo de espera é definido em “commit_delay”;
●
O número mínimo de transações simultâneas para aguardar é definido em
“commit_siblings”;
●Pode reduzir carga de IO em servidores muito concorridos. No entanto, em
servidores de baixa concorrência, pode diminuir o desempenho;
●Sem risco;
Em servidores com muitas transações concorrentes onde a carga de IO é muito

alta, é possível aglomerar vários commits em um único fsync utilizando o recurso de
commit atrasado, o qual consiste em esperar uma quantidade de tempo e ou
transações antes de realizar o fsync e retornar os commits.
Para habilitar este recurso deve-se alterar o valor padrão da opção

commit_delay de 0 (valor padrão) para a quantidade de microssegundos que deseja
esperar por outras transações. Em paralelo deve-se ajustar também a opção
commit_siblings na qual deve-se definir o mínimo de transações simultâneas para que
o PostgreSQL aguarde o tempo definido em commit_delay por novos commits.
Exemplo:
Supondo que temos commit_delay definido em 200 e commit_siblings definido

em 10 e o servidor atualmente tem 50 transações concorrentes. Quando uma
transação finalizar neste cenário ela vai aguardar 200 µs antes realizar commit.
Este recurso pode reduzir a carga de I/O no pg_xlog' em servidores muito

concorridos sem trazer risco de perda de dados. Todavia, o tempo médio de gravação
de dados vai aumentar um pouco.
Funcionamento Interno e Parametrização
Recapitulando
 Conhecer a arquitetura por trás de um DML;
 Conceitos de Memória Compartilhada;
 Aprender sobre a integridade do PostgreSQL;
 Parametrização dos WAL files;
 Função do Checkpoint;
 Alterar parâmetros com ALTER SYSTEM;
104
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características e Instalação do
Transações, Estatísticas MySQL
e Locks
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Transações, Estatísticas e Locks
Objetivos da Aula
 Lógica de uma transação;
 Níveis de isolamento de transação;
 Locks e DeadLocks;
 Conceitos MVCC;
 Vacuum e Analyze;
 Autovacum;
106
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Composição de uma Transação
BEGIN DML / DDL COMMIT

Registra o
Confirmar
Início da Execução
Execução
Transação
ROLLBACK ID
ID da
Desfazer transação
Comandos
107
BEGIN:
Sinaliza o início de uma transação.
DML / DDL:
Manipulação e consulta de dados dentro da transação.
COMMIT:
Grava efetivamente todas as alterações realizadas e finaliza a transação.
ROLLBACK:
Desfaz as alterações sem alterar os dados.
ID:
Identificador único da transação.
Inicio – Meio e Fim da transação

1 Verifique o identificador da transação e faça testes:

1=# SELECT txid_current();
3=# BEGIN;
5=# CREATE TABLE teste (id int);
6=# INSERT INTO teste VALUES (10);
7=# SELECT * FROM teste;
9=# ROLLBACK;
11=# SELECT * FROM teste;
108
A transação que alterou o dado já terá a nova versão, assim como novas
transações que venham após o término daquela que fez a alteração, respeitando
totalmente a norma ACID.
O MVCC funciona internamente de maneira igualmente simples. Ao alterar uma

linha em uma tabela, o PostgreSQL não altera a linha original, mas sim, cria uma
nova linha semelhante, com as alterações solicitadas. Essa nova linha é chamada de
nova versão.
Para identificar as versões, o PostgreSQL utiliza duas colunas xmin e xmax, e

utilizando o número de transação – xID – . Na coluna xmin é definido a partir de qual
transação esta tupla é visível, na xmax até qual transação a tupla é visível
O número das transações é sequencial de 32 bits. Cada transação recebida

pelo PostgreSQL recebe esse número.
Características das Leituras
Dirty Read Leitura suja de transações ainda não “commitadas”.
Nonrepeatable Leitura dos dados na posição do inicio da transação.

Read
Phantom Read Leitura a partir dos dados já “commitados” mesmo
que a transação seja anterios ao “commit”;
Serialization As transações são realizadas sequencialmente
Anomaly permitindo impedindo a concorrência.
109
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Nível de Isolação das Transações

Nível de isolação Dirty Read Nonrepeatable Phantom Serialization
Read Read Anomaly
READ POSSÍVEL POSSÍVEL POSSÍVEL POSSÍVEL

Não vale no
UNCOMMITED PG
READ IMPOSSÍVEL POSSÍVEL POSSÍVEL POSSÍVEL

COMMITED
REPEATABLE IMPOSSÍVEL IMPOSSÍVEL POSSÍVEL POSSÍVEL
Não vale no PG
READ
SERIALIZABLE IMPOSSÍVEL IMPOSSÍVEL IMPOSSÍVEL IMPOSSÍVEL
Nota: READ COMMITED é o Default do PostgreSQL
110
Ajuste do nível de transação
O Nível de transação pode ser alterado com o comando “SET SESSION”

conforme exemplo:
SET TRANSACTION ISOLATION LEVEL {SERIALIZABLE | REPEATABLE READ
| READ COMMITTED | READ UNCOMMITTED} ;]
No PostgreSQL o nível de isolamento READ UNCOMMITED não é possível,

assim o PostgreSQL trata como o READ COMMITED.
Locks e Deadlocks
Locks
 Impede que outra transação altere a tupla;

 Podem ser Implícitos ou Explícitos;
 Compartilhados ou exclusivos;
Deadlock
 Quando 2 transações entram em um “loop”;

 Acontece para que a aplicação não pare;
111
O uso de locks no PostgreSQL pode ser implícito em algumas operações, ou

de forma explicita (solicitada pelo cliente). Os locks podem ser exclusivos ou
compartilhados.
Situações onde uma transação depende da liberação de um lock de uma

segunda transação para finalizar, porem a segunda também depende da primeira é
chamada de deadlock. Pelo fato dos deadlocks serem uma situação onde as
transações são dependentes entre si, elas ficarão aguardando indefinidamente e
nunca seriam finalizadas.
Para evitar que transações em deadlock fiquem presas para sempre, o

PostgreSQL utiliza um tempo de timeout definido na opção deadlock_timeout para
finalizar transações neste estado.
Forçando um LOCK
1 Na base dbdexter abra 2 sessões e faça conforme segue:
1S1=# BEGIN;
2S1=# UPDATE secretaria.alunos SET senha = '100'
WHERE id = 1;
3S2=# BEGIN;
WHERE id = 1;
5S1=# COMMIT;
6S1=# SELECT * FROM secretaria.alunos;
7S2=# COMMIT;
8S2=# SELECT * secretaria.alunos;
112
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Forçando um DEADLOCK
1 Na base dbdexter abra 2 sessões e faça conforme segue:
1S1=# BEGIN;
WHERE id = 1;
3S2=# BEGIN;
WHERE id = 2;
WHERE id = 2;
WHERE id = 1;
9S1=# SELECT * FROM secretaria.alunos;
113
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
MVCC (Multi Version Concurrency Control)
Garantir a atomicidade das tuplas alteradas

por vários processos simultãneamente.
 Permite a aderência ACID;

 Concorrência das tuplas por várias transações;
 Controle das tuplas por versionamento;
 Garante a durabilidade da Transação
114
O controle de versão é a característica do PostgreSQL que permite que ele

atenda plenamente à norma ACID. O MVCC permite o isolamento entre as diversas
transações de banco de dados ocorrendo simultaneamente.
O princípio de funcionamento de um controle de versão é simples: uma

transação deve manter consistência durante sua vida, mesmo que outras transações
estejam modificando os dados ao mesmo tempo. Na prática, os dados utilizados por
uma transação só podem ser modificados por ela mesma, para ela.
Mas como fazer com que uma transação que alterou um dado não propague
esta alteração para uma transação concorrente?
Alguns bancos de dados implementam o full row lock, ou trava completa da

linha. Se uma linha foi alterada por uma transação, transações concorrentes não
podem visualizar esta linha, até que a transação que a modificou termine. Isto não
implementa completamente a norma ACID.
O MVCC implementado pelo PostgreSQL utilize um modelo share row lock, ou

trava compartilhada da linha. Quando uma linha é alterada por uma transação ela
pode ser lida por outra transação simultânea, porém, essa transação simultânea verá
uma versão do dado original, até que termine sua vida.
MVCC – Verificando versionamento

1 Crie uma tabela no schema financeiro no banco de dados dbdexter:
1=# CREATE TABLE financeiro.contratos (id int, empresa
varchar(50), vencimento date, valor numeric);
2 Agora acompanhe o versionamento dos registros inseridos:
2=#INSERT INTO financeiro.contratos VALUES
(1,'Janelas', '20171201','1000000.00');
3=#INSERT INTO financeiro.contratos VALUES
(2,'PadocaX', '20180701','5000.00');
4=# BEGIN;
5=# INSERT INTO financeiro.contratos VALUES

(3,'Zeca', '20161201','1000.00');
6=# INSERT INTO financeiro.contratos VALUES
(4,'Zica', '20161201','2000.00');
7 =# SELECT txid_current();
8=# COMMIT;
115
A transação que alterou o dado já terá a nova versão, assim como novas
transações que venham após o término daquela que fez a alteração, respeitando
totalmente a norma ACID.
O MVCC funciona internamente de maneira igualmente simples. Ao alterar uma

linha em uma tabela, o PostgreSQL não altera a linha original, mas sim, cria uma
nova linha semelhante, com as alterações solicitadas. Essa nova linha é chamada de
nova versão.
Para identificar as versões, o PostgreSQL utiliza duas colunas xmin e xmax, e

utilizando o número de transação – xID – . Na coluna xmin é definido a partir de qual
transação esta tupla é visível, na xmax até qual transação a tupla é visível
O número das transações é sequencial de 32 bits. Cada transação recebida

pelo PostgreSQL recebe esse número.
MVCC – Verificando versionamento
6 Abra uma segunda sessão sem fechar a primeira e execute:

1S2=# BEGIN;
2S2=# SELECT txid_current();
3S2=# SELECT xmin, xmax, empresa FROM financeiro.contratos;
4S1=# BEGIN;
5S1=# SELECT txid_current();
6S1=# DELETE FROM financeiro.contratos WHERE empresa = 'Zica';
8S1=# ROLLBACK;
10S2=# COMMIT;
11S2=# UPDATE financeiro.contratos
SET empresa = 'Zoca' WHERE id = 4;
13S2=# \q
116
Nesse exemplo podemos observar claramente o funcionamento do

versionamento das tuplas, onde o xmin significa o numero de transação em que
o registro foi criado, enquanto o xmax significa até que transação o registro
esteve visível.
Vacuum e Analyze
Tuplas Mortas
Update, Delete
Insert (quando ocorre rollback);
Vacuum
 Marca tuplas obsoletas para reaproveitamento;

Analyze
 Gera estatísticas da tabela;

117
Como visto anteriormente, no modelo MVCC, algumas operações deixam

tuplas mortas nas tabelas, de forma que é necessário existir um mecanismo para
prevenir o acumulo destas tuplas, pois do contrario as tabelas iriam crescer
indefinidamente e ficarem inchadas de tuplas mortas. Para que isso não ocorra o
PostgreSQL possui um mecanismo chamado vacuum, o qual marca tuplas mortas de
uma tabela para reaproveitamento.
Operações que geram tuplas mortas:
●UPDATE
●DELETE
●INSERT (somente quando ocorre rollback)
Vale ressaltar que o vacuum não elimina as tuplas mortas, ele apenas as
marca para serem reutilizadas por novos dados modificados na tabela.
Tuplas Mortas e Vacuum
1 Faça uma consulta nos registros verificando o xmin e xmax:

1=# SELECT xmin, xmax, empresa FROM financeiro.contratos;
2 Execute o DELETE abaixo:

2=# DELETE FROM financeiro.contratos WHERE id = 4;
3 Agora verifique as tuplas mortas da tabela::

3=# SELECT relname,n_live_tup,n_dead_tup
FROM pg_stat_user_tables
WHERE relname = 'contratos';
4 Execute o ANALYZE e verifique novamente as tuplas mortas:
4 =# ANALYZE financeiro.contratos;
5 Agora execute o VACUUM e verifique novamente
4 =# VACUUM financeiro.contratos;
118
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Autovacuum
Executa ANALYZE e VACUUM periodicamente

baseado em métricas estabelecidas.
 Recomendável manter habilitado;

 Geralmente não impacta na performance;
 Boa prática é monitorar gerando logs (min_duration);
 É ajustável por meio de parâmetros;
119
Agendar ou executar o vacuum e o analyze manualmente não são maneiras

eficientes de manter seu banco de dados, pois as operações realizadas por
aplicações na maioria dos bancos de dados não seguem uma ordem cronológicas
fixa.
Para manter seu banco livre de tuplas mortas e com as estatísticas
constantemente atualizadas o PostgreSQL utiliza-se do autovacuum, que é o
mecanismo que dispara operações de vacuum e analyze conforme necessidade.
Autovacuum é um processo fundamental para o PostgreSQL e não deve
impactar no desempenho banco, porem é possível desabilitá-lo na opção
autovacuum.
Para manter histórico e auxiliar em futuros ajustes é possível registrar em log
as operações realizadas pelo autovacuum através da opção
log_autovacuum_min_duration. Nesta opção definimos o tempo mínimo de execução
para que seja registrada, caso definido para 0 todas as operações serão registradas.
A memória utilizada pelas operações de vacuum e analyze são limitadas ao
valor definido na opção maintenance_work_mem, caso este valor seja ultrapassado a
operação continua, porem utilizando arquivos temporários em disco.
É importante ajustar este valor corretamente, pois se for muito pequeno
acarreta na demora para finalização dos processos de vacuum ou analyze e se for
muito grande pode levar o servidor a utilizar swap e prejudicar o desempenho do
banco.
Um bom número para se utilizar na autovacuum_max_workers é o número de
tabelas grandes(que se destacam) acrescido de 1, pois dessa forma mesmo que os
processos fiquem muito tempo nas tabelas grandes, sempre terá um processo
sobrando para outras tabelas.
Parametrização do Autovacuum
autovacuum = on
Habilitar ou não.
log_autovacuum_min_duration = 1
Duração mímina para gerar LOG.
autovacuum_max_workers = 3
Quantidade de processos que podem rodar em paralelo.
autovacuum_vacuum_threshold = 50
Numero de tuplas alteradas antes do VACUUM.
autovacuum_analyze_threshold = 50
Numero de tuplas alteradas antes do ANALYZE.
autovacuum_vacuum_scale_factor = 0.2
Fator de escala em % da tabela antes do VACUUM.
autovacuum_analyze_scale_factor = 0.1
Fator de escala em % da tabela antes do ANALYZE.
autovacuum_vacuum_cost_delay = 20ms
Tempo de espera antes de medir o custo do autovacuum.
autovacuum_vacuum_cost_limit = 1
Tempo limite para execução do autovacuum antes do delay.
120
O autovacuum possui uma série de opções que determinam quando as

operações devem executadas:
●autovacuum_max_workers: Número máximo de processos autovacuum (exceto o
lançador autovacuum) que possam estar em execução a qualquer momento. O

padrão é três. Este parâmetro só pode ser definido na inicialização;
●autovacuum_naptime: Especifica o atraso mínimo entre autovacuum executado em
um determinado banco de dados. Em cada rodada o daemon examina o banco de

dados e questões VÁCUO e analisar comandos conforme necessário para tabelas no
banco de dados. O atraso é medido em segundos, e o padrão é um minuto (1min);
●autovacuum_vacuum_threshold: Número mínimo de tuplas atualizadas ou
removidas para disparar um VACUUM em uma tabela. (Valor padrão: 50);
●autovacuum_analyze_threshold: Número mínimo de tuplas inseridas, atualizadas
ou removidas para disparar um ANALYZE em uma tabela. (Valor padrão: 50).

●autovacuum_analyze_scale_factor: Fração da tabela a adicionar sobre
autovacuum_analyze_threshold ao decidir quando disparar um VACUUM. (Valor
padrão: 0.1);
●autovacuum_vacuum_cost_delay: Especifica o intervalo de tempo a esperar após
atingido o limite de custo do VACUUM. Um valor -1 fará com que seja obedecido o
parâmetro vacuum_cost_delay.(Valor padrão: 20ms);
●autovacuum_vacuum_cost_limit: Especifica o custo limite que pode ser atingido
pelo VACUUM antes de esperar pelo tempo em autovacuum_vacuum_cost_delay. Um

valor -1 fará com que vacuum_cost_limit seja obedecido. O custo a ser atingido será a
somatória dos custos de todos os processos que estiverem rodando
simultaneamente. (Valor padrão: -1).
As opções acima podem ser configurados por tabela.
Teste prático Autovacuum

1 Crie uma e faça as validações na view pg_stat_all_tables:

1=# DROP TABLE teste;
2=# CREATE TABLE teste (id int);
3=# INSERT INTO teste (id)
SELECT id FROM GENERATE_SERIES(1,100000) id;
4=# ANALYZE teste;
5=# SELECT * FROM pg_stat_all_tables WHERE relname = 'teste';
6=# UPDATE teste SET id = 0 WHERE id <= 10000;
8=# UPDATE teste SET id = 0 WHERE id = 11000;
10=# DELETE FROM teste WHERE id > 20000;
11=# SELECT * FROM pg_stat_all_tables
WHERE relname = 'teste';
121
Levando em conta os valores padrões e supondo que a tabela X tenha 100

registros, a operação de vacuum só sera disparada quando o número de tuplas
modificadas/inseridas for 50 + (100*0.2) = 70, e operação de analyze quando o
número de tuplas modificadas/inseridas for de 50 + (100*0.1) = 60.
Os valores padrões de autovacuum_vacuum_threshold e

autovacuum_analyze_threshold, na maioria dos casos, são relativamente altos e
podem acabar deixando muito trabalho acumulado o que podem causar picos de
atividade. O ideal é que se evite estes picos, e que se mantenha o autovacuum
trabalhando continuamente e assim evitando acumulo de trabalho.
Inicialmente pode-se utilizar valores por volta de 0.05 para

autovacuum_vacuum_threshold e 0.02 para autovacuum_analyze_threshold.
Vacuum Freeze
 O versionamento das tuplas são realizados pelos XIDs;

 O XID é um numero inteiro de 32 bits = 4Bilhões;
 Antes de atingir esse limite o Freeze remarca o XID;
autovacuum_freeze_max_age = 200000000
XID máximo para geração do FroozenXID e o vacuum freeze;
autovacuum_multixact_freeze_max_age = 400000000
XID limite para execução de um vacuum na tabela;
122
O modelo MVCC, o PostgreSQL utiliza o número de transação (XID) para

determinar a visibilidade da tuplas. O XID é um número inteiro de 32bits, o que
limitaria a 4 bilhões de transações até que tenha que ser zerado.
Porém esta volta ao 0 poderia trazer problemas, pois todas as tuplas estariam
no futuro e não seriam mais acessíveis. Para evitar que isto ocorra, antes que se
atinja o limite o vacuum marca as tuplas com um XID especial denominado
FroozenXID, de modo a indicar que esta tupla encontra-se no passado.
Durante a execução do vacuum todas as tuplas analisadas que tiverem idade
(em número de transações) maior que o valor definido em vacuum_freeze_min_age
terão seus XIDs substituídos pelo o FroozenXID.
Sabe-se que o vacuum, por padrão, só analisa as páginas onde existem tuplas
mortas, porem é necessário que a tabela seja analisada por completo quando alcança
determinada idade, a qual é definida em vacuum_freeze_table_age.
Através da opção autovacuum_freeze_max_age é definido o limite de idade
para que seja executado vacuum em uma tabela (mesmo com o autovacuum
desligado).
Vacuum Full
 Executa o Vacuum em toda a tabela;

 É necessário espaço equivalente ao tamanho da tabela;
 Normalmente não é necessário;
 Utilizado para casos extremos;
 Dump e restore é mais rápido;
123
O vacuum full é um comando que só pode ser realizado manualmente, e ao

contrario do ``vacuum'' ele realmente remove as tuplas mortas e diminui o tamanho
físico da tabela pois a tabela é copiada e totalmente reescrita.
O vacuum full, tem vários aspectos negativos:
● Para realizar esta operação é necessário ter espaço livre em disco equivalente ao
dobro do tamanho atual da tabela, pois a tabela é duplicada durante a operação
(versão 9.1 ou superior).
●É um processo lento (foi aprimorado na versão 9.1)
●Faz lock exclusivo em toda a tabela.
●Recomenda-se recriar os índices após esta operação.
●
Não pode ser executado sobre tabelas em produção.
Com o autovacum ativado e bem configurado, não existe necessidade de se

utilizar o vacuum full. O vacuum full só deve ser utilizado em casos extremos.
A operação de vacuum full pode ser substituída pela exportação e importação

(pg_dump e pg_restore). Nas versões 9.0 ou anteriores, prefira a operação cluster ao
invés do vacuum full. Ela é similar ao funcionamento do vacuum full nas versões 9.1
ou superiores e também permite organizar a tabela na ordem de um índice.
Arquitetura e Processos do PostgreSQL
124
Agora podemos ter uma noção melhor sobre o funcionamento do PostgreSQL

e sua arquitetura com um fluxo mais completo:
Processos do servidor:
Postmaster = Primeiro processo
Background = As conexões
BRWriter = Escrita nos Datafiles
Checkpointer = Escrita nos Datafiles
WAL Writer = Escrita nos WAL files
Archiver = Escrita dos Archives
Logger = Escrita dos LOGs
Statistics Collector = Coletor de estatísticas
Autovacuum Launcher = Processo que dispara os Vacuums
Autovacuum Worker = Processo do Vacuum.
Principais parâmetros de memória:

Shared Buffers = Memória Compartilhada
WAL Buffers = Buffers para escrita de WAL
Work Mem = Memória para utilização das conexões do PostgreSQL
Maintenance Work Mem = Memória para atividades de Manutenção na base
Transações, Estatísticas e Locks
Recapitulando
 Lógica de uma transação;

 Níveis de isolamento de transação;
 Locks e DeadLocks;
 Conceitos MVCC;
 Vacuum e Analyze;
 Autovacum;
125
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
Backup ee Instalação do MySQL
Restauração
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Backup e Restauração
Objetivos da Aula
 Backup pontual com pg_dump e pg_dumpall;

 Configuração do Archive ;
 Backup PITR;
 Restauração de backup PITR;
127
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Tipos de Backup
COLD-Backup
 Offline – PostgreSQL Indisponível;

 Realizar uma cópia dos dados;
HOT-Backup
 Online – PostgreSQL Disponível;

 Pode ser Pontual (não incremental);
 PITR que é incremental – perca de dados é
mínima.
128
Backup Pontual
pg_dump
 Backup por base / tabela;

 Tamanho entre 10 e 50% do tamanho da base;
 É online;
pg_dumpall
 Backup de todo o cluster;

 Backup lógico dos dados;
129
Backups pontuais são aqueles que guardam as informações no momento em

que foram criados. Imagine que, num ambiente de produção, dados são inseridos,
alterados e removidos o tempo todo dos bancos de dados. Portanto, um backup
pontual permitirá ao administrador recuperar os dados em um ponto no passado,
quando o backup foi executado.
Backups pontuais no PostgreSQL são feitos com o comando pg_dump, e seu
uso básico é: pg_dump [banco de dados] > [arquivo.dump]
Pode-se utilizar uma extensão .sql para dumps textuais. O pg_dump possui
opções úteis como -t (fazer backup apenas de uma tabela) e -F c (arquivo próprio do
pg_restore, comprimindo com zlib). As opções de conexão do psql são aceitas, como
usuário, hostname, porta e etc.
Dumps de bancos de dados tem, geralmente, de 10 a 50% do tamanho
ocupado em disco por um banco de dados em produção, portanto, não se assuste.
Recomenda-se que o usuário que faça o backup seja um superusuário, dono
do banco de dados sendo feito backup ou, pelo menos, tenha acesso de leitura em
todos os objetos do banco de dados. O diretório onde estará o arquivo de backup
deve possuir permissão de escrita para o usuário do sistema operacional que estiver
executando o comando pg_dump.
O backup pode ser feito com o banco de dados funcionando, normalmente.
Note, porém, que durante o processo é feita uma cópia completa de cada tabela, o
acesso a disco será intenso, portanto, escolha horários de menor movimento
transacional para execução de dumps quando grandes tabelas estão envolvidas.
Scripts automatizados e agendados podem ser utilizados para backups, desde
que seja sempre verificada a saída do comando executado para garantir que não
aconteceram erros durante o processo.
Realizando Backup Pontual

1 Crie um backup pontual full do Cluster:
1 # pg_dumpall > bkp_full_cluster5432.sql
2 Crie o backup do banco de dados dbdexter:
2 # pg_dump dbdexter > bkp_dbdexter.sql
3 Crie o backup do banco de dados dbdexter com inserts:
3 # pg_dump dbdexter inserts > bkp_dbdexter_i.sql
4 Crie o backup binário do banco de dados dbdexter:
4 # pg_dump F c dbdexter > bkp_dbdexter_bin.dump
5 Crie o backup da tabela alunos no dbdexter:
5# pg_dump d dbdexter t secretaria.alunos >
bkp_dbdexter_alunos.sql
130
O comando pg_dumpall para faz um backup completo de um cluster:

pg_dumpall > arquivo.sql
As opções de conexão estilo psql são possíveis também. Todas os papéis,
bancos de dados e permissões serão copiadas em formato textual. Informações dos
catálogos de sistema do PostgreSQL não são copiadas.
Crie um cluster novo com initdb. Utilize o psql como usuário postgres para
recuperação:
psql < arquivo.sql
As opções de conexão como hostname e porta são possíveis.
Observação importante: dumps fazem cópias apenas das informações internas
do cluster. Será necessário copiar manualmente arquivos de configuração.
Observação muito importante: backups de cluster contém comandos que
recriam tablespaces, porém, os diretórios onde residem devem existir antes da
recuperação, na mesma localização original.
Há diversas formas de realizar o backup pontual com o pg_dump e o
pg_dumpall, mais informações podem ser extraidas com a execução do comando
com a cláusula --help, um ponto muito importante é:
Geração de backups pontuais default com string SQL:

1) Gera comandos SQL num arquivo;
2) Não permite o restore parcial;
3) É menos performático que o Binário;
Geração de backups pontuais Binários:

1) Gera um arquivo binário;
2) Permite o restore parcial;
3) É mais performático;
Restore do DUMP
 É necessário ter um cluster íntegro;

 O serviço do PostgreSQL deve estar Operante;
 Com o dump binário é possível paralelizar restore;
 Pode ser utilizado para migração de versão;
 É necessário ter estrutura de diretórios equivalente;
 Com o pg_restore é possível filtrar restore;
131
Para a realização do Restore de um DUMP, primeiramente é necessário ter um

cluster íntegro e funcional e com o PostgreSQL no ar para então inicializar o processo
de restauração pois esse backup é lógico portanto os dados serão interpretados e
aplicados no cluster para a restauração.
Utilizando o pg_restore, é possível segmentar e filtrar os dados que serão
restaurados, dessa forma o restore fica mais limpo não tendo a necessidade de
restaurar todo o banco de dado.
Em relação a performance a partir do dump binário também é possível realizar
uma restauração paralela abrindo diversas conexões no banco de dados, dessa
forma reduzindo o tempo de restore caso o hardware corresponda a alteração.
Um ponto importante é que como o pg_dump se trata de um backup lógico a
sua restauração consiste basicamente em comandos de criação de objetos e dados,
dessa forma é necessário além do Cluster íntegro, a criação de todos os diretórios
que hospedarão as tablespaces de acordo com o destino das tablespaces.
Restaurando um Backup Pontual

1 Crie o banco de dados restore com o usuário postgres:

1 $ createdb restore
2 Restaure o banco de dados dbdexter no banco restore com o psql:

3 $ psql restore < bkp_dbdexter.sql
3 Crie o banco restore2 e restaure a estrutura dos schemas:

3 $ createdb restore2
4 $ pg_restore s d restore2 < bkp_dbdexter_bin.dump
4 Com a estrutura ok, restaure somente os dados da tabela alunos:
5$ pg_restore a t alunos d restore2 <
bkp_dbdexter_bin.dump
132
Um usuário com direitos para tal deve criar o banco de dados conforme já
vimos em capítulo anterior. Se o banco de dados já existir, recomenda-se limpá-lo
primeiro, exceto se o dump foi criado com a opção de destruir objetos já existentes.
Para restaurar um dump textual, utilize o psql, assim:

psql [banco de dados] < [arquivo.sql]
Utilize as opções de conexão necessárias como hostname, usuário, etc.
Para dumps comprimidos do pg_restore (opção -F c do pg_dump), será obrigatório

utilizar o pg_restore:
pg_restore -d [banco de dados] [arquivo.dump]
As opções de conexão estilo psql também são aceitas.
As opções acima não restauram papéis de usuário e grupo. Devem ser

recriados manualmente de preferência antes da restauração. Também não são
copiadas as tablespaces. As mesmas tablespaces utilizadas devem ser criadas
manualmente antes da restauração.
PITR (Point In Time Recovery)
Backup Full e Incremental para

restauração em um certo ponto no tempo.
 Somente Backup FULL do Cluster;

 É incremental;
 Permite volta no tempo;
 É necessário habilitar archive;
 É mais performático que o pg_dump;
133
O PITR permite apenas cópias completas de clusters, inclusive usuários,

regras, privilégios, etc. Embora pareça complicado, uma vez habilitado o PITR é muito
simples de administrar.
A estratégia de backup PITR inicial pode ser feita com o servidor de banco de
dados funcionando normalmente. Como os arquivos de dados serão totalmente lidos
pelos comandos executados, tenha em mente que existirá um aumento do consumo
de I/O que pode afetar as transações normais. Prefira horários de baixo movimento
transacional para o backup inicial.
A maior vantagem do PITR é que o cluster terá um backup contínuo e
incremental. A estratégia consiste em avisar ao PostgreSQL que um backup será
feito. O PostgreSQL marcará então qual foi esse momento. Depois, pode-se copiar
normalmente os arquivos dos diretórios de dados e tablespaces sem se preocupar
com suas alterações durante o backup. O PostgreSQL gravará as modificações feitas
nos arquivos WAL. Após a finalização do backup o recurso de archiving manterá uma
alimentação contínua de arquivos WAL para o local de backup especificado.
Portanto o PITR mantém dois momentos: a cópia inicial e o arquivamento
contínuo. Reserve espaços especiais em disco para eles.
Outra vantagem do PITR é justamente seu nome: recuperação em momento
no tempo. O administrador poderá retornar o backup em qualquer momento no tempo
desde o backup inicial até o momento da falha. Isto é muito útil em situações em que
um usuário executou um comando que destruiu dados em determinado momento do
dia, ou se uma nova versão de uma aplicação fez alguma bagunça com seus dados
após um deploy.
WAL e Archive
WAL
 Arquivo de registro das transações;
Archive
 Backup do WAL;
wal_level = replica
Nível de detalhe da geração dos arquivos de WAL
archive_mode = on
Habilitar ou não o Archive.
archive_command = 'comando'
Comando para fazer o backup dos WAL files;
archive_timeout = 60
Limite de tempo para geração de archive;
134
Para habilitar o PITR utilizamos o recurso archiving no postgresql.conf:

●wal_level=archive
●archive_mode = on
●archive_command = 'comando de cópia do WAL para Archive'
O comando deve retornar 0 em caso de sucesso. Se um comando que não

retorna 0 for utilizado, ou se o comando falhar por algum motivo (diretório cheio, por
exemplo), o PostgreSQL manterá os arquivos não copiados no diretório pg_xlog. Isto
precisa ser monitorado pelo administrador. Após o sucesso, o respectivo arquivo de
log de transações será apagado ou renomeado para reuso pelo PostgreSQL, evitando
fragmentação do sistema de arquivos.
Comandos interessantes a utilizar em archive_command:
cp i %p /dir/archives/%f > /dev/null
Para copiar os arquivos WAL para o diretório /dir/archives
scp %p IP:/dir/archives/%f > /dev/null
Para enviar os arquivos WAL para a máquina IP no diretório /dir/archives. Neste
caso, a máquina de destino deve ter um servidor ssh e chaves públicas trocadas
adequadamente.
A variável %p é o caminho completo do arquivo WAL original do PostgreSQL e
%f é apenas o nome dele. Portanto, os comandos irão literalmente copiar o arquivo
de pg_xlog para o diretório escolhido pelo administrador.
Pelo fato de os segmentos somente serem copiados quando estiverem
completos, em bancos com poucas transações os segmentos vão levar um tempo
considerável para serem completados e em consequência o backup pode ficar muito
atrasado. No entanto essa situação pode ser evitada definindo um tempo máximo a
ser aguardado pelo preenchimento do segmento, o que é definido através da opção
archive_timeout'.
Colocando a Base em Archive

Servidor dbmaster – Usuário root
1 Crie os diretórios e dê as permissões com o usuário root:
1# mkdir p /pg_backup/base
2# mkdir p /pg_backup/arquivamento
3# chown R postgres. /pg_backup
4# chmod R 700 /pg_backup
2 Faça as alterações nos parâmetros do postgresql.conf:

+ wal_level = replica
+ archive_mode = on
+ archive_command = 'cp %p /pg_backup/arquivamento/%f
> /dev/null'
3 Reinicie o PostgreSQL.
135
Após o sucesso, o respectivo arquivo de log de transações será apagado ou

renomeado para reuso pelo PostgreSQL, evitando fragmentação do sistema de
arquivos.
Comandos interessantes a utilizar em archive_command:
cp i %p /dir/archives/%f > /dev/null
Para copiar os arquivos WAL para o diretório /dir/archives
scp %p IP:/dir/archives/%f > /dev/null
Para enviar os arquivos WAL para a máquina IP no diretório /dir/archives. Neste
caso, a máquina de destino deve ter um servidor ssh e chaves públicas trocadas
adequadamente. A variável %p é o caminho completo do arquivo WAL original do
PostgreSQL e %f é apenas o nome dele. Portanto, os comandos irão literalmente
copiar o arquivo de pg_xlog para o diretório escolhido pelo administrador.
Pelo fato de os segmentos somente serem copiados quando estiverem
completos, em bancos com poucas transações os segmentos vão levar um tempo
considerável para serem completados e em consequência o backup pode ficar muito
atrasado. No entanto essa situação pode ser evitada definindo um tempo máximo a
ser aguardado pelo preenchimento do segmento, o que é definido através da opção
archive_timeout'.
Exemplos de estratégias
1) cópia dos arquivos WAL para um diretório nfs, drdb ou outra partição e depois um
rsync acionado pelo cron é interessante para garantir um backup local e remoto ao
mesmo tempo.
2)Uma estratégia combinada pode ser a chamada de um shell script pelo
archive_command. Este script pode fazer as duas coisas, uma cópia para a partição
local e um envio via rsync para um servidor remoto. Tome precauções para que o
script retorne 0 quando for bem sucedido e qualquer outro valor em caso de falha.
Backup PITR – Backup Base
Servidor dbmaster – Usuário postgres
1 Sinalize o início do backup para o PostgreSQL:
1 $ psql c "SELECT pg_start_backup('backup1');"
2 Faça uma cópia dos dados e da tablespace:
2$ cp av /var/lib/postgresql/9.6/main/* /pg_backup/base/
3$ mkdir /pg_backup/base/tablespace
4$ cp av /tbsdexter /pg_backup/base/tablespace
3 Sinalize o término do backup:

3 $ psql c "SELECT pg_stop_backup();"
136
A partir da versão 9.1 existe uma ferramenta chamada pg_basebackup, esta

ferramenta facilita o trabalho de realizar um backup base, pois ela implicitamente
efetua o pg_start_backup'', copia os arquivos e efetua o pg_stop_backup. Esta
ferramenta sera mostrada no capitulo de replicação.''
\end{Nota}
Dentro do diretório pg_xlog vai existir um arquivo nomeado
XXXXX.YYYYY.backup. Todos os arquivos anteriores (em ordem hexadecimal) podem
ser deletados do seu diretório de backup.
O arquivo XXXXX e os arquivos subsequentes serão enviados normalmente
pelo archive_command, o que pode levar algum tempo após a conclusão do backup,
dependendo da carga do sistema e dos meios de comunicação utilizados.
Atenção: se estiver fazendo vários backups iniciais, apague somente os
arquivos WAL mais antigos que o seu backup inicial mais antigo mantido.
Procedimentos básicos do Backup:

1) Sinalizar início do backup com o comando:
SELECT pg_start_backup('label');
2) Copiar arquivos da base com ferramenta de preferência.
3) Sinalizar término do backup com o comando:

SELECT pg_stop_backup();
Restore da Base PITR – Parte 1

1 Crie o diretório para restore e um de backup dos arquives.
1$ mkdir /var/lib/postgresql/9.6/restore
2$ mkdir /pg_backup/bkp_archive
2 Copie os dados, configuração e archives:
3# cp av /pg_backup/base/* /var/lib/postgresql/9.6/restore
4# cp av /pg_backup/arquivamento/* /pg_backup/bkp_archive/
5# cp av /etc/postgresql/9.6/main/*
/var/lib/postgresql/9.6/restore
3 Sinalize o local da tablespace dexter no arquivo tablespace_map:
6# vim /var/lib/postgresql/9.6/restore/tablespace_map
+ <Tablespace OID>
/var/lib/postgresql/9.6/restore/tablespace/tbsdexter
137
A recuperação total por PITR é muito simples:
● Pare o PostgreSQL.
● Limpe mova seu diretório do cluster.
●
Copie todo o seu backup inicial para seu cluster original, lembre-se de tablespaces.
●Crie um arquivo recovery.conf dentro do diretório do cluster. O conteúdo do arquivo
deve ser: restore_command = 'cp /dir/WAL/%f "%p"'

●
Onde /dir/WAL é o diretório onde estão os arquivos WAL arquivados pelo
archive_command''.
● Ajuste as permissões de seu \emph{cluster} com:
chmod -R 700 /dir/cluster/

chown -R postgres /dir/cluster/
●Inicie seu cluster normalmente. Os arquivos de transação serão processados e, em

seguida, banco de dados funcionando. A recuperação pode ser acompanhada no log.

4 Edite o novo arquivo de configuração do PostgreSQL:
1$ vim /var/lib/postgresql/9.6/restore/postgresql.conf
+data_directory = '/var/lib/postgresql/9.6/restore'
+hba_file = '/var/lib/postgresql/9.6/restore/pg_hba.conf'
+ident_file = '/var/lib/postgresql/9.6/restore/pg_ident.conf'
+external_pid_file = '/var/run/postgresql/9.6main5433.pid'
+port = 5433
5 Remova o arquivo de pid:

$ rm rf /var/lib/postgresql/9.6/restore/postmaster.pid
2
138
Exemplos demonstrados nos slides:

Como não queremos destruir nosso banco de dados atual, vamos criar um
outro cluster do PostgreSQL usando o backup do cluster atual para a recuperação
dos dados, para isso foi necessário realizar algumas alterações no procedimento
default para restauração do PITR, porém a lógica é a mesma.
Procedimentos básicos do Restore:
1) Com o PostgreSQL fora do ar, limpar o diretório que será restaurado:

$ rm rf /var/lig/postgresql/9.6/main/*
2) Copiar backup da base no diretório de dados:

$ cp /pg_backup/base/* /var/lig/postgresql/9.6/main/
3) Se necessário, realizar mapeamento de tablespace no arquivo tablespace_map.

$ vim /var/lig/postgresql/9.6/main/tablespace_map
4) remover arquivo de PID caso ele exista.

$ rm rf /var/lig/postgresql/9.6/main/postmaster.pid
5) Criar e e ditar o arquivo recovery.conf com as informações para restauração:

$ vim /var/lig/postgresql/9.6/main/recovery.conf
6) Iniciar o PostgreSQL
# service postgresql start

6 Crie o arquivo de restauração:
1$ vim /var/lib/postgresql/9.6/restore/recovery.conf
+ restore_command = 'cp /pg_backup/bkp_archive/%f %p'
7 Altere as permissões do diretório e inicie o cluster na porta 5433:

2# chmod R 700 /var/lib/postgresql/9.6/restore/
3# chown R postgres. /var/lib/postgresql/9.6/restore/
3# su postgres
4$ /usr/lib/postgresql/9.6/bin/pg_ctl D
/var/lib/postgresql/9.6/restore/ start
8 Faça as validações
5$ ps ef | grep postgres
6$ psql p5433
139
O arquivo recovery.conf
O arquivo recovery.conf contém as informações necessárias para o restore, a
informação mínima para ser contida nesse arquivo é o parâmetro “restore_command”,
esse parâmetro recebe os dados de onde o PostgreSQL vai ler os arquivos de archive
durante a recuperação, porém outros parâmetros podem ser acrescentados.
A sequência de comandos fará com que seu cluster seja recuperado por
completo até o último arquivo WAL existente no seu backup. Caso deseje voltar para
um momento específico no tempo, tenha em mente que não é possível voltar para um
momento antes do backup inicial. Para recuperações em momento no tempo, insira a
seguinte linha em recovery.conf:
recovery_target_time = ‘’ (timestamp)
Onde timestamp é o momento onde se deseja o estado do cluster. Ele é no
formato do PostgreSQL como 'YYYY-MM-DD HH:MM:SS'.
recovery_target_xid = ‘’
Especificar até que XID a recuperação deve ser feita.
recovery_target_inclusive = 'true'
True = Recuperação logo após o recovery_target_time ou xid.
False = Recuperação até uma transação antes do recovery_target_time ou xid.
recovery_target_timeline = 'latest'
Para recuperação dentro de uma timeline utilizando o pg_control como
referência.
Backup e Restauração
Recapitulando:
 Backup pontual com pg_dump e pg_dumpall;

 Configuração do Archive ;
 Backup PITR;
 Restaurando backup PITR;
140
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características
BARMAN (Backupeand
Instalação do MySQL
Recovery Manager)
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
BARMAN (Backup and Recovery Manager)
Objetivos da Aula
 Instalando o BARMAN
 Arquivo de parâmetros;
Troca de chaves;
 Validação e backup;
 Restaurando backup;
 Backup via streaming;
142
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Ferramenta OpenSource escrita em Python para

gerenciamento dos backups do PostgreSQL
 Pode ser utilizada para backups remotos;

 Gera Catálogo de Backups;
 Política de retenção;
 Recuperação remota de Cluster;
 Faz backups dos arquives;
143
A ferramenta barman possui as seguintes características:
●
Backup físico completo a quente de um servidor PostgreSQL.
●Gerenciamento de vários servidores PostgreSQL.
●Recuperação remota e local de backup para um servidor PostgreSQL.
●Suporte ssh para operações remotas.
●Status e informações do servidor.
●
Compressão de arquivos WAL (bzip2, gzip ou personalizado).
●Integração com ferramentas de arquivamento padrão (por exemplo, tar).
●Pré/pós backup de scripts de gancho.
●
Arquivo de configuração INI simples.
●Point-In-Time-Recovery (PITR).
●Backup remoto de um servidor PostgreSQL.
●Gestão de backups de base e arquivos do WAL através de um catálogo.
●Gestão de políticas de retenção para backups e arquivos de WAL.
●
Remanejamento de PGDATA e espaços de tabela no momento da recuperação.
●Geral e do disco informações sobre o uso de backups.
●Diagnósticos servidor para backup.
●
Suporte a rsync sobre ssh para sincronização de arquivos e transferências.
BARMAN – Procedimentos de Instalação

Execute as ações no Servidor backup
1 Adicione o repositório, a chave e atualize a lista de repositórios:
deb http://apt.postgresql.org/pub/repos/apt/ jessiepgdg
main
4# aptget update
2 Instale o barmam com o apt-get install:

5 # aptget install barman
144
Roteiro de instalação:
● O pacote do barman esta disponível no repositório APT do Postgres para Ubuntu;

● É preciso configurar o arquivo sources.list na máquina Storage na iniciar a
instalação;
●Em seguida obtenha a chave pública do repositório pgdg e a instale (validar os
pacotes);
●
Atualize a lista de pacotes e instale o pacote barman.
BARMAN – Arquivo de parâmetros

1 Edite o arquivo de configuração conforme segue:
1# vim /etc/barman.conf
barman_home = /var/lib/barman/backups
minimum_redundancy = 0
[dbmaster]
description = "Servidor PostgreSQL DB Master"
ssh_command = ssh postgres@dbmaster.dexter.com.br
conninfo = host=dbmaster.dexter.com.br user=barman
password=4linux dbname=postgres
archiver = on
retention_policy = RECOVERY WINDOW OF 2 DAYS
145
Configuração do Barman
A configuração do barman é feita através do arquivo barman.conf localizado no

diretório /etc. Acompanhe a descrição de algumas diretivas relevantes na
configuração do barman.
● Sessão [barman]: Contem configurações relacionadas ao servidor barman:

●
barman_home: Diretório onde o barman vai armazenar os backups.
●barman_user: Nome do usuário do barman.
●log_file: Localização onde os logs do barman serão gravados.
●compression: Tipo de compressão para realizar o backup.
●configuration_files_directory: Diretório que o barman utiliza para separar sua
configuração em arquivos por servidor.

●minimum_redundancy: Número mínimo de backups requeridos (redundância).
●retention_policy: Política de retenção.
●
Sessão [main]: Contem configurações relacionadas ao servidor Postgres que o
barman vai gerenciar os backups:
●description: Define a descrição do servidor Postgres.
●ssh_command: Comando ssh usada para acessar o servidor Postgres.
●conninfo: Informações de conexão do servidor Postgres (nome, usuário, senha,
banco).
●compression: Opções de compressão.
Para cada servidor Postgres é necessário criar uma sessão com um nome que
identifique seu cluster.
BARMAN – Configuração do Storage

1 Crie a estrutura de diretórios para armazenar os backups:
1# mkdir p /var/lib/barman/backups/dbmaster/incoming
3# mkdir p /var/lib/barman/backups/audit/incoming
4# chmod 750 /var/lib/barman R
5# chown barman:barman /var/lib/barman R
146
Preparar área de armazenamento para backups:
● Vamos utilizar o LVM e RAID que a máquina File Server possui, com uma área de
armazenamento de 40GB para receber os dados das máquinas DB Master e Audit;
●
A máquina possui um volume lógico de 40GB grupo storage com sistema EXT4;
●É preciso fazer a montagem da nova partição na home do usuário barman.;
●Configure a montagem automática na inicialização do sistema;
●
Em nosso exemplo a partição possui apenas 40GB, podendo ser estendida com a
adição de novos discos no RAID.
●Em seguida crie os diretórios para cada servidor que o Barman ira gerenciar os
backups;
●Para terminar altere a permissão de acesso para o usuário barman no ponto de
montagem.
BARMAN – Troca de chaves SSH

Execute as ações no Servidor dbmaster
1 Instale o rsync com o usuário root:

# aptget install rsync
1
2 Crie uma chave ssh e o authorized_keys para o usuário postgres:
2$ sshkeygen <Enter 3x>
3$ cat ~/.ssh/id_rsa.pub > ~/.ssh/authorized_keys
4$ chmod 600 ~/.ssh/authorized_keys
3 Copie as chaves para o servidor backup com o usuário root:

5# rsync avz ~postgres/.ssh/authorized_keys backup:~barman/.ssh/
6# rsync avz ~postgres/.ssh/id_rsa* backup:~barman/.ssh/
147
Configuração de chaves SSH
● É preciso configurar a comunicação SSH bidirecional entre os servidores barman e

postgres;
●
Para começar logue com o usuário postgres e crie o par de chaves ssh através do
comando ssh-keygen;
●Em seguida envie a chave pública para o arquivo authorized_keys.
●
Através do comando rsync envie os arquivos authorized_keys, chave publica e
privada para o servidor de backup, no login do usuário do Barman.
BARMAN – Troca de chaves SSH

1 Altere as permissões conforme abaixo:

1# chown R barman. /var/lib/barman/.ssh
2# chmod 700 /var/lib/barman/.ssh
3# chmod 600 /var/lib/barman/.ssh/authorized_keys
4# chmod 600 /var/lib/barman/.ssh/id_rsa
5# chmod 755 /var/lib/barman/.ssh/id_rsa.pub
2 Realize o teste de conexão com o usuário barman:

6# su barman
7$ ssh postgres@dbmaster.dexter.com.br
3 Dentro do usuário postgres tente conectar no servidor backup:
8 $ ssh barman@backup.dexter.com.br
148
Configuração de chaves SSH
● É preciso configurar a comunicação SSH bidirecional entre os servidores barman e

postgres;
●
Para começar logue com o usuário postgres e crie o par de chaves ssh através do
comando ssh-keygen;
●Em seguida envie a chave pública para o arquivo authorized_keys.
●
Através do comando rsync envie os arquivos authorized_keys, chave publica e
privada para o servidor de backup, no login do usuário do Barman.
Após a troca de chaves e os ajustes do permissionamento é necessário realizar

os testes de conexão entre os servidores até mesmo para que a conexão entre os
servidores sejam inseridas no cache do linux na lista de servidores confiáveis.
BARMAN – Configuração do Database

Execute as ações no Servidor dbmaster
1 Crie o usuário barman com privilégios de SUPERUSER:
1 =# CREATE ROLE barman LOGIN SUPERUSER PASSWORD '4linux';
2 Edite o arquivo pg_hbs.conf:

+ host postgres barman 192.168.200.80/32 md5
3 Altere o local de geração dos archives:
archive_command = 'scp %p barman@backup.dexter.com.br
:/var/lib/barman/backups/dbmaster/incoming/%f >
/dev/null'
149
Configuração do Postgres
●
É necessário criar um usuário no PostgreSQL com privilégios de SUPERUSER para
a realização do backup.
●É necessário ajustar o comando de arquivamento, que agora sera feito via scp;
BARMAN – Validação e Backup
Informativos:
1 Liste, verifique e exiba detalhes do servidor:
1# barman listserver
2# barman switchxlog force dbmaster
3# barman check dbmaster
4# barman showserver dbmaster
Comandos de Gerenciamento:
2 Faça o Backup do dbmaster:
5 # barman backup dbmaster
3 Liste os backups realizados e os arquivos:
6# barman listbackup dbmaster
7# barman showbackup dbmaster <Backup ID>
8# barman listfiles dbmaster <Backup ID>
150
Comandos Informativos:
Listar servidores gerenciados pelo barman:
barman listserver
Checar conexão com um servidor Postgres:
barman check dbmaster
Exibir detalhes de configuração de um servidor Postgres:
barman backup dbmaster
Comandos de gerenciamento
Executar backup completo:
barman backup dbmaster
Listar backups de um servidor Postgres:
barman listbackup dbmaster
Exibir informações de um backup:
barman showbackup dbmaster <BACKUP_ID>
Listar arquivos armazenados no backup:
barman listfiles dbmaster <BACKUP_ID>
Apagando backup:
barman delete dbmaster <BACKUP_ID>
BARMAN – Restore
Servidor dbmaster
1 Simule um desastre no servidor dbmaster:
1# service postgresql stop
2# rm rf /var/lib/postgresql/9.6/main
Servidor backup
2 Faça a recuperação do backup full com o usuário barman:
3$ barman recover dbmaster <BACKUP_ID>
/var/lib/postgresql/9.6/main remotessh
command="ssh postgres@dbmaster.dexter.com.br"
Servidor dbmaster
3 Inicie o PostgreSQL no servidor dbmaster:
151
Restauração local do backup completo:

barman recover dbmaster <BACKUP_ID> /tmp/backup
Restauração remota do backup completo:

barman recover dbmaster <BACKUP_ID> remotesshcommand=”ssh
postgres@remoteserver”
Restauração remota do backup completo determinando o timestamp:

barman recover dbmaster <BACKUP_ID> remotesshcommand=”ssh
postgres@remoteserver” targertime “YYYMMDD HH:mm:ss”
BARMAN – Backup com streaming
Servidor backup
1 Edite o arquivo barman.conf
1# vim /etc/barman.conf
+streaming_conninfo=host=dbmaster.dexter.com.br
user=barman password=4linux dbname=postgres
+backup_method = postgres
+streaming_archiver = on
+slot_name = barman
Servidor dbmaster
2 Edite o arquivo postgresql.conf
3$ vim /etc/postgresql/9.6/main/postgresql.conf
+max_replication_slots = 2
+max_wal_senders = 2
152
Backup utilizando streaming é uma forma de backup que utiliza slot de replicação,
de forma que o servidor de backup recebe todas as transações do banco no momento
que elas são concluídas.
A principal vantagem é que temos um backup instantâneo de todas as transações
que ocorre no banco, sendo que em caso de crash, a perda de dados é quase
inexistente. Outra vantagem é que como o arquivamento de wal é realizado pelo
barman, podemos desativar o arquivamento do banco, reduzindo o uso do espaço em
disco no servidor de banco.
Em caso de queda na comunicação do servidor de backup com o servidor de
banco, o arquivamento é executado no banco, através do uso de slots, ao retornar a
comunicação, os arquivos de wal que estavam sendo arquivado no banco, são
transferidos para o backup via streaming e reciclados.
Servidor dbmaster:
3 Edite o arquivo pg_hba.conf e reinicie o banco:
2# host replication barman 192.168.200.80/32 md5
4 Reinicie o banco e crie o slot no banco:
1# /etc/init.d/postgresql restart
2# su – postgres
3$ psql
4$ SELECT * FROM
pg_create_physical_replication_slot('barman');
5$ select * from pg_replication_slots;
153

Servidor backup
5 Verifique a utilização do processo receive-wal:
1$ barman check dbmaster
2$ ps ef | grep postgres
barman 1291 1289 0 10:34 ? 00:00:00
/usr/lib/postgresql/9.6/bin/pg_receivexlog
dbname=dbname=replication
host=dbmaster.dexter.com.br password=4linux
replication=true user=barman
application_name=barman_receive_wal verbose no
loop nopassword –
directory=/var/lib/barman/backups/dbmaster/
streaming slot=barman
154
Objetivos da Aula
 Instalando o BARMAN
 Arquivo de parâmetros;
Troca de chaves;
 Validação e backup;
 Restaurando backup;
 Backup via streaming;
155
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Tunning Linux do MySQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Tunning PostgreSQL & Linux
Objetivos da Aula
 Reconhecimendo de Hardware no Linux;

 Alteração de parâmetros do Kernel;
 Características dos Filesystems;
 PGBouncer - Pooler de conexões;
 Particionamento de tabelas;
157
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Ciclo Básico de Solução de Performance
158
Reconhecimento o Hardware
1 - Discos e Controladoras
 Utilizar Storage;
 Usar Raid 10;
2 - Memória RAM
 ECC (detecção de erros);
 Proporcional a utilização do Banco;
3 - CPU
 Proporcional ao numero de conexões;
 Maior clock possível;
4 - Rede
 Segmentar Rede;
 Utilizar Cabeamento certificado;
159
Ao determinar os recursos de hardware, é importante avaliar a qualidade. Nem

todas as CPUs são iguais e nem todas as controladoras RAID são iguais. É
necessário avaliar estatísticas, benchmarks, conselhos de especialistas em hardware
e, principalmente, de especialistas em SGBDs. Alta performance em SGBDs só é
alcançada caso se conheça muito bem o hardware.
Ao ser consultado sobre que hardware comprar, o DBA deve dar preferência
para os seguintes itens, em ordem.
Discos e controladoras
Discos formam o recurso mais consumido pelos bancos de dados, e não
estamos falando apenas do espaço ocupado.
Eles são os componentes vitais de um SGBD. Quanto mais poderoso o seu
sistema de discos, melhor a performance do SGBD.
Discos de rotação mais rápida (10.000 ou 15.000 rpm) garantirão tempos de
acesso a dados mais rápidos. A utilização de RAID 1+0 (RAID 10) é a combinação
mais favorável para bancos de dados pois ele alia segurança e desempenho.
Sistemas de storage do tipo SAN – Storage Area Network utilizando fibras
ópticas são os mais indicados. Discos high-end com muito cache podem ser
necessários para aplicações OLTP mais pesadas. Multipath aumenta a banda
disponível em canais de fibra e aumenta a disponibilidade.
Múltiplos discos e RAID arrays separados para tabelas e índices muito
acessados são importantes. Separar os arquivos WAL (diretório pg_xlog) em um
grupo só para eles garantirá a melhor performance nas aplicações com muita escrita.
Outro ponto importante é escolher controladoras que possuam bateria, afim de
possibilitar o uso do seu cache de forma segura e eficaz.
Memória RAM
• ECC;
• Registrada;
• OLAP maior quantidade de RAM;
• OLTP menor quantidade de RAM;
• Mais conexões, mais memória.
Quanto mais RAM melhor. Para maior estabilidade, prefira memórias com
detecção e correção de erro (ECC) e com registradores (registered).
Aplicações OLAP (relatórios e estatísticas) com bancos de dados Data
Warehouse precisarão de muita memória enquanto bancos de dados OLTP (transações
rápidas) terão um consumo mais modesto. Muitas conexões exigirão muita memória.
Em aplicações OLAP, o ideal é que a memória RAM disponível consiga
armazenar as ordenações e operações com tabelas hashes, como agregações e
junções.
Processador
• Maior clock;
• 64bits;
• Grande número conexões, mais cores;
O escalonamento com múltiplos processadores não é linear. Poucos

processadores rápidos são mais eficientes do que muitos processadores lentos.
Apesar de ser quase o último item na escala de escolha de hardware, o banco de
dados se beneficiará de sistemas multiprocessados, com processadores de 64 bits e
velocidades de clock elevadas, pois isso ajudará muito no processamento das conexões
e consultas.
Devido às características do PostgreSQL, a comunicação entre os processos é
muito importante para a performance. Quanto mais núcleos no mesmo “chip” mais
rápida será essa comunicação, portanto, processadores modernos de quatro ou mais
núcleos são indicados.
Adequando o Linux para o PostgreSQL
 Comunicação inter-processos (System V IPC);

 Consumo de Memória Compartilhada;
 Overcommit de Memória;
 Consumo de Swap;
 Semáforos do S.O.;
 Limites de Usuário;
161
Em uma instalação de grande porte, é possível que o PostgreSQL atinja os

limites de alguns recursos do sistema operacional. Semáforos e memória
compartilhada são recursos que eventualmente precisam ser ajustados.
Outros limites como número de processos por usuário, número de arquivos

abertos por processo e quantidade de memória disponível para cada processo podem
interferir no funcionamento do servidor PostgreSQL.
Comunicação Inter-processos}
Para realizar a comunicação inter-processos o PostgreSQL utiliza-se memória

compartilhada e semáforos baseando-se no modelo System V IPC.
Memória compartilhada
O cache do PostgreSQL (shared buffers) fica armazenado em um segmento de

memória compartilhada por todos os processos servidor (backends). Pode-se vê-lo
utilizando o comando ipcs.
Memória Compartilhada do Kernel
SHM = Shared Memory = Memória Compartilhada

SHMMNI = Limite de numero de segmentos de SHM;
SHMMAX = Limite do tamanho do segmento de SHM;
SHMALL = Total de SHM disponível;

1 Verifique os parâmetros SHMMNI, SHMMAX e SHMALL:
1# sysctl kernel.shmmax
2# sysctl kernel.shmmni
3# sysctl kernel.shmall
2 Verifique os limites de memória compartilhada com o comando:

4 # ipcs ml
162
Os parâmetros do kernel do Linux importantes para o PostgreSQL relativos à

memória compartilhada são:
●SHMMNI: Número máximo de segmentos de memória compartilhada no sistema

operacional. O PostgreSQL utiliza somente um segmento. Normalmente, as
configurações padrão dos sistemas operacionais são suficientes.
SHMMAX: Tamanho máximo de um segmento de memória compartilhada. Em alguns
sistemas operacionais, o valor padrão pode ser muito baixo, dependendo da
instalação realizada. Este parâmetro deve ser definido de acordo com algumas
configurações do PostgreSQL como shared_buffers, max_connections,
autovacuum_max_workers, max_prepared_transactions, max_locks_per_transactions
e wal_buffers. Uma mensagem de erro ao iniciar o PostgreSQL dirá exatamente qual
o tamanho de memória compartilhada é necessária;
SHMALL: Tamanho total de memória compartilhada utilizada pelo sistema
operacional. O ajuste deste valor depende de cada instalação de sistema operacional.
Este valor deve ser grande o suficiente para que caiba toda a memória compartilhada
do PostgreSQL e demais processos do servidor.
Alterando parâmetros:
É recomendável que os parâmetros sejam alterados no arquivo
“/etc/sysctl.conf” para que sejam verificados duranet a inicialização do Sistema
Operacional, além do arquivo é possível mudar sem reboot com os comandos:
# sysctl w kernel.shmmax=<valor>
# echo <valor> > /proc/sys/kernel/shmmax
Configuração de Semáforos do S.O.
SEMMNI = Numero máximo de conjuntos;

SEMMSL = Limite de semáforos por conjunto;
SEMMNS = Limite de semáforos no S.O.
SEMOPM = Máximo de operações por “semop()”;

1 Verifique respectivamente SEMMSL, SEMMNS, SEMOPM e SEMMNI:
1# sysctl kernel.sem
2# cat /proc/sys/kernel/sem
2 Verifique os limites de semáforos com o comando:

3 # ipcs sl
163
Semáforos
Outro recurso que pode ser precisar de ajuste são os semáforos, o que
normalmente ocorre quando se aumenta demasiadamente o número máximo de
conexões.
● SEMMNI: número máximo de conjuntos de semáforos. O PostgreSQL necessita de

pelo menos (max_connections + autovacuum_max_workers) / 16;
●SEMMSL: número máximo de semáforos por conjunto; o PostgreSQL precisa no
mínimo de 17 semáforos por conjunto;

●SEMMNS: número máximo de semáforos no sistema operacional. Esse valor é,
idealmente, SEMMNI * SEMMSL;

●
SEMOPM: numero máximo de operações de semáforo por chamada do sistema
semop(). O valor padrão nas distribuições Linux é 32, o que é suficiente para o
PostgreSQL. Este valor pode ser aumentado caso o número de conexões em uso
seja muito grande, embora penalidades de desempenho possam ocorrer.
Overcommit de Memória e Swap
Parâmetro “vm.overcommit_memory”:
0 = Permite overcommit de memória (Linux default);
1 = Sempre faz o overcommit de memória;
2 = Não permite overcommit de memória;

1 Altere o parâmetro vm.overcommit_memory para 2:
1# sysctl a | grep vm.overcommit_memory
2# sysctl w vm.overcommit_memory=2
2 O parâmetro vm.swappiness é um parâmetro que determina a

probabilidade da necessidade do uso de swap no servidor, altere o
valor de 60(default) para 10:
3# vim /etc/sysctl.conf
+ vm.overcommit_memory = 2
+ vm.swappiness = 10
164
Memory overcommit
O comportamento padrão de memória virtual no kernel Linux não é ótimo para o

PostgreSQL. Da maneira que o kernel implementa a atribuição de memória além do que
existe (overcommit), o sistema operacional pode terminar o processo postgres (processo
supervisor) se a demanda de outro processo exceder o limite de memória virtual.
Em versões recentes do kernel Linux (2.6 ou superior), uma medida adicional do

parâmetro vm.overcommit_memory diminui as chances do OOM killer ser executado (Out
of Memory killer). Esta configuração é possível usando os recursos do sysctl. Um valor
vm.overcommit_memory = 2 garante que o kernel não libere mais espaço do que a
memória virtual disponível mais uma taxa pré-definida no parâmetro vm.overcommit_ratio.
Isto permite diminuir enormemente as chances de execução do OOM killer.
Se desejado, pode-se garantir que o OOM killer não escolha o processo supervisor,
definindo em /proc/pid/oom_adj o valor -17 que significa OOM\_DISABLE. Esta medida é
complicada pois, a cada reinício do PostgreSQL, o PID do processo supervisor muda. Isto
também não impede que o OOM killer atue sobre os outros processos do PostgreSQL e
mesmo backends.
Conceitos de RAID
165
Conceitos básicos de RAID:

É importante que o DBA conheça o hardware em que o banco de dados ficará
hospedado, para isso um fator que afeta diretamente a segurança e a performance do
banco de dados é a disponibilidade dos discos, RAID de uma forma geral é a forma
em que os discos ficarão disponíveis para escrita e se os dados que são enviados ao
disco, se eles estão sendo espelhados ou somados em algum outro disco, podendo
melhorar não só a disponibilidade mas também a performance.
RAID 5
Os dados ficam espalhados em vários discos onde o dado fica fragmentados
em vários discos, em termos de escrita a performance é interessante pois a escrita é
espalhada em diversos discos, porém para consulta de dados a performance
normalmente é degradada pois existe grandes chances de que seja necessário
mapear mais de um disco para capturar os dados, portanto RAID 5 não é
recomendado para bandos de dados de Produção.
RAID 0
O espaço em disco é estendido em outros discos, a performance de forma
geral é boa, porém caso algum disco fique danificado os dados são perdidos.
RAID 1
Os dados são espalhados em 2 discos, a performance é boa e caso um disco
falhe o outro tem o backup dos dados melhorando a disponibilidade, o problema é
que a utilização de disco sempre vai ser o dobro(devido ao espelhamento).
RAID 1+0 ou RAID10
É a soma do RAID 1 e do RAID 0 essa é a forma mais recomendada para
ambientes produtivos, pois provê performance e disponibilidade ao mesmo tempo.
Sistema de Arquivos | Filesystem
 Afeta desempenho e comfiabilidade;

Journaling
 Proteção dos dados em caso de crash;
 Recuperação rápida e eficiente;
Write Barriers
 Garante escrita do cache da controladora em disco;
 Garante o “fsync” dos dados;
 Pode ser desativado em storage com bateria;
166
Sistema de arquivos
A escolha de um sistema de arquivos adequado, é fundamental para se obter
desempenho e confiabilidade em um SGBD. Nesta seção serão abordados seus
principais recursos, vantagens e desvantagens.
Journaling
Talvez esta seja a funcionalidade mais popular dos sistemas de arquivas, o que
de grosso modo trata-se de uma prevenção contra perda de dados que permite a sua
recuperação em caso de um crash.
Write Barriers
Este recurso, bem menos popular que journaling, é de grande importância para
uso com SGBD's, pois é ele que garante que os dados sejam fisicamente gravados
em disco após um fsync, é ele garante que o conteúdo do cache da controladora seja
despejado no disco fisicamente.
Sem os write barriers, após um fsync os dados são despejados do cache do
sistema operacional porem podem permanecer no cache da controladora e se um
crash ocorrer neste momento, os mesmo serão perdidos pois o cache da controladora
é baseado em memória volátil. O uso dos write barriers aumenta a confiabilidade
porem praticamente inutiliza todas as vantagens de desempenho de se possuir cache
na controladora, pois toda gravação com fsync vai precisar esperar pela escrita em
disco físico.
É possível desligar os writer barriers com segurança e aproveitar o
desempenho da escrita no cache quando se utiliza controladoras/storage que
possuem bateria, pois desta forma em caso crash a bateria mantêm o conteúdo do
cache da controladora durante horas ou dias dependendo do equipamento.
Importância do Journaling
1)Registrar Bloco;
2)Escrever no Bloco;
3)Escrever Metadados;
O journaling recupera o
dado caso ocorra um crash
em alguma dessas etapas.
167
Journaling
●Prevenção contra perda de dados em caso de crash;
●Journal – Pequena área reservada no FS para armazenar preventivamente metadata
e ou dados de arquivos;
●
Recuperação mais rápida e eficiente;
●Em caso de crash somente o journal precisa ser lido;
●Gera overhead;
●
Diversos tipos.
Basicamente a gravação de um arquivo em disco pode ser divida em 3 fases,

registrar bloco nos metadados de blocos utilizados, efetuar a escrita no bloco e registrar
metadados deste bloco. Porem caso aconteça um crash entre as etapas, o sistema de
arquivos pode ficar inconsistente, ou seja, podem existir blocos marcados como utilizados
porem não utilizados, blocos com dados gravados porem sem metadados gravados.
Mesmo nesta situação ainda é possível efetuar a recuperação dos dados, porem é
demorada pois é necessário varrer todos o blocos do sistema de arquivos.
Os metadados possuem diversas informações como arvore de diretório, atributos
de arquivo, lista de blocos do arquivo, etc.
Para possibilitar uma recuperação mais confiável e mais rápida, existe o journaling
que consiste em se gravar metadados ou até mesmo os próprios dados em um região
chamada journal'' antes de se gravar nos blocos. Após a gravação ser efetivada com o
sucesso nos blocos, o seu conteúdo no journal'' pode ser eliminado. Note que, com o uso
do journaling, em caso de crash durante a gravação basta efetuar a recuperação a partir
dos dados presentes no ``journal''. A recuperação neste caso é bem mais rápida que de
sistemas de arquivos sem ``journaling'', pois deve-se apenas varrer o journal e não todos
os blocos do sistema de arquivos.
Opções de Sistema de Arquivos

EXT2 – PostgreSQL = Não
Não tem Journaling;
EXT3 - PostgreSQL = Talvez
Possui Journaling;
Possui Write Barriers com limitações(não LVM, RAID sof.);
EXT4 – PostgreSQL = Recomendado
Possui Journaling;
Possui Write Barriers;
XFS – PostgreSQL = Mais Recomendado
Possui Journaling com mais performance;
Possui Write Barriers com mais performance;
168
EXT2
O ext2 não possui journaling por isso a recuperação após crash é lenta e não
garante recuperação completa dos dados, porem por outro lado possui vantagem em
desempenho, já que não existe o overhead do journaling.
A sua utilização com o PostgreSQL não é mais recomendada devido ao risco
de perda de dados por não dispor de ``journaling''. Todavia, como o próprio
PostgreSQL dispõe de estratégias de recuperação, o uso de ext2 pode ser desejado
quando não há disponibilidade de opção mais performática.
EXT3
O ext3 é basicamente um ext2 com journaling, é possível facilmente
transformar um sistema de arquivos ext2 em ext3, são 3 modalidades de journaling:
●
writeback : Apenas mudanças de metadados são gravados no journal, arquivos
recuperados podem conter lixo no final do arquivo;
●ordered : Metadados são gravados no journal, arquivos recuperados podem conter
``lixo'' porém nunca terão seu tamanho alterado;

●journal : Os dados e metadados são gravados no journal.
O writeback é o modo com menor overhead, por isso tem melhor desempenho
e pode ser utilizado de forma segura com pg_xlog pois o lixo que pode ocorrer no final
do arquivo é facilmente descartado pelos mecanismos do WAL. Já para os diretórios
de dados deve-se utilizar ordered ou journal.
O ext3 suporta write barriers, desde que não se utilize LVM ou RAID via
software, porem de forma ineficiente, pois toda chamada de fsync força o despejo do
cache como um todo e não somente do arquivo em questão como deveria ser.
ext4
FS padrão nas distros mais recentes;

Evolução do ext3;
Implementação correta dos “write barriers”;
O ext4 é o sistema de arquivos padrão nas distribuições Linux mais recentes, é

uma evolução do ext3, cuja as principais melhorias são uma implementação correta dos
write barriers e aumento nos limite de tamanho para até 1 exbibyte (no entanto as
ferramentas atuais de criação do sistema, só suportem 16 terabytes).
XFS
Desenvolvido pela SGI para o IRIX;
Pouco popular no Linux, porém o mais robusto para SGBDS;
Implementação melhor de journaling;
Write barrier funciona de forma correta;
O mais recomendado para o PostgreSQL;
O XFS é um sistema de arquivos originalmente desenvolvido pela SGI para o
IRIX, hoje ainda é pouco popular no Linux, porem é um dos mais robustos e de melhor
desempenho para bancos de dados.
O XFS trabalha melhor com journaling pois ao contrario do ext3 que foi adaptado
a partir ext2 para suportar journal o XFS já foi projetado inicialmente com esta ideia.
Outro ponto positivo do XFS é o write barrier trabalhar de forma correta, ou seja,
somente o necessário é despejado do cache.
O limite de tamanho do XFS esta na casa dos 8 exbibytes e pode trabalhar com
arquivo na casa dos milhões de terabytes.
Para desabilitar os write barriers (em caso de controladora/storage com bateria)
basta utilizar opção nobarrier durante a montagem.
Hoje o XFS é o sistema de arquivos de escolha inicial para se utilizar com o
PostgreSQL. Alguns DBAs experientes também têm usado ext4 com bons resultados,
principalmente quando há contrato padrão de suporte do sistema operacional Red Hat
Enterprise Linux, que oferece XFS como opcional e custo extra.
Separação do PG_XLOG
Principalmente Bancos Transacionais;

Escrita seguencial seguidas de “fsync”;
Montar um disco a parte com LVM;
Utilizar um link para disco dedicado;
Manutenção com o PostgreSQL parado;
170
Como visto anteriormente o pg_xlog é o local onde ficam armazenados os logs

de transação do PostgreSQL ou WAL. Este local é o onde ocorre maior carga de
escrita devido ao perfil de escrita constante seguida de fsync.
Normalmente este é o primeiro ponto a engargalar na maioria dos casos, por

isso que separá-lo é um dos tunings fundamentais a ser realizado.
O perfil de escrita no pg_xlog é de escrita sequencial seguidas de fsync

constantemente.
Para separar o pg_xlog em outro dispositivo, basta substituir a diretório do

pg_xlog por um link simbólico para o ponto de montagem, lembrando que o usuário
postgres deve ser o dono deste novo local, ou utilizar a opção -X no initdb já no
momento da criação do cluster.
O procedimento de movimentação do pg_xlog deve ser feito com o

PostgreSQL parado, e o conteúdo do atual pg_xlog deve ser copiado para o novo
dispositivo. Há alto risco de perda de dados caso não seja feito desta forma.
Tunning nas conexões do PostgreSQL
PostgreSQL é multiprocessos;
Muitas conexões:
Aumentam o consumo de CPU;
Aumentam o LOAD do CPU;
Geram overhead de troca de contextos de CPU;
Recomendações:
Limitar numero de conexões (max_connections);
Utilizar “Pooler de Conexões;
171
Sabendo que o PostgreSQL é baseado em múltiplos processos e que cada

conexão utiliza um processo backend, logo se tivermos enumeras conexões teremos
inúmeros processos sendo executados no sistema operacional.
Um grande número de processos rodando no S.O. tende a desperdiçar
recursos, principalmente CPU, devido ao escalonador de tarefas precisar dividir a
mesma fatia de tempo entre maior número de processos.
É visível e notável o aumento de uso de CPU e da carga do sistema quando o
número de processos aumenta, por isso um grande número de conexões diretas no
PostgreSQL deve ser evitada.
O número máximo de conexões que o PostgreSQL pode aceitar é definida na
opção max_connections. Ao aumentar este número significa aumentar o uso de
memória compartilhada em aproximadamente 400 bytes por conexão.
O ideal é que se evite ao máximo um número grande de conexões no
PostgreSQL. Números maiores que 200 já podem ser considerados grandes, lembre-
se que normalmente é a aplicação quem conecta no banco é não os usuários finais,
por isso, poucas conexões bastam.
Servidores de aplicação como o JBoss possuem recursos de pool de conexão,
onde a aplicação é conectada ao pool e o pool conectado ao banco de dados, neste
casos o uso de conexão é mínimo. Porem existem cenários onde o servidor de
aplicação não possui ``pool'' o nem mesmo existe um servidor de aplicação, nestes
casos quando houver consumo grande conexão deve-se utilizar um pool de conexão
externo como o PgBouncer ou PgPool2.
Existe uma reserva de conexões para que superusuários possam conectar e
atuar caso ocorrer estouro do número de conexões, este número é definido na opção
superuser_reserved_connections que por padrão é 3.
Pooler de Conexões - pgBouncer

Características:
Mantém conexões em Cache;
É transparente para aplicação;
Ideal para:
Muitos usuários;
Consultas rápidas;
Aplicações WEB;
1 Faça a instalação do pgbouncer:

1# aptget install pgbouncer
2# vim /etc/default/pgbouncer
+ START=1
172
O PgBouncer foi desenvolvido para diminuir o impacto de performance causado

pela abertura de novas conexões. Existem aplicações, tais como aplicações web, que:
●
Executam muitas tarefas, de curto prazo;
● Tem muitos usuários simultâneos.
No primeiro caso, o tempo de abertura e fechamento da conexão, na maioria das

vezes, é significante em relação ao tempo total da requisição. No segundo caso, o SGBD
não consegue se comportar com a mesma performance quando o número de usuários
simultâneos aumenta. Por isso, o aglomerador de conexões (conhecido como connection
pooler) pode ajudar nesses dois casos. A reutilização de conexões elimina o tempo de
abertura e fechamento das conexões (elas ficam abertas caso haja demanda) e, também,
diminui a necessidade de se abrir várias conexões (os comandos são distribuídos entre as
conexões existentes).
O PgBouncer pode ficar em uma máquina separada (mas nada impede que ele
esteja na mesma máquina). A quantidade de clientes (m) que se conectam ao pool é
muito maior do que o número de conexões (n) do pool para o servidor PostgreSQL.
É importante lembrar que, para a aplicação, o PgBouncer é transparente, ou seja,

a aplicação enxerga o PgBouncer como se fosse o próprio servidor PostgreSQL.
Modos de gerenciamento do pgBouncer

Session:
Conexão atribuida por sessão;
Reutilizada após o fim da sessão;
Transacion;
Conexão é atribuída por transação;
Reutilizada após o término da transação;
Statement;
Conexão é atribuida por comando;
Reutilizada após o término do comando;
173
O PgBouncer trabalha em três modos:
●Aglomeração por Sessão (Session pooling): é o método mais gentil. Quando um

cliente conecta, uma conexão do servidor é atribuída a ele enquanto permanecer
conectado. Ao desconectar, a conexão é colocada novamente no aglomerado (pool);
●Aglomeração por Transação (Transaction pooling): uma conexão do servidor é
atribuída ao cliente somente durante uma transação. Quando o PgBouncer nota que a
transação acabou, a conexão é colocada novamente no aglomerado (pool);
●Aglomeração por Comando (Statement pooling): é o método mais agressivo. Uma
conexão do servidor é atribuída ao cliente somente durante um comando. Transações

com múltiplos comandos não são permitidas nesse modo, pois elas podem falhar.
Quando o comando acaba, a conexão é colocada novamente no aglomerado (pool)
Configurando o pgBouncer
1 Edite o arquivo de configuração adicionando as linhas:

1# vim /etc/pgbouncer/pgbouncer.ini
[databases]
dexterpool = host=127.0.0.1 port=5432 dbname=dexter
[pgbouncer]
listen_addr = *
auth_type = md5
admin_users = aluno
stats_users = aluno
pool_mode = transaction
2 Altere o dono do arquivo:

2 # chown postgres. /etc/pgbouncer R
174
Pgbouncer.ini
A configuração do PgBouncer consiste de dois arquivos: um arquivo de
configuração e um arquivo de autenticação.
O arquivo de configuração (geralmente chamado de pgbouncer.ini), possui o
formato ini que é um padrão de fato para arquivos de configuração (amplamente
utilizado na plataforma Windows).
O elemento básico é um parâmetro que possui o formato nome = valor.
Parâmetros podem ser agrupados em seções que são descritas por [seção]. O ponto
e vírgula indica um comentário até o fim da linha.
[databases]
A seção databases informa a string de conexão a ser utilizada pelo PgBouncer.
Nomes de bancos de dados podem conter [A-Za-z0-9_.-]. String de conexão pode
conter os seguintes parâmetros:
●dbname: nome do banco de dados do servidor PostgreSQL;
●
host: endereço IP do servidor PostgreSQL;
●port: porta TCP onde o servidor PostgreSQL está atendendo;
●user: usuário do servidor PostgreSQL;
●password: senha do usuário do servidor PostgreSQL;
●pool_size: tamanho máximo do pool para este banco de dados. (default_pool_size)
●
connect_query: consulta executada após a conexão ser estabelecida mas antes de
disponibilizar a conexão para os clientes;
●client_encoding: informa a codificação de caracteres a ser utilizada;
●
datestyle: informa o estilo de data a ser utilizado;
●timezone: informa a zona horária a ser utilizada.
Opções Gerais:
● listen_addr: endereço TCP/IP onde o servidor atenderá as conexões dos clientes;
●
listen_port: a porta TCP onde o servidor está atendendo;
● unix_socket_dir: o diretório do soquete de domínio Unix;
● logfile: caminho do arquivo de log;
● pidfile: caminho do arquivo que contém o PID;
● auth_type: tipo de autenticação suportada. Pode ser: trust, any, plain, crypt e md5;
●
pool_mode: especifica quando um conexão pode ser reutilizada por outros clientes.
São eles: session (conexão é reutilizada após o cliente desconectar), transaction
(conexão é reutilizada após uma transação terminar) e statement (conexão é
reutilizada após um comando ser executado);
● max_client_conn: número máximo de conexões cliente permitido. Ao aumentar este
número, o número de descritores de arquivos (vide ulimit) deve ser aumentado de
acordo. Teoricamente, o máximo utilizado é max_client_conn + (max_pool_size *
num_bds * num_usuários);
●
default_pool_size: quantas conexões são permitidas por usuário/banco de dados.
Pode ser modificado através de configuração por banco de dados;
● reserve_pool_size: quantas conexões adicionais (além de default_pool_size) são
permitidas por usuário/banco de dados. Pode ser modificado através de configuração
por banco de dados;
● reserve_pool_timeout: se o cliente não for atendido nesse tempo, o PgBouncer
permite que seja utilizada uma conexão reserva;
●
server_round_robin: o PgBouncer reutiliza as conexões utilizando o conceito LIFO
(acrônimo para expressão inglesa Last In, First Out, que significa último a entrar,
primeiro a sair), que refere-se a estrutura de dados do tipo pilha. Assim, poucas
conexões fazem a maioria do trabalho. Isto garante uma boa performance se você
possui somente um servidor servindo um banco de dados. Esta opção habilita a
carga uniforme a todas as conexões.
Opções de Log:
●
syslog: habilita o uso do syslog. Na plataforma Windows, o eventlog é utilizado;
●
syslog_facility: qual tipo de programa (facilidade) está enviando o log para o syslog;
● log_connections: registra conexões realizadas com sucesso;
● log_disconnections: registra desconexões informando o motivo;
●
log_pooler_errors: registra mensagens de erro que o PgBouncer envia para os
clientes;
Opções administrativas:
●
admin_users: usuários que tem permissão para efetuar o login no console do
PgBouncer e executar todos os comandos;
● stats_users: usuários que tem permissão para efetuar o login no console do
PgBouncer e executar comandos somente leitura, ou seja, todos os comandos
SHOW exceto SHOW FDS.
● server_reset_query: comando enviado ao servidor antes da conexão ser liberada a
outros clientes. Uma boa escolha para versões 8.2 ou inferiores é RESET ALL; SET
SESSION AUTHORIZATION DEFAULT;. Para versões 8.3 ou superiores, DISCARD
ALL; é suficiente;
Configurando o pgBouncer
3 Crie um arquivo de autenticação com o usuário postgres:
1$ psql c "SELECT * FROM pg_shadow;" | awk F" "
'{ print $1,$13 }' | grep aluno >
/etc/pgbouncer/userlist.txt
4 Insira aspas no arquivo conforme exemplo:
2$vim /etc/pgbouncer/userlist.txt
"aluno" "md596b565550b58e3d2a4e3028186fd815a"
5 Inicialize o PGBouncer manualmente:

3$/usr/sbin/pgbouncer d
/etc/pgbouncer/pgbouncer.ini R
176
Opções administrativas - continuação:
●
server_check_query: consulta simples (ex:, SELECT 1) para verificar se o servidor
ainda está respondendo;
●server_check_delay: timeout para verificar uma conexão liberada. O valor 0 (zero)
implica que a verificação será feita imediatamente;

●server_lifetime: conexões que foram utilizadas mais que esse tempo (em segundos)
serão fechadas. 0 (zero) a conexão com servidor PostgreSQL será utilizada uma vez;
●server_idle_timeout: se a conexão com o servidor PostgreSQL está ociosa mais do
que o tempo de espera informado é porque existem muitas conexões no pool e esta
pode ser fechada;
●server_connect_timeout: tempo de espera para efetuar o login ao servidor antes da
conexão ser fechada.

server_login_retry: se a efetivação do login falhou por algum motivo, espere o tempo
informado antes de tentar se conectar novamente;
●
query_timeout: consultas que demoram executar mais do que o tempo informado
são canceladas. Isso deve ser utilizado somente com
●client_idle_timeout: se a conexão com o cliente está ociosa mais do que o tempo
de espera informado, ela será fechada. Este valor não deve ser menor do que o
tempo total de uma conexão;
●client_login_timeout: se o cliente se conectar e não efetuar o login no tempo
informado, ele será desconectado;

●
autodb_idle_timeout: tempo de espera antes de fechar uma conexão que foi aberta
utilizando um pool de bancos de dados genérico (criado utilizando * no nome do
banco).
PgBouncer - Comandos
SHOW (monitoria)
STATS, SERVERS, CLIENTS, POOLS,LISTS
USERS, DATABASES, FDS, CONFIG
Comandos
PAUSE / RESUME
SUSPEND
SHUTDOWN
RELOAD
1 Valide alguns comandos:

1$ psql U aluno h 127.0.0.1 p 6432 d pgbouncer
2=# PAUSE;
3=# RESUME;
4=# SHOW STATS;
177
O PgBouncer disponibiliza um console para monitoramento e controle de

operações. Para isso, você precisa se conectar a um banco de dados chamado
pgbouncer. O monitoramento pode ser feito através do comando SHOW. Cada uma
das opções do SHOW mostram estatísticas sobre o uso do pool.
SHOW { STATS | SERVERS | CLIENTS | POOLS | LISTS | USERS | DATABASES |

FDS | CONFIG }
O controle do PgBouncer pode ser feito através dos seguintes comandos:

●PAUSE: PgBouncer tenta desconectar de todos os servidores mas primeiro ele
espera que todas as consultas terminem. O comando não retornará até que todas as
consultas terminem. Útil para ser executar um reinício no servidor de banco de dados;
●
SUSPEND: todos os buffers são escritos e o PgBouncer para de atender requisições.
O comando não retornará até que tudo seja feito. Útil para executar um reinício no
PgBouncer;
●
RESUME: voltar ao trabalho após executar os comandos PAUSE ou SUSPEND;
●SHUTDOWN: termina o processo do PgBouncer;
●RELOAD: carrega novamente o arquivo de configuração do PgBouncer.
Exemplo utilizado:
O exemplo acima ilustra o uso dos comandos PAUSE e RESUME. Neste caso,
executamos o PAUSE para bloquear consultas de futuras conexões. Após todas as
consultas das conexões ativas terminarem, você pode fazer uma manutenção no
servidor PostgreSQL.
Para aceitar novas consultas novamente, executamos o comando RESUME.
Particionamento de Tabelas
Características:
Utiliza conceito de herança com tabela filho;

Tabela mãe deve ficar vazia;
Restringir todos os dados para as tabelas filhas;
Quando usar:
Grande volume de registros;
Há restrições coerentes nas consultas;
Melhorar rotina de expurgo;
178
Particionamento é a divisão de uma tabela grande em pedaços menores. Os

principais motivos para optar pelo particionamento de uma tabela são:
● Melhorar performance de consultas (modelos OLAP, DW, Web) onde grandes

porções de tabelas são utilizadas, e essas porções podem ser planejadas de forma a
estarem em uma ou poucas das partições;
●Nessas consultas, pode-se conseguir aumentar a probabilidade de que a porção da
tabela ou índices utilizados caibam na memória;

●Facilitar gerenciamento de cargas e exclusões em qualquer modelo de dados, desde
que isso conste também do planejamento do particionamento;

●Se bem planejadas, as cargas e exclusão se darão pela adição e remoção de
partições inteiras de uma grande tabela particionada;

●
Separar dados de uso constante dos que são raramente utilizados, inclusive
utilizando discos mais lentos para isso.
Particionamento – Criando Partições

1 Crie a tabela mãe conforme segue:
1=# CREATE TABLE financeiro.boletos ( cedente
varchar(50), codigo int, vencimento date);
2 Crie a partição para os dados de 2016:
2=#CREATE TABLE financeiro.boletos_2016
(CONSTRAINT boletos_2016_check CHECK (vencimento
>= '20160101' AND vencimento < '20170101'))
INHERITS (financeiro.boletos);
3 Crie a partição para os dados de 2015:
3=#CREATE TABLE financeiro.boletos_2015
(CONSTRAINT boletos_2015_check CHECK (vencimento
>= '20150101' AND vencimento < '20160101'))
INHERITS (financeiro.boletos);
179
O PostgreSQL suporta particionamento utilizando o conceito de herança. Cada

partição é uma tabela filho. A tabela pai só existe para representar o conjunto de
dados e, normalmente, ela fica vazia. Os tipos de particionamento suportados
atualmente pelo PostgreSQL são:
●Particionamento por intervalo

●Particionamento por lista de valores.
As seguintes passos podem ser executados para implementar o

particionamento em uma tabela no PostgreSQL:
● Criar uma tabela pai contendo as colunas desejadas;

●
Criar as tabelas filho que herdam da tabela pai (normalmente essas tabelas não
conterão novas colunas);
●Adicionar restrições as tabelas filho, com cuidado para que elas não se sobreponham
e cubram todos os valores possíveis;

●Não é obrigatório criar índice(s) na(s) coluna(s) chave em cada partição, mas pode
ajudar em muitos casos;

●Definir gatilhos ou regras para redirecionar os dados a partição apropriada, sendo
que não deve-se usar regras se as cargas forem feitas com o comando COPY;
●
Habilitar o parâmetro constraint_exclusion no postgresql.conf, usando o valor
partition a partir da versão 8.4 ou on nas versões anteriores.
Particionamento – Criando Regras

3 Crie uma regra para os dados de 2016:

1=#CREATE RULE boletos_2016 AS ON INSERT TO
financeiro.boletos WHERE (vencimento >= '201601
01' AND vencimento < '20170101') DO INSTEAD
INSERT INTO financeiro.boletos_2016 (cedente,
codigo, vencimento) VALUES (new.cedente,
new.codigo, new.vencimento);
4 Crie uma regra para os dados de 2015:
2=#CREATE RULE boletos_2015 AS ON INSERT TO
financeiro.boletos WHERE (vencimento >= '201501
01' AND vencimento < '20160101') DO INSTEAD
INSERT INTO financeiro.boletos_2015 (cedente,
codigo, vencimento) VALUES (new.cedente,
new.codigo, new.vencimento);
180
Exemplos de particionamento:
● particionamento por intervalo
●valor > 8 AND valor < 80

●valor >= 80 AND valor < 800
●col >= ’2008-06-06’ AND col <= ’2008-10-08’
●col > ’2008-10-08’ AND col <= ’2008-12-31’
● particionamento por valores
●
tipo = ’A’ OR tipo = ’E’ OR tipo = ’J’
● tipo = ’X’ OR tipo = ’Z’
Particionamento – Validação
3 Insira registros na tabela financeiro.boletos:

1=#INSERT INTO financeiro.boletos VALUES
('dexter','1234567890','20160215');
2=#INSERT INTO financeiro.boletos VALUES
('dexter','1234567891','20150716');
4 Valide as alterações realizadas na tabela:

3=#select * from financeiro.boletos_2016;
4=#select * from financeiro.boletos_2015;
4=#\d+ financeiro.boletos;
181
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Tunning Linux
Recapitulando
 Reconhecimendo de Hardware no Linux;

 Alteração de parâmetros do Kernel;
 Características dos Filesystems;
 PGBouncer - Pooler de conexões;
 Particionamento de tabelas;
182
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Características ee Tunning
Monitoramento InstalaçãoPostgreSQL
do MySQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Monitoramento e Tunning PostgreSQL
Objetivos da Aula
Monitoramento Pontual;
Monitoramento Contínuo;
Benchmark com pgbench;
Tunning OLAP e OLTP;
Explain e Explain Analize;
184
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Monitoramento Pontual
Considerações:
 Deve-se conhecer o Hardware;
 Deve-se conhecer a arquitetura;
Ferramentas:
 top – CPU, RAM, SWAP, etc;
 free – Dados referente a memória RAM;
 ps – lista de processos;
 iostat – Estatísticas de IO e CPU;
 vmstat – Memória, paginação, etc;
185
Conhecer as principais ferramentas de monitoramento pontual e suas métricas

é fundamental para realizar ajustes finos e detectar gargalos. Neste tópico serão
abordadas ferramentas a nível de S.O. para determinar consumo de recursos e
ferramentas para o PostgreSQL.
Os recursos utilizados pelo PostgreSQL são gerenciados pelo sistema
operacional. Para se compreender o que está acontecendo com o PostgreSQL, às
vezes, é necessário saber se a questão não reside em alguns desses recursos. A
seguir, são apresentadas algumas das ferramentas utilizadas por administradores de
sistemas para monitorar esses recursos.
Os recursos mais importantes a monitorar são estatísticas dos discos, memória
e CPU. Outras estatísticas podem ser importantes em alguns cenários como rede,
processos, swap e IPC - Inter-Process Communications.
Para que seja possível um monitoramento eficaz, é muito importante que o
administrador conheça os limites de cada um dos itens. Em alguns casos, a métrica
de porcentagem já expõe quanto de um recurso está em uso ou ainda está
disponível. Em algumas outras medidas, como estatísticas de I/O, os limites terão de
ser determinados experimentalmente.
top
É uma ferramenta muito popular no mundo Unix/Linux, é usada com frequência
pelos sysadmins pois ela traz uma visão geral estado do S.O. no momento. Ele
apresenta um snapshot de 3 em 3 segundos de várias informações de sistema.
$ top
Uma dica interessante é usar a tecla ’1’ para mostrar os detalhes de consumo
de CPU por núcleo, a tecla 'c' para visualizar os comandos completos e a tecla ’d’
para configurar o tempo de refresh da tela. Também é possível mudar a ordenação
dos campos com ’<’ e ’>’
free
O comando free é muito popular em ambientes Unix. Mas ele pode ser mal interpretado
para administradores desavisados. Vejamos um exemplo do mesmo:
$ free m
A opção -m é usada para mostrar os valores em MB ao invés de bytes (pode-se usar -g
para GB também).
É importante frisar que a linha que devemos mais prestar atenção para saber o quanto
de memória usada e livre o sistema tem é a segunda! Esta linha desconta o uso de
buffers e cached memory, e indica o quanto realmente os processos estão consumindo.
Se levarmos em conta somente a primeira linha o sistema acima indica que temos
apenas 337 MB livres de memória, o que não corresponde a realidade.
É importante ressaltar que a memória compartilhada é computada como cache e
por isso acaba sendo descontada na segunda linha, então para se obter um resultado
mais adequado deve-se somar e subtrair a quantidade de shared buffers do totais
utilizado e livre respectivamente.
O Linux (e outros Unix) tem a tendência de usar a memória disponível para cache
de disco e buffers de rede. A coluna cached da primeira linha indica o quanto de cache
de disco o S.O. está alocando, e este cache é usado para evitar I/O de disco em leituras
e portanto muito importante para um banco de dados. A existência deste cache é um dos
motivos que não há necessidade de se alocar tanto shared buffer o possível no
PostgreSQL.
ps
Outra ferramenta muito usada pelos administradores de sistema, mas raramente
explorada em sua totalidade é o ps, capaz de mostrar os processos na memória e o
consumo de recursos dos mesmos.
O ps pode por exemplo ser usado para filtrar somente as informações pertinentes
do sistema com a opção o. O exemplo abaixo indica os processos que estão na
memória do PostgreSQL somente com o uso de CPU e memória.
$ ps o 'pid,s,%cpu,%mem,cmd' C postgres
Com o ps também é possível saber a quantidade de conexões abertas somente
mandando contar suas linhas e descontando os processos fixos.
# ps o 'pid,s,%cpu,%mem,cmd' C postgres | wc l
No exemplo acima é possível concluir que existe um conexão aberta, pois
descontando o número de processos fixos (6) mais o cabeçalho temos o número 1.
vmstat
Outro comando popular é o vmstat. Ele relata estatísticas sobre processos, memória,
paginação, CPU e I/O de uma forma resumida e prática.
$ vmstat 2
É importante ressaltar que a primeira coleta(primeira linha) deve ser descartada,
pois ela não representa a real situação do sistema. Diante disso, sempre é necessário
informar uma taxa de atualização das coletas, que neste caso foi de 2 segundos, pois
caso contrário ele apresentara somente a primeira coleta.
No uso do vmstat destaca-se as seguintes informações:
● Fluxo de uso de swap: Através das colunas si e so é possível saber a quantidade de
dados fluindo da memória para swap, ou vice-versa. É com estes indicadores que se
determina se o swap esta sendo efetivamente usado e atrapalhando no
desempenho.
● Número de trocas de contexto: Apresentado na coluna cs, este valor tende a subir
quando se aumenta o número de processos.
iostat
É uma ferramenta de apresentação de estatísticas de I/O e CPU relacionada a I/O
extremamente útil para um DBA. Podemos especificar dispositivos ou partições a serem
monitorados.
Assim como o vmstat a primeira coleta deve ser descartada e por isso sempre é
necessário informar uma taxa de atualização.
O iostat pode apresentar suas informações de forma resumida ou detalhada quando
utilizada a opção -x.
$ iostat sda 2
No modo resumido destacam-se as seguintes informações:
●
Média de operações de IO por segundo}: É apresentado na coluna tps. É útil para
determinar se os discos estão chegando próximo ao seu limite de IOPS.
● Média da taxa de blocos lidos e gravados}: É apresentada nas colunas Blk_read/s e
Blk_wrtn/s' respectivamente. Este auxilia determinar qual tipo de operação pode estar
gerando carga.
Quando utilizado no modo detalhado traz informações mais especificas:
$ iostat x sda 2
Tamanho médio da fila: Apresentado na coluna avgqu-sz, é média no tamanho da fila
de IO no tempo mensurado.
Media de tempo de espera para concluir uma requisição: Apresentado na coluna
await, é a media de tempo gasto do inicio de uma requisição até receber o retorno do
dispositivo.
Media de tempo de serviço: Apresentado na coluna svctm, é media de tempo gasto a
partir da saída da requisição do S.O. até seu retorno, pode ser considerado como tempo
de resposta do dispositivo.
Porcentagem de utilização: Apresentado na coluna %util, traz uma aproximação do
uso do disco, quando atinge valores próximos a 100% pode-se dizer que o disco esta
saturado.
Apesar de ser útil para determinar problemas de desempenho em disco a métrica
de tempo de serviço não é mais confiável no Linux atualmente e será removido das
próximas versões do iostat.
iotop
Ferramenta similar ao top porem com informações de IO por processo, é útil para
identificar se um processo especifico esta causando carga excessiva de IO.
$ iotop
Monitoramento Contínuo
Ferramentas completas
 Zabbix;
Ferramenta SAR
 Ferramenta básica de monitoria;
 Eficiente e com relatórios em texto;
 Monitora os principais itens de hardware;
Ferramenta KSAR
 Converte o relatório em texto do sar;
 Gera gráficos facilitando a visualização;
188
O sar é uma antiga ferramenta UNIX, implementada inicialmente no Solaris, é

muito eficiente e atualmente está presente na maioria dos sistemas UNIX-like,
inclusive no Linux. Extremamente leve em consumo de recursos, foi desenhado para
ter um impacto marginal enquanto coleta dados de CPU, memória, I/O, rede,
interrupções e paginação, entre outras, com data e hora de cada informação coletada,
em intervalos flexíveis. O sar coleta informações a partir dos arquivos disponíveis no
diretório /proc.
Para utilizá-lo é necessário executar um dos utilitários (sadc, sa1 ou sar) para
coleta periódica de dados. A execução desses utilitários pode ser disparada
manualmente ou por um agendador de tarefas como o cron. Os dados são gravados
em arquivos de log no formato binário e, para lê-los, utiliza-se o utilitário sar.
O arquivo binário de dados deve ser lido pelo sar na mesma máquina onde foi
gerado, para extrair as informações corretas. O arquivo de texto final gerado pelo
utilitário sar pode ser então copiado para outro local para ser analisado.
Instalando ferramentas de monitoria

1 Instale algumas ferramentas de monitoria pontual:

1# aptget install iotop
2# aptget install htop
2 Instale e configure o sysstat:

3# aptget install sysstat
4# dpkgreconfigure sysstat
3 Veja exemplos de monitoria constínua e pontual:

5# top
6# free m
7# ps aux
8# iotop
9# sar A
189
Em distribuições Debian e derivados o sar pode ser instalado e ativado na

CRON através dos seguintes comandos:
# apt-get install sysstat
# dpkg-reconfigure sysstat
Para visualizar os dados coletados basta executar o comando abaixo:
# sar -A
Para facilitar a leitura dos dados coletados pelo sar, existe uma ferramenta
chamada ksar, pois como visto acima, o sar coleta muitos dados, e pode ser tornar
trabalhoso e difícil extrair informações sobre os dados coletados.
O ksar é feito Java, e pode ser obtido através do seguinte endereço
http://sourceforge.net/projects/ksar/.
Uma limitação importante do ksar é que ele somente consegue importar dados
que foram gerados utilizando a codificação c, por isso antes a exportação deve ser
feita da seguinte forma:
# LC_ALL=c sar -p -A > sar.txt
Primeiras etapas do Tunning

Reconhecer Hardware
 OK
Verificar parâmetros do SO
 OK
Customizar LOGS do PostgreSQL
 Rastreabilidade de erros;
 Auditoria de conexões;
 Coleta de consultas lentas;
190
Customizando logs do PostgreSQL

1 Edite o arquivo postgresql.conf para auditar os usuários:
+ log_min_duration_statement = 1
+ log_checkpoints = on
+ log_connections = on
+ log_disconnections = on
+ log_hostname = on
+ log_line_prefix = '%t [%p]: [%l1] db=%d,user=%u@%r %x:%v '
+ log_lock_waits = on
+ log_statement = 'ddl'
+ log_temp_files = 0
+ lc_messages = 'en_US.UTF8'
2 Configure o locale para inglês e reinicie o postgresql:

2# dpkgreconfigure locales
Selecione “en_US.UTF8”
191
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Benchmark Tool - pgbench

Características
Ferramenta de benchmark default;
Teste de Stress OLTP;
É customizável;
Retorna numero de transações por segundo;
Boas Práticas
Executar em um servidor separado;
Realizar testes longos;
Executar mais de uma vez;
192
O pgbench é um programa simples para executar testes de performance no

PostgreSQL. Ele é baseado no TPC-B, que é caracterizado pelo TPC como um teste
de estresse do banco de dados. Executa comandos SQL continuamente e,
possivelmente, em múltiplas conexões. Ao final dos comandos, ele calcula a número
de transações por segundo.
A carga simulada pelo TPC-B não reflete todos os aspectos de um sistema

OLTP (Online Transaction Processing) pois não contém, por exemplo, múltiplos tipos
de transações (simples e complexas). Esse tipo de teste é útil para exercitar os
componentes básicos de um SGBD.
O banco de dados do teste foi montado nos termos de um banco hipotético. O

banco(financeiro) tem um ou mais agências (branches). Cada agência tem múltiplos
caixas de banco (tellers). O banco tem muitos clientes, cada um com uma conta
(accounts).
O banco de dados representa o dinheiro em cada entidade (agência, caixa e

conta) e um histórico das transações recentes executadas pelo banco. A transação
representa o trabalho executado quando um cliente faz um depósito ou saque de sua
conta. A transação é feita pelo caixa em alguma agência.
Configurando o pgbench
1 Instale os pacotes de extensão do PostgreSQL

1 # aptget install postgresqlcontrib9.6
2 Com o usuário postgres crie o banco bench:
2$ createdb bench
3 Faça a carga de dados inicial com fator de escala 40:
3 $ pgbench i s 40 bench
4 Faça o primeiro teste de benchmarking durante 5 minutos:
4$ pgbench T 300 s 40 bench
Nota: O teste de benchmarking deve ser repetido mais 2 vezes

inicialmente e depois executado cada vez que as alterações
forem realizadas no PostgreSQL.
193
Para executar testes de performance com pgbench precisamos fazer pelo

menos dois passos:
●Criar e adicionar dados as tabelas;
●Executar os testes em si.
O primeiro passo ou inicialização, consiste em:
●remover (caso existam) e criar as tabelas descritas acima;

●
inserir dados nas tabelas de acordo com um fator de escala (opção -s);
●adicionar as chaves primárias;
●executar VACUUM ANALYZE nas tabelas envolvidas.
Abaixo podemos ver como seria esse primeiro passo.

$ pgbench -i -s 15 bench
Algumas opções para execução dos testes são:
● Ler o script de transação a partir de um arquivo. Isto que dizer que você também
pode montar os seus testes com tabelas diferentes e utilizar o pgbench para obter os
resultados. Múltiplos scripts podem ser utilizados; nesse caso, o pgbench escolhe um
script randomicamente toda vez que uma transação for iniciada;
●
Escolher o tipo de protocolo no qual enviará as consultas ao servidor. As opções são:
simple, extended e prepared;
●Executar exclusivamente transações somente leitura;
●
Fazer (ou não) a limpeza (VACUUM) das tabelas antes dos testes;
●Escolher o número de clientes simultâneos;
●Escolher o número de transações ou o tempo do teste;

OLTP vs OLAP
OLTP – (Online Transacional Processing)
 Muita Escrita;
 Consultas Simples;
 Modelo normalizado;
 Mais volátil;
OLAP – (Online Analytical Processing)
 Consultas Complexas;
 Grandes massas de dados;
 Modelo mais simples;
194
 Menos volátil;
OLTP
OLTP (Online Transaction Processing) são bancos cujo o perfil é

transacional, ou seja, onde as operações de escrita são muito maiores que as de
consultas que normalmente são muito simples. Um bom exemplo de OLTP são os
bancos de instituições financeiras que armazenam os dados bancários dos clientes,
onde a maior parte das transações são relacionadas a saques, depósitos,
pagamentos, transferências.
OLAP
Bancos OLAP (Online Analytical Processing) se caracterizam por receberem

consultas complexas em grandes massas de dados e as operações de escrita serem
mínimas. Este tipo de banco normalmente é utilizado para gerar relatórios, um bom
exemplo são bancos utilizados por sistemas de BI.
Tunning OLTP
 Separar PG_XLOG;
 Aglomerar Commits;
 Mais Shared Buffers (40% da RAM);
 Log Checkpoints;
195
WAL
Neste tipo de banco normalmente a escrita é intensa, o que faz com que
primeiro gargalo seja o WAL, por isso é fundamental que o ``pg_xlog'' esteja em
conjunto de discos separados e de alto desempenho e confiabilidade.
Em bancos OLTP, com muitas transações concorrentes, pode ser interessante
utilizar as opções de commit_siblings e commit_delay para aglomerar mais de uma
transações em único fsync, e desta forma amenizar a carga de IO gerada pela
gravação do WAL.
Os ajustes destes parâmetros são muito específicos de cada ambiente, por
isso, não se tem uma recomendação de número inicial.
Shared buffers, bgwriter e checkpointer
Bancos com este perfil devem possuir uma área de shared buffers
suficientemente grande para que consiga armazenar o fluxo de dados a serem
escritos, afim de sempre ter páginas disponíveis e assim evitar que os backends
tenham necessidade de efetuar as gravações por si mesmos. Como recomendação
inicial pode-se dedicar em torno de 40% da memória ram para os shared buffers
(desde que não exceda faixa dos 4GB a 8GB).
Também deve-se evitar que ocorram checkpoints constantemente, o ideal é
aumentar o número segmentos para evitar que sua falta provoque um checkpoints e
desta forma possibilitando controlar exatamente a cada quanto tempo ele deve
ocorrer, e como deve ser espalhado. Como recomendação inicial pode-se começar
com pelo menos 15 segmentos.
Quando ativada a opção log_checkpoints, todos os checkpoints passam a ser
registrados em log, com esta informação é possível saber, quando e como estão
ocorrendo os checkpoints, o que é fundamental para realizar novos ajustes.
Separando pg_xlog
1 Existe um disco de 1GB no servidor, formate o disco:
1 # mkfs.ext4 /dev/sdb1
2 Crie o diretório /pg_xlog e monte o disco
2# mkdir /pg_xlog
3# vim /etc/fstab
/dev/sdb1 /pg_xlog ext4 defaults 0 2
4# mount a
5# chown R postgres /pg_xlog
3 Com o PostgreSQL fora do ar mova os WAL e crie o link simbólico:

7# mv /var/lib/postgresql/9.6/main/pg_xlog/* /pg_xlog
8# rmdir /var/lib/postgresql/9.6/main/pg_xlog
9# ln s /pg_xlog /var/lib/postgresql/9.6/main/pg_xlog
10# service postgresql start
196
ponto importante é monitorar o trabalho do background writer através da view

pg_stat_bgwriter'. Através dela é possível identificar:
●Se os backends} estão efetuando gravação em disco e realizando fsync.

●
Se o bgwriter esta atingindo o seu limite de gravação por rodada.
●A quantidade de buffers que estão sendo limpo pelo bgwriter
Tunning OLTP
1 Altere os parâmetros commit_delay e commit_siblings:

1=# ALTER SYSTEM SET commit_delay=1000;
2=# ALTER SYSTEM SET commit_siblings=100;
2 Altere o parâmetro e faça o reload no PostgreSQL:

3=# ALTER SYSTEM SET wal_writer_delay=500;
4=# SELECT pg_reload_conf();
3 Faça um teste de benchmarking durante 5 minutos com 50 clients:

5 $ pgbench T 300 c 50 s 40 bench
197
Em casos de muitas transações concorrentes é interessante utilizar o “commit

atrasado”;
commit_siblings
commit_delay
Tunning OLAP
 Consultas complexas geram hash tables;

 Ajustar work_mem para hash tables;
 Shared Buffers (10% da RAM);
 Ajustar maintenance_work_mem;
 Ajustar effective_cache_size;
198
Bancos OLAP (Online Analytical Processing) se caracterizam por receberem

consultas complexas em grandes massas de dados e as operações de escrita serem
mínimas Este tipo de banco normalmente é utilizado para gerar relatórios, um bom
exemplo são bancos utilizados por sistemas de BI.
Uso de memória
Consultas complexas normalmente envolvem:

●Diversas tabelas unidas por join e ou Sub consultas, o que internamente utiliza-se de
hash tables.
●Resultados com dados ordenados.
Operações que utilizam-se de hash tables e ordenação tem uso de memória

limitado ao definido na opção work_mem, este limite é importante pois caso não
existisse uma única consulta poderia acabar com a memória física do servidor.
Em bancos OLTP, onde essas operações são largamente utilizadas, o ideal é
que o conteúdo das consultas caibam dentro do limite do work_mem, pois caso
contrario elas serão realizadas utilizando arquivos temporários em disco, o que
diminui drasticamente o desempenho das consultas.
Tunning OLAP
1 Edite o arquivo de configuração ajustando os parâmetros:

+ work_mem = 32MB
+ maintenance_work_mem = 256MB
+ effective_cache_size = 3GB
2 Reinicie o PostgreSQL
2# service postgresql restart
4 $ pgbench T 300 c 50 s 40 bench
199
Pgbouncer.ini
work_mem
configuração
O valorepadrão
um arquivo
do work_mem
de autenticação.
é de 1MB, o que é muito pequeno, por isso esse
valor deve
O arquivo
ser aumentado,
de configuração
porem é(geralmente
necessário chamado
tomar o cuidado
de pgbouncer.ini),
para que o valor
possuinãoo
formato um
permita ini estouro
que é um da memória
padrão de física
fatodopara
servidor,
arquivos
levando
de configuração
em conta que(amplamente
este limite é
utilizado
por na plataforma
operação, e pode serWindows).
alocado múltiplas vezes de forma paralela em uma consulta
e em diversas
O elemento conexões.
básico é um parâmetro que possui o formato nome = valor.
Parâmetros
Para evitar
podemestouro
ser agrupados
de memoria
em seções
de físicaque
a seguinte
são descritas
formula
porpode
[seção].
ser utilizada
O ponto
e vírgula
(em indica
qualquer um de
perfil comentário
banco): até o fim da linha.
(shared_buffers + (2*max_connections*work_mem) + (autovacuum_max_workers *
[databases]
maintenance_work_mem) ) < Total de RAM
A seção Para databases
ajudar no informa
tuning adostring de conexão
work_mem a ser utilizada
é fundamental peloo PgBouncer.
habilitar registro de
Nomes de
arquivos temporários
bancos deem dados
log através
podemda conter
opção[A-Za-z0-9_.-].
log_temp_files.
String
Quando
de conexão
definida empode
0,
conter os
registra todas
seguintes
os arquivos
parâmetros:
temporários independente do tamanho.
dbname: nome do banco de dados do servidor PostgreSQL;
20160807 15:21:46 EDT STATEMENT: select * from
●

pgbench_history order by tid;
●

No trecho acima é mostrada uma consulta que precisou de arquivo temporário,
●user: usuário do servidor PostgreSQL;
neste caso o consulta excedeu em 90112 bytes o tamanho do work_mem.
O work_mem também pode ser definido por usuário e por sessão, o que pode
ser uma boa prática caso alguns usuários específicos necessitem de mais memória.
●
connect_query: consulta executada
Além de work_mem, existe o após a conexão
parâmetro ser estabelecida mas Esta
maintenance_work_mem. antesédea
disponibilizar
memória a conexão
utilizada para os clientes;
pelos processos de manutenção como CREATE INDEX, REINDEX,
VACUUM e os autovacuum workers.
●
datestyle:
O valorinforma o estilo de data a ser utilizado;
de maintenance_work_mem pode ser aumentado quando for percebida
demora excessiva nas operações por ele limitadas, especialmente após o
crescimento da quantidade de tuplas nas tabelas envolvidas.
Benchmark com PgBouncer

1 Vamos adicionar a base bench no pgbouncer:

1$ vim /etc/pgbouncer/pgbouncer.ini
[databases]
+ bench = host=127.0.0.1 port=5432 dbname=bench
2 Reinicie o PGBouncer:
2$ kill $(pidof pgbouncer)
3$ /usr/sbin/pgbouncer d /etc/pgbouncer/pgbouncer.ini
4 $ pgbench p6432 T 300 c 50 s 40 bench Ualuno
200
Pgbouncer.ini
Shared buffers
configuração
Bancose OLAP,
um arquivo
não necessitam
de autenticação.
tanto de shared buffers quanto os OLTP, pois
eles seObeneficiam
arquivo dedoconfiguração
cache do sistema
(geralmente
de arquivos
chamado
parade
a leitura
pgbouncer.ini),
dos dados, possui
poremo
formato inideque
precisam mais
é ummemória
padrãopara
de fato
work_mem.
para arquivos
A recomendação
de configuração
inicial (amplamente
para shared
utilizadoneste
buffers na plataforma
perfil deWindows).
banco é que se utilize por volta de 10% da memória RAM
(desdeOque elemento
não excedabásico
faixaé dos
um4GB
parâmetro
a 8GB). que possui o formato nome = valor.
Parâmetros podem ser agrupados em seções que são descritas por [seção]. O ponto
ePlanejador
vírgula indica
de um comentário até o fim da linha.
consultas
[databases]
Para que que consultas complexas tenham um plano de busca ótima é
A seção databases
necessário informa tenha
que PostgreSQL a string de suficientes
dados conexão a bons
ser utilizada pelosua
para basear PgBouncer.
decisão.
Nomes
Um dadodefundamental
bancos de dados
para opodem
planejador
conter
de [A-Za-z0-9_.-].
consultas é quantidade
String de total
conexão
de cache
pode
conter os em
presente seguintes
todos níveis
parâmetros:
abaixo do PostgreSQL, seja cache do sistema de arquivos,
controladoras,
● dbname: nome storage
do banco
e afins\ldots
de dados do servidor PostgreSQL;
●
A soma de todos estes caches deve ser informado ao PostgreSQL através da
opção
● user: effective_cache_size.
usuário do servidor PostgreSQL;
●
connect_query: consulta executada após a conexão ser estabelecida mas antes de
disponibilizar a conexão para os clientes;
●
datestyle: informa o estilo de data a ser utilizado;
Consultas lentas com PgBadger
Ferramenta de analise de logs:

Evolução do PgFounine;
Relatório de consultas lentas;
Frequência de erros, checkpoints, vacuum, etc;
201
PgBadger
O PgBadger, considerado uma evolução do PgFouine, é uma ferramenta de

análise de logs que permite de forma simples identificar as consultas lentas. Ele extrai
informações do logs do PostgreSQL e gera relatórios que contém estatísticas sobre
as consultas executadas nos bancos de dados. Ele pode ser obtido através do site:
http://dalibo.github.io/pgbadger/
Além das informações sobre as consultas o PgBadger também traz as

seguintes informações:
Arquivos temporários por hora.

●
Estatísticas sobre os checkpoints
●Estatísticas sobre locks}
●Estatísticas sobre o autovacuum
●
Conexões por banco/cliente/usuários
Para gerar um relatório através do PgBadger basta executar o comando

abaixo:
$ pgbadger /var/log/postgresql/postgresqlX.Ymain.log o
pgbadger.html
Analise do consumo de banco de Dados

1 Instale o pgbadger:
1# aptget install pgbadger
2 Abra o arquivo em algum servidor com interface grática e verifique.

2# pgbadger /var/log/postgresql/postgresql9.6
main.log o analise_logs.html
202
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Consultas lentas – Plano de execução
EXPLAIN
Plano de execução;
Estimativas;
EXPLAIN ANALYZE
Plano de Execução e estimativas;
Tempo Real;
A instrução SQL é executada;
203
Após identificar as consultas lentas, deve-se identificar o motivo da lentidão da

consulta, o que é feito através da analise do plano execução. Para exibir os planos de
execução o PostgreSQL dispõem dos seguintes comandos:
●
EXPLAIN: Apenas exibe o plano de execução e suas estimativas, sem executar a
consulta.
●EXPLAIN ANALYZE: Exibe o plano de execução, suas estimativas e mostrando os
tempos reais de cada etapa, pois neste caso a consulta é executada.
No exemplo abaixo temos a execução de um `ÈXPLAIN'':

bench=# explain select * from pgbench_branches ;
QUERY PLAN
--------------------------------------------------------------------
Seq Scan on pgbench_branches (cost=0.00..15.20 rows=20 width=364)
Neste caso o planejador de consultas optou por fazer uma busca sequencial.
O custos acima representam:

●Custo estimado para iniciar o retorno dos dados, por exemplo ordenar dados de um
ORDER BY, neste caso 0.

●Custo estimado para executar o plano, neste caso 15.20 .
●
Numero estimado de linhas a ser retornado.
●Tamanho média estimado (bytes) das linhas.
Analise do consumo de banco de Dados

1 Conecte no banco de dados bench conforme abaixo:
1 $ psql p6432 Ualuno bench
2 Execute o comando EXPLAIN conforme segue:
2pgbadger=# EXPLAIN
SELECT *
FROM pgbench_accounts
JOIN pgbench_branches ON
(pgbench_accounts.bid=pgbench_branches.bid)
WHERE aid<10;
3 Colete o conteúdo e coloque no site:
https://explain.depesz.com/
204
Neste caso temos um plano de execução com 4 etapas:
● Primeira etapa fara a busca através de índices na pgbench_accounts

● A partir do resultado anterior será criada uma hash table
●
Sera feito uma busca sequencial na tabela pgbench_branches
●
E por fim sera feito um hash join para unir os resultados
De acordo com o plano mostrado a etapa mais custosa seria o hash join, agora
vamos conferir se as estimativas estão corretas executando um EXPLAIN ANALYZE:
bench=# explain analyze select * from pgbench_accounts join pgbench_branches on

(pgbench_accounts.bid=pgbench_branches.bid) where aid<10 ;
Como visto acima, a estimativa do hash join realmente é parte mais custosa
desta consulta, pois seu tempo foi o maior de todas etapas.
Monitoramento e Tunning PostgreSQL
Recapitulando
Monitoramento Pontual;
Monitoramento Contínuo;
Benchmark com pgbench;
Tunning OLAP e OLTP;
Explain e Explain Analize;
205
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Replicação e Alta do MySQL
Disponibilidade
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Replicação e Alta Disponibilidade
Objetivos da Aula
➢ Configurar replicação assíncrona;
➢ Configurar replicação síncrona;
➢ Configurar replicação em cascata;
➢ Usar slots de replicação;
➢ Promover Slave a Master.
207
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Streaming Replication
➢ Streaming Replication;
➢ 1 Master – X Slaves;
➢ Slave online somente leitura;
➢ Replicação física;
➢ Versão e arquitetura idênticas;
➢ Alta disponibilidade;
➢ Replicação síncrona e assíncrona;
➢ HOT-STANDBY.
208
Neste capítulo será mostrado como é realizada a replicação no PostgreSQL de forma

nativa.
Hot-standby com Streaming Replication
O modelo Hot-standby, introduzido na versão 9.0, consiste de um servidor master e

de um slave, que permanece online somente para consultas até que seja promovido
a master e passe a permitir escrita e leitura.
A replicação nativa do PostgreSQL é física, por isso, não é possível replicar somente
alguns objetos, ou seja, na replicação nativa somente é possível realizar a replicação
do um cluster como um todo. Por ser uma replicação física, também é necessário
que a versão e arquitetura do PostgreSQL sejam idênticas.
Além de permitir a alta disponibilidade, a replicação em hot-standby, também

permite o balanceamento de consultas ou isolar consultas pesadas de sistemas de
BI.
O funcionamento do hot-standby é bem similar a um backup PITR, porém, com as

seguintes diferenças:
➢ Logs de transação são aplicados assim que chegam ao slave;
➢ Logs de transação podem ser transmitidos através de streaming, ou seja, as

transações são replicadas no momento em que são concluídas, não havendo a
necessidade de esperar preenchimento do segmento.
É importante salientar que o uso do streaming replication não é obrigatório para o

hot-standby, inclusive é possível se utilizar de streaming replication e archiving
juntos, de forma que se a conexão do streaming for cortada por algum motivo, o
PostgreSQL passa a utilizar os segmentos arquivados.
É possível ter várias réplicas de um master e, a partir da versão 9.2, é possível

cascatear réplicas de réplicas.
Streaming Replication
210
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando o Servidor Master
1 Crie o usuário de replicação do servidor dbmaster:

1=# CREATE USER replicacao REPLICATION PASSWORD '4linux';
2 Realize os ajustes necessários no pg_hba.conf:

host replication replicacao 192.168.200.60/32 md5
3 Realize os ajustes no postgresql.conf:

wal_level = replica #antigo hot standby
max_wal_senders = 3
wal_keep_segments = 100
wal_sender_timeout = 60s
hot_standby = on
archive_command = 'cp %p /pg_backup/arquivamento/%f >/dev/null'
Execute os comandos no servidor: dbmaster.

211
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando o Servidor Slave
1 Pare o PostgreSQL e edite o arquivo de configuração:

listen_addresses = '*'
wal_level = replica
max_wal_senders = 3
hot_standby = on
2 Configure o diretório para replicação da tablespace tbsdexter:

3# mkdir /tbsdexter
4# chown R postgres. /tbsdexter
6# rm rf /var/lib/postgresql/9.6/main/*
212 Execute os comandos no servidor: dbstandby1.
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Realizando Carga Inicial da Replicação
1 Com o usuário postgres faça a carga inicial dos dados:

1$ pg_basebackup D /var/lib/postgresql/9.6/main P v h
dbmaster p 5432 U replicacao
2 Configurar a replicação no arquivo recovery.conf:

2$ vim /var/lib/postgresql/9.6/main/recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=dbmaster port=5432 user=replicacao
password=4linux application_name=dbstandby1'
trigger_file = '/tmp/psql.trigger'
3 Inicie o PostgreSQL e acompanhe os LOG's.
4 Faça validações realizando alterações no Master e verificando se as

alterações são refletidas no Slave.
213 Execute os comandos nos servidores: dbstandby1 e usuário postgres.
Da mesmo forma que o backup PITR, para criar uma réplica é necessário efetuar um
backup base, como apresentado no capítulo anterior. Porém, para facilitar este
procedimento, existe a ferramenta pg_basebackup.
O pg_basebackup deve ser executado na máquina slave da seguinte forma:
pg_basebackup D /var/lib/postgresql/9.4/slave P v h
192.168.200.50 p 5432 U replicacao
Criação do recovery.conf
Assim como no backup PITR, na replicação também é necessário o uso do

recovery.conf, que neste caso deve conter as seguintes informações:
➢ standby_mode: Deve ser on;

➢ primary_conninfo: Neste campo devem ser preenchidos os dados de conexão
com master para o streaming replication;
➢ trigger_file: Informar o caminho de um arquivo de gatilho. Quando este arquivo for
criado, o slave é promovido a master.
Veja o exemplo abaixo:
standby_mode = 'on'
primary_conninfo='host=127.0.0.1 port=5433 user=teste
password=123456 application_name=slave
trigger_file = '/tmp/psql.trigger'
Opcionalmente pode-se colocar o restore_command caso queira utilizar o archiving

em conjunto com o streaming replication.
Cascading Replication
215
Cascading Replication
O modelo de replicação em cascata permite que um servidor Standby (em espera)

aceite conexões de replicação e transmita registros do WAL para outros servidores
Standby, agindo como um Relay. Essa solução pode ser usada para reduzir o
número de ligações diretas para o servidor Master e também minimizar o consumo de
largura de banda.
Configurando Replicação por Cascata
1 Pare o PostgreSQL e edite o arquivo pg_hba.conf:

host replication replicacao 192.168.200.70/32 md5
2 Agora edite o postgresql.conf:

archive_mode = on
archive_command = 'exit 0'
hot_standby = on
3 Reinicie o PostgreSQL:
3# systemctl restart postgresql
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando Replicação por Cascata
1 Com o usuário postgres, faça o backup dos arquivos de conf:

1$ cp /var/lib/pgsql/9.6/data/*.conf /tmp
2 Prepare o ambiente para a replicação dos dados:

2# mkdir /tbsdexter
3# chown R postgres. /tbsdexter
5# systemctl stop postgresql9.6
6# rm rf /var/lib/pgsql/9.6/data/*

7$ pg_basebackup D /var/lib/pgsql/9.6/data P v
h dbstandby1 p 5432 U replicacao
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando Standby2
1 Altere o arquivo recovery.conf:

1$ vim /var/lib/pgsql/9.6/data/recovery.conf
primary_conninfo = 'host=dbstandby1 port=5432 user=replicacao
password=4linux application_name=dbstandby2'
2 Volte o backup dos arquivos e edite o postgresql.conf:

2$ cp /tmp/*.conf /var/lib/pgsql/9.6/data
3$ vim /var/lib/pgsql/9.6/data/postgresql.conf
wal_level = replica Inicie o PostgreSQL “systemctl
3
hot_standby = on start postgresql-9.6”.
max_wal_senders = 3
Execute os comandos nos servidores:
hot_standby = on
dbstandby2 e usuário postgres.
218
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Tipos de Replicações
Hot-Standby - ➢ Replicação Default;

Asíncrono ➢ Pode haver atraso de dados.
➢ O commit só é feito depois da replicação;

Hot-Standby - ➢ Não há atraso algum;
Síncrono ➢ Afeta o desempenho do master;
➢ O Slave pára o Master também pára.
219
A partir da versão 9.1 do PostgreSQL foi introduzido o recurso de replicação

síncrona, que consiste no mesmo tipo de replicação do hot-standby, porém, neste
caso, o master e o slave sempre serão idênticos, não havendo nenhum tipo de
atraso entre os servidores.
Ao decidir por utilizar a replicação síncrona, deve-se verificar a real necessidade, pois
seu uso afeta o desempenho do banco, devido a necessidade do master aguardar
pela efetivação no slave. O tempo de mínimo de uma transação será o tempo para
gravar os dados no master somado com o tempo gasto para trafegar na rede somado
com o tempo de gravação no slave.
A replicação síncrona pode ser uma necessidade em alguns casos, porém, na

maioria dos casos, a replicação assíncrona atende sem problemas.
Para minimizar o impacto gerado pela replicação síncrona, recomenda-se a

utilização de rede de baixa latência.
Configurando a Replicação Síncrona
1 Veja o status da replicação na view pg_stat_replication:

1=#SELECT * FROM pg_stat_replication;
2 Edite o arquivo postgresql.conf para tornar a replicação síncrona:

synchronous_standby_names = 'dbstandby1'
3 Faça o reload do postgres e verifique a view de replicação:

3=#SELECT * FROM pg_stat_replication;
4 Pare o PostgreSQL do Standby e tente realizar uma alteração no dbmaster.
5 Volte o servidor Standby e veja a alteração acontecer.
220 Execute os comandos no servidor: dbmaster.
Para habilitar a replicação síncrona, basta incluir o application_name do servidor slave na

opção synchronous_standby_names. Lembrando que o application_name do slave é
definido no seu recovery.conf.
É importante enfatizar que quando se utiliza a replicação síncrona, caso o slave pare, o
master também para, pois ficará indefinidamente aguardando pelo slave. Para evitar que
isso aconteça, deve-se ter um segundo slave que assumirá como síncrono caso o slave
primário pare.
Os servidores slaves adicionais devem ser passados por vírgula na opção

synchronous_standby_names. Note que somente o primeiro assume como síncrono, os
outros permanecem em modo assíncrono. Veja o exemplo:
synchronous_standby_names=slave,slave2,slave3
No exemplo acima, o slave ficará em modo síncrono. O slave2 permanece em modo

assíncrono, a menos que o slave pare. O slave3 só assume o modo síncrono caso o slave e
o slave2 parem.
Para monitorar o estado da replicação, basta consultar a view pg_stat_replication no

servidor master: select * from pg_stat_replication ;.
Para promover um servidor slave a master, basta criar o arquivo de trigger definido no seu
recovery.conf.
Slot de Replicação
➢ Faz a retenção de WAL no Master;
➢ Deve-se monitorar o ambiente;
➢ Dimensionar o disco do WAL de acordo;
➢ Importante para ambiente crítico;
➢ Remover o slot quando não estiver em uso.
221
Replication Slots
O modelo de replicação por slots é uma das novidades no PostgreSQL 9.4. Slots de
replicação fornecem uma maneira automatizada para garantir que o Master não remova
segmentos do WAL até que tenham sido recebidas por todos os servidores Standby, e que o
servidor Master não remova linhas que poderiam causar um conflito de recuperação, mesmo
quando os servidores Standby são desligados.
O Slot de replicação é importante para se obter detalhes do status da replicação, pois

impede que, caso o servidor slave por qualquer motivo fique indisponível, o servidor master
irá reter os arquivos de WAL. Dessa forma, quando o servidor slave for restabelecido, será
possível realizar a sincronia utilizando apenas os arquivos de WAL, pois o Master impedirá a
remoção dos WAL's, mesmo que configurado o parâmetro “wal_keep_segments”.
Um cuidado a mais precisa ser tomado, pois caso o servidor slave fique muito tempo
indisponível, como os arquivos de WAL irão aumentar continuamente o espaço em disco,
ficará comprometido, causando uma parada do servidor Master.
Caso queira remover um slot depois de remover um servidor que estava utilizando a
replicação após a remoção do servidor, é necessário remover o slot com os comandos:
postgres=# SELECT * FROM pg_replication_slots ;
postgres=# select pg_drop_replication_slot('nome_do_slot');
Slot de Replicação
1 Veja os slots de replicação na view pg_stat_replication:

1=#SELECT * FROM pg_replication_slots;
2 Edite o arquivo postgresql.conf e reinicie o PostgreSQL:

max_replication_slots = 3
3 Crie o slot utilizando a função e depois valide:
3=#SELECT * FROM
pg_create_physical_replication_slot('slot_standby1');
4=#select * from pg_replication_slots;
Execute os comandos no servidor: dbstandby1.
4 Adicione uma linha no recovery.conf, reinicie o PostgreSQL e valide:

5# vim /var/lib/postgresql/9.6/main/recovery.conf
primary_slot_name = 'slot_standby1'
222
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Promovendo Servidor Slave a Master
1 Pare o PostgreSQL do servidor Master simulando um desastre:

1# systemctl stop postgresql
2 Tente realizar alguma operação de escrita no Slave:

2=# create database disaster;
3 O Standby1 está como somente leitura. Promova-o a Master:

3# touch /tmp/psql.trigger
4 Agora realize testes de escrita:

4=# create database disaster;
Perceba que o arquivo “recovery.conf”

foi renomeado para “recovery.done”.
Execute os comandos nos servidores: db master e dbstandby1.

223
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Replicação e Alta Disponibilidade
Nesta aula vimos:

Recapitulando
➢ Replicação assíncrona;
➢ Replicação síncrona;
➢ Replicação em cascata;
➢ Slots de replicação;
➢ Promoção de Slave a Master
224
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
REPMGR (Replication
Características e InstalaçãoManager)
do MySQL
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
REPMGR (Replication Manager)
Objetivos da Aula
➢ Utilizar o Replication Manager;
➢ Configurar um servidor Witness;
➢ Automatizar o processo de desastre;
➢ Separar escrita e leitura com pgpool.
226
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Cenário Proposto
227
Master
O arquivamento contínuo pode ser usado para criar uma configuração de cluster de
alta disponibilidade (HA) com um ou mais servidores de espera, prontos para assumir
as operações caso o servidor primário falhe. Um servidor primário funciona no modo
de arquivamento contínuo.
Standby
O servidor Standby (modo de espera) é criado para para assumir as operações caso
o servidor primário falhe. Enquanto o servidor primário funciona no modo de
arquivamento contínuo, cada servidor Standby opera em modo de recuperação
contínua, lendo os arquivos do WAL do primário.
Cenário Proposto
NOTA
228
Witness
O servidor testemunha deve conter uma cópia das tabelas de metadados repmgr,
mas não será configurado como um servidor em modo de espera (Standby). Em vez
disso, irá atualizar as cópias de metadados cada vez que ocorre um failover.
Ele pode detectar automaticamente as falhas de outros nós e, em seguida, decidir

qual o servidor deve se tornar o novo mestre, votando entre todos os nós de espera
ainda disponíveis.
Pgpool
É uma ferramenta que pode ser usada tanto para gerenciamento da replicação, como
para segmentação de escrita e leitura. Esse aplicativo ficará instalado junto com o
servidor witness e poderá ser usado para conexão ao banco de dados.
Cenário Proposto
229
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Replication Manager
➢ Ferramenta Opensource;
➢ Gerencia a Replicação;
➢ Gerencia Failover;
➢ Monitora a Replicação
➢ Usa pg_basebackup;
➢ Tem suporte a slots de replicação;
➢ Suporta replicação em Cascata.
230
O repmgr é uma ferramenta open-source para gerenciar a replicação e failover entre

vários servidores PostgreSQL. Ela aprimora os recursos de hot-standby internos do
PostgreSQL com ferramentas para:
➢ Configurar servidores em espera (Standby);

➢ Monitorar a replicação;
➢ Executar tarefas administrativas;
➢ Realizar operações de failover.
O repmgr inclui dois componentes:
➢ repmgr: Fornece um conjunto de ações de linha de comando que realizam todas as

atividades necessárias em um nó;
➢ repmgrd: Daemon utilizado na gestão e monitoramento do Cluster.
Requisitos de Instalação Replication Manager
➢ PostgreSQL dos nós na mesma versão;*
➢ Troca de chaves entre os servidores;
➢ Instalação do repmgr e rsync necessária;
➢ Todas os clusters em archive;
➢ Todos os clusters com hot-standby;
➢ PG_HBA coerente nos clustes.

Lembre-se:
Qualquer nó pode
ser Master!
231
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Preparando Servidor Master
1 Instale o Replication Manager e o rsync:

1#aptget install repmgr rsync y
2 Com o usuário postgres crie o usuário e a base “repmgr”:

2$ createuser s repmgr
3$ createdb repmgr O repmgr
3 Faça uma carga de dados no banco repmgr:

4$ psql repmgr <
/usr/share/postgresql/9.6/contrib/repmgr_funcs.sql
4 Valide se o usuário postgres está com a chave ssh criada.
Diretivas de configuração:
➢master_response_timeout: Define a quantidade máxima de tempo que o nó vai

esperar antes de decidir que o nó Master morreu e iniciar o procedimento de failover;
➢reconnect_attempts: Define o número de vezes que o nó vai tentar reconectar no
nó Master após ter sido detectada uma falha e antes de iniciar o procedimento de
failover;
➢reconnect_interval: Define a quantidade de tempo entre as tentativas de
reconectar-se no nó Master depois de ter sido detectada uma falha e antes de iniciar
o procedimento de failover;
➢failover: Define o tipo de Faiolver, podendo ser manual ou automático;
➢promote_command: Define o comando executado para fazer o failover (incluindo o
próprio failover PostgreSQL). O comando deve retornar 0 em caso de sucesso;
➢follow_command: Define o comando executado para o nó Standby seguindo outro
nó Master no Cluster. O comando deve retornar 0 em caso de sucesso.
A ferramenta repmgr fornece um conjunto de ações de linha de comando único que

realizam todas as atividades necessárias em um nó. A opção register registra o
mestre atual no cluster.

Edite o arquivo pg_hba.conf para permitir conexões ao repmgr:
1
1#vim /etc/postgresql/9.6/main/pg_hba.conf
host repmgr repmgr 192.168.200.0/24 trust
host replication repmgr 192.168.200.0/24 trust
2 Crie o diretório de configuração do repmgr e edite o arquivo:

2# mkdir /etc/repmgr
3# vim /etc/repmgr/repmgr.conf
cluster=dexter
node=1
node_name=dbmaster
conninfo='host=dbmaster user=repmgr dbname=repmgr'
pg_bindir=/usr/lib/postgresql/9.6/bin
use_replication_slots=1
failover=automatic
promote_command='repmgr standby promote f /etc/repmgr/repmgr.conf'
follow_command='repmgr standby follow f /etc/repmgr/repmgr.conf'
loglevel=NOTICE
logfile='/var/log/postgresql/repmgr.log'
Ajustes de Segurança
Caso a replicação por Streaming esteja ativada em modo síncrono, é necessário comentar a
diretiva synchronous_standby_names.
É preciso configurar a autenticação no Postgres, liberando o acesso aos usuários repmgr
aos bancos repmgr e replication. Na quarta coluna estamos informando o IP da rede e sua
máscara.
Diretivas de Configuração:
➢shared_preload_libraries: Esta variável especifica uma ou mais bibliotecas compartilhadas a serem
pré-carregados na inicialização do servidor;
➢wal_level: Determina a quantidade de informação e é escrito para o WAL. O valor padrão é mínimo, o
que escreve apenas as informações necessárias para se recuperar de uma falha ou desligamento
imediato.
➢archive_mode: Quando o archive_mode está ativado, os segmentos do WAL concluídos são enviados
para armazenamento de arquivos, definindo como archive_command;
➢archive_command: Define o comando que será executado para arquivar um segmento de arquivo
WAL concluído;
➢max_wal_senders: Define o número máximo de conexões simultâneas a partir dos servidores de
espera (total de slaves + 1);
➢wal_keep_segments: É o número de segmentos extras a serem mantidos no pg_xlog do Master;
➢max_replication_slots: Especifica o número máximo de slots de replicação que o servidor pode
suportar;
➢hot_standby: Quando ativado transforma o nó em em um servidor de espera. Todas essas conexões
são estritamente somente leitura.
1 Faça o reload do PostgreSQL.

1# service postgresql reload
2 Altere as permissões do diretório do repmgr:

2# chown R postgres. /etc/repmgr
Com o postgres, registre o dbmaster como master e inicialize o

3
daemon do repmgr:
3# su postgres
4$ repmgr f /etc/repmgr/repmgr.conf verbose master register
5$ repmgrd f /etc/repmgr/repmgr.conf d &
4 Exiba o status dos servidores:

5$ repmgr f /etc/repmgr/repmgr.conf cluster show
O arquivo repmgr.conf utilizado durante a replicação não deve ser armazenado

dentro do diretório de dados PostgreSQL. O recomendado é criá-lo em
/etc/repmgr/repmgr.conf.
Diretivas de configuração:
➢ cluster: Nome que representa a replicação.

➢ node: Define o número de nó corrente (1 no master, 2 e 3 nos standby).
➢ node_name: É um identificador para cada nó no Cluster.
➢ conninfo: Usado para se conectar ao servidor PostgreSQL a partir de qualquer nó.
Nesta diretiva precisamos informar o nome do usuário e banco utilizado na replicação.
➢ use_replication_slots: Ativa o uso de replicação por slots.
Caso não seja possível encontrar os binários do PostgreSQL (pg_ctl,

pg_basebackup), no PATH do sistema, você pode especificar um local alternativo em
repmgr.conf através da diretiva pg_bindir:
pg_bindir = /path/to/postgres/bin
Preparando Servidor Standby1

Instale o Replication Manager e o rsync:
1
1#aptget install repmgr rsync y
2 Edite o arquivo pg_hba.conf para permitir conexões no repmgr:

2#vim /etc/postgresql/9.6/main/pg_hba.conf
3 Pare o PostgreSQL e limpe o diretório de dados:

3# systemctl stop postgresql
5# rm rf /tbsdexter/*
4 Crie o diretório de configuração do repmgr e ajuste as permissões:

O nome do cluster deve ser o mesmo em todos os nós. O valor das diretivas node e
node_name deve ser exclusivo para cada nó.
5 Com o usuário PostgreSQL edite o arquivo de conf do repmgr:

cluster=dexter
node=2
node_name=standby1
conninfo='host=dbstandby1 user=repmgr dbname=repmgr'
failover=automatic
promote_command='repmgr standby promote f /etc/repmgr/repmgr.conf'
follow_command='repmgr standby follow f /etc/repmgr/repmgr.conf'
loglevel=NOTICE
logfile='/var/log/postgresql/repmgr.log' Execute os
comandos no
servidor:
dbstandby1.
236
A diretiva shared_preload_libraries especifica uma ou mais bibliotecas

compartilhadas para serem pré-carregadas na inicialização do servidor. A biblioteca
repmgr_funcs utiliza memória compartilhada no PostgreSQL.
O suporte para failover requer uma extensão repmgr_func, que pode ser instalada
através do arquivo repmgr_funcs.sql.
6 Edite o parâmetro no arquivo postgresql.conf:
shared_preload_libraries = 'repmgr_funcs'
Execute os
comandos no
servidor:
dbstandby1.
237
A diretiva shared_preload_libraries especifica uma ou mais bibliotecas

compartilhadas para serem pré-carregadas na inicialização do servidor. A biblioteca
repmgr_funcs utiliza memória compartilhada no PostgreSQL.
O suporte para failover requer uma extensão repmgr_func, que pode ser instalada
através do arquivo repmgr_funcs.sql.
1 Instale o Replication Manager e o rsync:

1# yum install repmgr96 rsync y
2 Edite o arquivo pg_hba.conf para permitir conexões no repmgr:

2#vim /var/lib/pgsql/9.6/data/pg_hba.conf

3 Edite o arquivo postgresql.conf:

3#vim /var/lib/pgsql/9.6/data/postgresql.conf
archive_mode = on
archive_command = 'exit 0'
max_replication_slots = 3
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________

4 Edite o arquivo de conf do repmgr: Execute os
1# vim /etc/repmgr/9.6/repmgr.conf
comandos no
cluster=dexter
servidor:
node=3
dbstandby2.
node_name=standby2
conninfo='host=dbstandby2 dbname=repmgr user=repmgr'
failover=automatic
loglevel=NOTICE
logfile='/var/log/repmgr/repmgr9.6.log'
5 Altere as permissões do diretório de configuração:

3# systemctl stop postgresql9.6
4# cp r /var/lib/pgsql/9.6/data/p*.conf /root
5# rm rf /var/lib/pgsql/9.6/data/*
6# rm rf /tbsdexter/*
239
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando Servidor - Witness

Execute os comandos abaixo no servido witness
1 Inserir o repositório:
+ deb http://apt.postgresql.org/pub/repos/apt/ trustypgdg main
2 Realize o download da chave do PostgreSQL e adicionar ao apt:
3 Atualize a lista de pacotes do repositório:

4 # aptget update
240
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
1 Instale o replication manager e crie o diretório necessário:

1# aptget install repmgr postgresql9.6
Execute os
2 Edite o repmgr.conf e altere o dono do diretório:
comandos
no servidor:
cluster=dexter
witness.
node=4
node_name=witness
conninfo='host=witness user=repmgr dbname=repmgr port=5499'
loglevel=NOTICE
logfile='/var/log/postgresql/repmgr.log'

4# chown R postgres. /etc/repmgr/
241
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________

1 Copie as chaves ssh no servidor dbmaster
1#rsync avz ~postgres/.ssh/* witness:~postgres/.ssh/
Execute os comandos no servidor: witness.
2 Edite o pg_hba.conf:

242
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Replicando Chaves SSH

1 Copie a chave do usuário postgres do dbmaster para os outros

servidores:
1# rsync avz ~postgres/.ssh/* dbstandby1:~postgres/.ssh/
2# rsync avz ~postgres/.ssh/* dbstandby2:~postgres/.ssh/
Execute os comandos no servidor: dbstandby1 e witness.

2 Altere as permissões do diretório:
4# chown postgres. /var/lib/postgresql/.ssh/
Execute os comandos no servidor: dbstandby2.
3 Altere as permissões do diretório:

5# chown postgres. /var/lib/pgsql/.ssh/
4 Teste a intercomunicação entre todos os servidores com o usuário

postgres, garantindo a autenticação sem senha:
6$ ssh [dbmaster, dbstandby1, dbstandby2, witness]
243
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Checklist de Implementação Replication Manager
➢ PostgreSQL: conf, hba, repmgr - OK

Servidor
➢ Replication Manager: Inst, conf – OK
MASTER
➢ Registro no repmgr - OK
➢ PostgreSQL: conf, hba - OK

Servidor ➢ Replication Manager: Inst, conf – OK
SLAVES ➢ Clone e sincronia – Pendente
➢ Registro no repmgr – Pendente
244
Sincronizando e Registrando - Standby1

1$repmgr f /etc/repmgr/repmgr.conf \
D /var/lib/postgresql/9.6/main \
d repmgr U repmgr \
verbose copyexternalconfigfiles \
standby clone h dbmaster
2 Inicie o PostgreSQL com o usuário root:
2# systemctl start postgresql
3 Com o usuário postgres registre o servidor slave e inicialize o deamon do

repmgr:
3$ repmgr f /etc/repmgr/repmgr.conf standby register
4 Valide o status do Cluster:

5$ repmgr f /etc/repmgr/repmgr.conf cluster show
Opções de linha de comando:
➢ -D ( --data-dir=DIR ): Diretório local onde os arquivos serão copiados;

➢ -f ( --config-file=PATH ): Define o caminho do arquivo de configuração;
➢ -d ( --dbname=DBNAME ): Nome do banco de dados que será replicado;
➢ -U ( --username=USERNAME ): Nome do usuário usado na conexão com o nó
Master.
Sincronizando e Registrando - Standby2

1$ /usr/pgsql9.6/bin/repmgr f /etc/repmgr/9.6/repmgr.conf \
D /var/lib/pgsql/9.6/data/ d repmgr U repmgr \
copyexternalconfigfiles=pgdata verbose standby clone h
dbmaster
2 Com o usuário root recupere os arquivos de conf: Execute os
2# cp /root/p*.conf /var/lib/pgsql/9.6/data/ comandos no
3# chown R postgres. /var/lib/pgsql/9.6/data servidor:
3 Inicialize o serviço do PostgreSQL e o deamon do repmgr: dbstandby2.

4# systemctl start postgresql9.6
5$ /usr/pgsql9.6/bin/repmgr f /etc/repmgr/9.6/repmgr.conf
4 Registre o servidor com o usuário postgres e verifique o status:

standby register
246 cluster show
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Comandos do Replication Manager
MASTER SLAVES CLUSTER GERAL

register register / show force (F)
unregister
clone cleanup verbose
promote configfile (f)
follow rsynconly (r)
switchover
disconect
manual
247
Opções de linha comando:
➢ register: Registra um nó no Cluster;

➢ clone: Prepara um novo nó Standby clonando o $PGDATA do nó Master;
➢ promote: Promove um nó Standby em um novo nó Master no Cluster;
➢ follow: Solicita a um nó Standby seguir um novo nó Master no Cluster;
➢ show: Verifica o status de cada nó registrado no Cluster;
➢ cleanup: Solicita um pedido de limpeza de dados de monitoramento;
➢ --force: Forçar operações que são potencialmente perigosas;
➢ --verbose: Exibe de forma detalhada as operações da ferramenta repmgr;
➢ --config-file: Especifica o caminho para o arquivo repmgr.conf;
➢ --rsync-only: Usa somente o comando rsync para clonar um Standby.

Edite o arquivo de configuração do PostgreSQL:
4
Port = 5499

4$ ln s /usr/lib/postgresql/9.6/bin/pg_ctl /bin/
6 Com o usuário postgres crie o servidor witness:

5$ cd /etc/repmgr
6$ repmgr d repmgr U repmgr h dbmaster verbose \
force D /var/lib/postgresql/9.6/main witness create
8$ repmgr cluster show
7 Inicie o PostgreSQL: Execute os comandos no

9# service postgresql start
servidor: witness.
248
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
PGPOOL-II
➢ Ferramenta Opensource;
➢ Gerencia a Replicação;
➢ Load Balancer;
➢ Pooler de conexões.
249
O que é o Pg-poolII?
É um middleware que funciona entre os servidores do PostgreSQL e um cliente de banco de
dados PostgreSQL. É licenciado sob a licença BSD. Abaixo algumas de suas funções:
Pooler de Conexões
Pode gerenciar conexões com os servidores PostgreSQL e reutilizá-los sempre que uma nova
conexão com as mesmas propriedades que o pgcouncer ocorrer em modo de transação,
além de poder gerenciar vários servidores PostgreSQL.
Load Balancer
Quando a arquitetura utilizada possui réplicas, a execução do SELECT em qualquer servidor
irá devolver o mesmo resultado, enquanto as escritas são direcionadas sempre para o
servidor MASTER.
Limitando Conexões
Há um limite para o número máximo de conexões simultâneas com o PostgreSQL. As
conexões que ultrapassam o limite são rejeitadas. O pgpool-II também tem um limite para o
número máximo de conexões, mas conexões extras serão enfileiradas em vez de retornar um
erro imediatamente.
Transparência
Diz o protocolo de backend e frontend do PostgreSQL e transmite uma conexão entre eles.
Portanto, o pgpool-II é transparente para o servidor e o cliente.
Instalando o PGPOOL 2
Instale os pacotes: Execute os comandos no servidor: witness.
1
1# aptget install postgresql9.6pgpool2 pgpool2 y
2 Edite o arquivo de configuração:

2# vim /etc/pgpool2/pgpool.conf
backend_hostname0 = '192.168.200.50'
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = '/var/lib/postgresql/9.6/main'
backend_flag0 = 'ALLOW_TO_FAILOVER'
backend_weight1 = 1
backend_data_directory1 = '/var/lib/postgresql/9.6/main'
backend_weight2 = 1
backend_data_directory2 = '/var/lib/pgsql/9.6/data'
250
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando o PGPOOL 2
Pegue os dados de autenticação com a consulta no banco master:
3
1$ postgres=# select rolname, rolpassword from pg_authid;
4 Utilize o conteúdo para editar os arquivos de senha:

2# vim /etc/pgpool2/pcp.conf
aluno:md596b565550b58e3d2a4e3028186fd815a
dexter:md5bd5a10d1473c21b2fd32a9ea540b49e2
3# tail 2 /etc/pgpool2/pcp.conf > /etc/pgpool2/pool_passwd
5 Crie o usuário e o banco pgpool com o usuário postgres:

4$ createuser s pgpool
5$ createdb pgpool O pgpool
6 Acrescente as linhas abaixo em todos os pg_hbas:

host pgpool pgpool 192.168.200.0/24 trust
host replication pgpool 192.168.200.0/24 trust
251
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
Configurando o PGPOOL 2
7 Pare o pgpool e faça os testes:

1# pgpool stop
2# pgpool
3# su – postgres
4$ psql Ualuno h127.0.0.1 p5499
5=# SHOW pool_nodes;
8 Realize as seguintes atividades:

➢ Simule uma queda do Master;
➢ Simule o chaveamento de um Slave para Master;
➢ Faça testes de escrita no Master e leitura nos Slaves.
Execute os comandos no servidor: witness.

252
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
REPMGR(Replication Manager)
Nesta aula vimos:

Recapitulando
➢ Utilização do Replication Manager;
➢ Configuração de um servidor Witness;
➢ Automatização do processo de desastre;
➢ Separação da escrita e leitura com pgpool.
253
Anotações:
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________

Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Administrac ºa Âo PostgreSQL Com Alta Performance e Alta Disponibilidade

Título original:

Enviado por

Direitos autorais:

Amorim Weverton Rufino De / weverton.geek@gmail.

Características e Instalação do PostgreSQL

 Conhecer a Origem do PostgreSQL

Sybase Corp Informix IBM

Tandem -NonStop SQL PostgreSQL

Berkeley POSTGRES Postgres95

Tudo começou como INGRES

●Em 1992 a Microsoft licenciou alguns produtos Sybase – SQL Server

●Em 1997 a Informix adquiriu os demais direitos – Sybase

●Em 2000 a IBM tornou-se proprietária da Informix – Sybase

Pronúncia e Suporte do PostgreSQL

 PostgreSQL ou Postgres - CORRETO

●1996 O Postgres95 foi rebatizado como PostgreSQL, muitos usuários

●2010 PostgreSQL 9.0 Amadurecimento do PL/pgSQL, suporte completo a Windows

 Banco de dados ACID;

A licença utilizada é a BSD, que permite a redistribuição comercial em formato

A maioria das linguagens de programação modernas preveem interface nativa

Existem centenas de projetos livres e comerciais relacionados à administração,

Características do PostgreSQL - ACID

ACID é uma característica fundamental para os bancos de dados, pois fecha

Atomicidade: Garantir o início, meio e fim da transação a fim de que a transação só

Consistência: Com a execução de várias transações em paralelo nenhuma transação

Isolamento: As transações executadas em paralelo não podem interferir nas

Durabilidade: Após a conclusão da transação o banco precisa garantir que o dado

 9.5.X (terceiro número da versão);

 X.X (primeiro ou segundo numero da versão)

Formas de instalação do PostgreSQL

 Instalação do fornecedor do SO;

 Compilar código fonte;

Instalação do fornecedor do S.O.

● As flags utilizadas na compilação geralmente são as default;

● Em alguns casos, é a única opção disponível (ex. Windows);

● Têm suporte da comunidade;

● São compiladas com as flags definidas pela comunidade.

Compilar o código fonte

● Permite a instalação de qualquer uma das versões disponíveis do PostgreSQL.

Instalação do PostgreSQL no Debian

A comunidade PostgreSQL oferece pacotes no site www.postgresql.org. As

O one-click installer, instala o PostgreSQL no diretório /opt e é compatível com a

PostgreSQL como a documentação, FAQ, listas de discussão e wiki.

Instalação do Repositório PostgreSQL no Debian

Execute os comandos abaixo nos servidores: dbmaster e standby1

1 Servidores dbmaster e standby1 inserir o repositório:

2 Realize o download da chave do PostgreSQL e adicionar ao apt:

3 Atualize a lista de pacotes do repositório:

Instalação do PostgreSQL no Debian

Execute os comandos abaixo nos servidores: dbmaster e standby1

1 Instale o pacote com o comando apt-get install conforme segue:

2 Liste o conteúdo do diretório dos binários do PostgreSQL:

3 Localize os binários dos programas abaixo:

4 Liste as conexões da porta default do PostgreSQL:

Stop e Start do PostgreSQL no Debian

1 No servidor dbmaster realizar listar os processos do PostgreSQL:

2 Comandos para parar o PostgreSQL:

3 Comandos para iniciar o PostgreSQL:

4 Comando para reload do PostgreSQL:

Instalação do PostgreSQL no Centos

Instalação do PostgreSQL no Centos

Execute os comandos abaixo no servidor standby2

1 Realize a instalação do repositório com o comando abaixo:

2 Localize os binários da instalação:

Criando um Cluster no PostgreSQL - Centos

No CentOS o cluster do PostgreSQL não foi criado, então vamos criar:

Execute os comandos abaixo no servidor standby2:

1 Crie um cluster no diretório default do Centos: