Dextra Sistemas: Novidades do PostgreSQL 9.0

PostgreSQL: Novidades da Versão 9.0
Centro de Computação Unicamp
Setembro/2010

Soluções de Software
Sistemas e aplicações sob medida para as
necessidades do seu negócio.

Dextra Sistemas

Empresa Jovem e Inovadora, no mercado desde 1995
Serviços: Desenvolvimento de Software sob Medida, Consultoria e Treinamento
Unidades: Campinas, São Paulo e Campo Grande/MS
Certificada MPS.Br nível F, em processo CMMI 3
Reconhecida no mercado pelo alto conhecimento técnico
Eleita em 2009 e 2010 como uma das Melhores Empresas de TI para Trabalhar

Áreas de atuação

Através dos nossos serviços de Desenvolvimento de Software sob Medida, Consultoria
e Treinamento, auxiliamos médias e grandes organizações dos mais variados
segmentos a elevarem o seu patamar competitivo, adaptando-se às novas exigências
tecnológicas do mercado.

Cursos PostgreSQL

PostgreSQL Essencial

PL/pgSQL

Administração

Performance Tuning

Alta Disponibilidade

Postgis

www.dextra.com.br/treinamento

Novidades do PostgreSQL 9.0

Mais de 200 melhorias na versão 9.0
Hot standby
Streaming Replication
Melhorias na administração de privilégios dos usuários
Blocos anônimos em PL/pgSQL
Triggers condicionais e por colunas
Reimplementação do VACUUM FULL
Contrib para migração de versões
Melhorias de performance para consultas geradas por ORMs

Dupla Dinâmica
Hot standby & Streaming Replication

Santa Disponibilidade,
Batman!!!

Comparativo entre versões

Desde a versão 8.2: Warm Standby
Alta disponibilidade com servidor standby
Replicação por arquivos do WAL
Não disponibiliza o servidor standby para consultas

PostgreSQL 9.0: Hot Standby e Streming Replication
Alta disponibilidade com servidor standby
Replicação por fragmentos do WAL
Servidor standby disponível para consultas

Hot Standby

Permite a criação de bancos de dados secundários onde serão
atualizados com as transações envolvendo o BD primário
Atualização assíncrona

Permite consultas de leitura no servidor standby
Conflito: atualizações x consultas em execução
Resolução de conflito configurável
Encerrar consulta
Aguarda finalização para atualizar

Hot Standby

postgresql.conf no servidor master:
wal_level = hot_standby
archive_mode = on
archive_command = 'scp %p dextra02:/archives/%f'
archive_timeout = 120

postgresql.conf no servidor slave:
hot_standby = on

recovery.conf no servidor slave ($PGDATA):
standby_mode = 'true'
restore_command = 'cp /archives/%f %p'
trigger_file = '/tmp/arquivo_gatilho.pgsql'

Hot Standby

postgres@dextra02:~$ pg_ctl start
LOG: entering standby mode
LOG: restored log file "00000001000000000000000D" from archive
LOG: redo starts at 0/D000020
LOG: consistent recovery state reached at 0/E000000
LOG: database system is ready to accept read only connections
LOG: restored log file "00000001000000000000000E" from archive
cp: cannot stat `/archives/00000001000000000000000F': No such file
or directory
LOG: restored log file "00000001000000000000000F" from archive
cp: cannot stat `/archives/000000010000000000000010': No such file
or directory

Hot Standby

Servidor standby disponível em modo read-only:
postgres@dextra02:~$ psql pagila
pagila=# UPDATE actor SET last_update = now();
ERROR: cannot execute UPDATE in a read-only transaction
STATEMENT: UPDATE actor SET last_update = now();

Restauração ocorre paralelamente às consultas
Em caso de failover:
Conexões ativas são mantidas e autorizadas a alterar a base de
dados sem a necessidade de reconexão

Hot Standby: Limitações

Consultas nos servidores em modo standby podem causar
conflitos com as operações de restauração que ocorrem em
paralelo.
Exemplo:
Uma operação de VACUUM, ao ser replicada pode remover um
registro “morto”, que esteja sendo utilizado por uma transação
read-only;
Ao remover o registro, a consulta pode trazer resultados
incorretos.
Há duas maneiras de resolver este problema:
Parar a replicação até que a consulta finalize
Matar a consulta no servidor standby

Criação de um canal de comunicação via TCP/IP
Comunicação constante entre os servidores master e slaves,
agilizando a transferência de fragmentos de segmentos de log
de transação
Criação de processos WalSender e WalReceiver, iniciados nos
servidores master e slaves respectivamente

File-based Replication Record-based Replication


WAL LOG SHIPPING WAL
SENDER RECEIVER

wal_level = archive
max_wal_senders = 3
Define o número conexões concorrentes recebidas de
servidores standby. Cada servidor standby utiliza uma
conexão.
#wal_sender_delay = 200ms
Intervalo entre a operações de envio de fragmentos
(stream) pelo processo WalSender. Padrão: 200 ms
wal_keep_segments = 20
Números de arquivos de logs de transação que devem ser
mantidos para a recuperação, em caso de problemas com
a restauração automática

pg_hba.conf no servidor master:
host replication all 192.168.40.128/32 trust
Diretiva especial para que possa ser aceita a conexão do servidor
standby

primary_conninfo = 'host=dextra01'
String de conexão com o servidor de produção

postgres@dextra02:~$ pg_ctl start
LOG: entering standby mode
LOG: consistent recovery state reached at 0/2002FFF0
LOG: unexpected pageaddr 0/1030000 in log file 0, segment 32,
offset 196608
LOG: streaming replication successfully connected to primary
Streaming Replication isoladamente não disponibiliza o
servidor para consultas, apenas sincroniza os servidores com
os fragmentos (streams) dos logs de transação
postgres@dextra02:~$ psql
FATAL: the database system is starting up

No servidor de produção, é criado o processo WalSender:
postgres 2568 2566 08:39 00:00:00 postgres: writer process
postgres 2569 2566 08:39 00:00:00 postgres: wal writer process
postgres 2572 2566 08:39 00:00:00 postgres: stats collector process
postgres 3071 2566 0 09:01 ? 00:00:00 postgres: wal sender process
postgres 192.168.40.128(39593) streaming 0/19000000
No standby, o processo WalReceiver:
postgres 4295 1 09:01 pts/0 00:00:00 /usr/local/bin/postgres
postgres 4296 4295 09:01 00:00:00 postgres: startup process recovering
000000010000000000000020
postgres 4298 4295 09:01 00:00:00 postgres: writer process
postgres 4565 4295 09:09 00:00:00 postgres: wal receiver process
streaming 0/2000E758

As alterações que ocorrem no servidor de produção são
enviadas continuamente para os servidores standby.
A cada atualização, o stream do arquivo de log é
incrementado:
postgres: startup process recovering 000000010000000000000020
postgres: wal receiver process streaming 0/2000E758

postgres: wal receiver process streaming 0/20017BF4

postgres: wal receiver process streaming 0/20026684

Streaming Replication: Monitoramento
Informações sobre o servidor standby:
pagila=# SELECT pg_last_xlog_receive_location();
0/23AC4360
Último fragmento recebido do servidor de produção
pagila=# SELECT pg_last_xlog_replay_location();
0/23AC4360
Último fragmento aplicado durante a recuperação
Valores idênticos para as duas funções indicam que não há
informações pendentes a serem aplicadas
pagila=# SELECT pg_is_in_recovery();
true
Indica se o servidor PostgreSQL está em restauração

Streaming Replication: Monitoramento
O aplicativo pg_controldata exibe várias informações de
controle do WAL:
As seguintes informações podem ser comparadas entre os
servidores master e slaves
postgres@dextra02:~$ pg_controldata
...
Latest checkpoint location: 0/23AC6658
...
Latest checkpoint's REDO location: 0/23AC6624

Streaming Replication + Hot Standby

wal_level = hot_standby
max_wal_senders = 3
wal_keep_segments = 20
pg_hba.conf no servidor master:
host replication all 192.168.40.128/32 trust
postgresql.conf no servidor slave:
hot_standby = on
primary_conninfo = 'host=dextra01'

Streaming Replication + Hot Standby

max_standby_streaming_delay
Idêntico ao parâmetro max_standby_archive_delay
Específico para Streaming Replication
max_standby_delay = -1
Aguarda a finalização das transações que causam conflitos no
servidor standby
Ideal para ambientes onde as consultas são mais importantes
do que a sincronização dos servidores
max_standby_delay = 0
Mata as consultas que causam conflito imediatamente
Ideal para ambientes onde a sincronização é mais importante
do que as consultas do servidor standby

Cenários possíveis

Backup WAL + Hot Standby + Streaming Replication
Possibilidade de Point In Time Recovery (PITR)
Geração de relatórios nos servidores standby
Utilização de ferramenta de balanceamento de carga para
consultas
Servidor standby atualizado a cada alteração
Utilização de ferramentas que automatizem o processo de
failover:
Heartbeat

Administração de privilégios de usuários
Facilidade para alterações de privilégios em massa:
pagila=> SELECT * FROM dextra.actor;
ERROR: permission denied for relation actor
STATEMENT: SELECT * FROM dextra.actor;
Concedendo permissão de consulta para todas as tabelas do
schema dextra ao usuário foobar:
pagila=# GRANT SELECT ON ALL TABLES IN SCHEMA dextra TO foobar;
Até a versão 8.4, era possível apenas conceder/revogar
privilégios especificando uma tabela por comando:
Necessidade de gerar scripts SQL
Assistente de GRANT do PgAdmin

Administração de privilégios de usuários
Definição de privilégios padrões para futuros objetos
pagila=> CREATE TABLE clientes();
pagila=> c pagila foobar
You are now connected to database "pagila" as user "foobar".
pagila=> SELECT * FROM dextra.clientes;
ERROR: permission denied for relation clientes
STATEMENT: SELECT * FROM dextra.clientes;

Concedendo permissão de consulta para todas as futuras
tabelas do schema dextra ao usuário foobar:
pagila=# ALTER DEFAULT PRIVILEGES FOR ROLE dextra IN SCHEMA dextra
GRANT SELECT ON TABLES TO foobar;


Capacidade de executar funções sem a necessidade de criá-las
Todas as linguagens procedurais podem ser utilizadas em linha
de comando
Sintaxe:
DO [ LANGUAGE nome_linguagem ] código
Facilita tarefas de administração
Não há necessidade de CREATE/DROP FUNCTION
A estrutura das funções são mantidas:
[ DECLARE ]
BEGIN
END

pagila=> DO $$
DECLARE
stmt text;
BEGIN
FOR stmt IN SELECT 'ALTER TABLE ' ||tablename|| ' ADD COLUMN
ultima_modificacao timestamp;' FROM pg_tables WHERE schemaname = 'dextra'
AND tablename NOT LIKE 'payment_%'
LOOP
EXECUTE stmt;
END LOOP;
END
$$ LANGUAGE plpgsql;
DO
pagila=>

Triggers por colunas

Triggers disparadas com eventos de UPDATE em colunas
Evita condições lógicas e comparação de valores no código da
função
Não dispara em caso de atualização da coluna para o valor
default

CREATE TRIGGER tg_log_ativo BEFORE UPDATE OF activebool ON customer
FOR EACH ROW EXECUTE PROCEDURE log_ativo();

UPDATE customer SET activebool = false WHERE customer_id = 599;

pagila=# SELECT * FROM log_ativo WHERE customer_id = 599;
id | customer_id | first_name | activebool | last_modified
600 | 599 | AUSTIN |f | 2010-08-28

Triggers condicionais
Comparação que define se a trigger será executada
Reduz o número de execuções das funções de trigger
Elimina estruturas de condição do código da função

CREATE TRIGGER tg_log_ativo BEFORE UPDATE OF activebool ON customer
FOR EACH ROW WHEN (OLD.activebool IS DISTINCT FROM
NEW.activebool) EXECUTE PROCEDURE log_ativo();

pagila=# UPDATE customer SET activebool = true WHERE customer_id = 599;
pagila=# UPDATE customer SET activebool = true WHERE customer_id = 599;
pagila=# SELECT * FROM log_ativo WHERE customer_id = 599;
id | customer_id | first_name | activebool | last_modified
606 | 599 | AUSTIN |t | 2010-08-28

Reimplementação do VACUUM FULL

O processo de VACUUM FULL é mais rápido, pois duplica a
tabela, eliminando a original e recriando os índices
Não é mais necessária a execução do REINDEX após o VACUUM
FULL
Mais espaço em disco
VACUUM FULL 8.4
pagila=# VACUUM FULL actor;
Time: 217 613.377 ms
pagila=# REINDEX TABLE actor;
Time: 81 567.277 ms

VACUUM FULL 9.0
pagila=# VACUUM FULL actor;
Time: 98 295.479 ms

Contrib para migração de versões

A ferramenta pg_migrator está presente no contrib com o
nome de pg_upgrade
Permite a migração através dos datafiles, sem a necessida de
dump/restore
Torna o processo de migração muito rápido
Somente para migração de 8.4 para 9.0

cd /usr/local/src/postgresql-9.0beta4/contrib/pg_upgrade_support
make; make install
cd ../pg_upgrade
make; make install

pg_upgrade -d /dados/postgresql8.4/ -D /dados/postgresql9.0/ -b
/usr/local/pgsql/bin/ -B /usr/local/bin/ > upgrade.log

Melhorias de performance para queries
geradas por ORMs
Dentre as melhorias no plano de execução de consultas,
destaca-se a possibilidade de otimização com base na reescrita
Consultas podem ser reescritas e eliminarem junções (JOINs)
ineficientes
Para ferramentas ORM (Object Relational Mapping) há uma
grande melhoria de performance na geração de relatórios
Este tipo de ferramentas possuem uma tendência para escrever
junções desnecessárias

O que vem por aí...

PostgreSQL 9.1
Acesso a fontes de dados
externas via SQL
Geração de backup base
através da Streaming
Replication
Replicação síncrona
Replicação em cascata

Fale conosco

Dextra Sistemas
contato@dextra.com.br

www.dextra.com.br
São Paulo | Campinas | Campo Grande

(11) 2824-6722 | (19) 3256-6722

Dextra Sistemas: Novidades do PostgreSQL 9.0

Mais conteúdo relacionado

Mais procurados (20)

Destaque (7)

Semelhante a Dextra Sistemas: Novidades do PostgreSQL 9.0 (20)

Mais de Dextra (20)

Último (16)

Dextra Sistemas: Novidades do PostgreSQL 9.0