Olá pessoal,

Está disponível para download a versão 8.4 do PostgreSQL.

Após 16 meses de desenvolvimento, foram adicionadas quase 300 melhorias em todos os aspectos do SGBD, para mais detalhes clique aqui.

A atualização para a versão 8.4 é altamente recomendada.

• Foram desenvolvidas e aperfeiçoadas ferramentas de administração e monitoramento.
• Novos comandos foram adicionados para tornar a programação em banco de dados mais simples e compacta.
• Características avançadas do padrão SQL ANSI 2003 de windowing functions, common table expressions e consultas recursivas permitem a elaboração de relatório complexos em uma única consulta.
• Melhorias de performance em todos os aspectos. Destaque para otimização do tempo de restauração do banco e tempo de execução de consultas (semi-join e anti-join).

O grupo de desenvolvedores do PostgreSQL visa a cada versão tornar a administração e desenvolvimento nesse banco de dados mais fácil e produtivo, sem deixar de lado as características de robustez e performance que consagraram o SGBD livre mais avançado do mundo.

Confira a lista completa de cursos e consultoria PostgreSQL oferecida pela Dextra.

Enviado por: Matheus Ricardo Espanhol
Administrador de Banco de Dados, Dextra Sistemas

Os benefícios dessa replicação são muitos, fato que levou o grupo de desenvolvedores do PostgreSQL a se dedicar na criação e aperfeiçoamento de suas funcionalidades, o que antes ocorria com a ferramenta de replicação Slony-l. Como resultado dessa dedicação pode-se esperar o aumento constante do uso do Warm Standby para prover alta disponibilidade no PostgreSQL.

A partir da versão 8.2 do PostgreSQL, foi incorporada uma contrib chamada pg_standby. Este utilitário é responsável pelo gerenciamento da réplica que permanecerá em constante restauração dos logs de transação recebidos pelo servidor de produção até o momento da falha (crash) do mesmo, ocorrendo então o failover.
Com o pg_standby é possível uma replicação consistente sem ocasionar relevantes impactos à performance do sistema. Esta relação desempenho e consistência é um desafio para as soluções de replicação de banco de dados, sendo essa característica o maior benefício da replicação Warm Standby. Mas as vantagens não param por aí, o pg_standby permite também a recuperação imediata do servidor Standby, tornando-o disponível para acesso segundos após o crash do servidor de produção. Configuração de limpeza dos logs já restaurados ou armazenamento dos mesmos para backup e restauração PITR (Point in Time Recovery) também oferecem grande vantagem.

Para melhor compreender as vantagens do Warm Standby, basta analisar o funcionamento interno do PostgreSQL em relação a utilização dos logs de  transação.
SGDBs avançados utilizam intensamente a memória principal para obter desempenho no gerenciamento dos dados. Por outro lado, dados em memória são perdidos na ocasião de uma falha inesperada no servidor. Surge então, a necessidade de um armazenamento intermediário no próprio disco, porém com uma característica que permita o acesso rápido na leitura e escrita. Para suprir essa necessidade são utilizados os logs transacionais, que possuem estrutura seqüencial para facilitar o acesso ao disco. No PostgreSQL esses logs são denominados WAL (Write Ahead Logs), estão presentes no diretório $PGDATA/pg_xlog e possuem por padrão 16MB (Ver figura 1). Em um intervalo de tempo configurado ou através de comando SQL, as transações que sofreram COMMIT são transferidas do WAL para o arquivo de dados e os logs são reciclados, essa operação é conhecida como CHECKPOINT.

Figura 1 – Diretório do WAL

De tempos em tempos, as transações em memória são gravadas no WAL. As que sofreram COMMIT em memória podem ser gravadas de forma síncrona nos logs. A partir do momento que as transações estão nos logs, elas já podem ser recuperadas em caso de crash no banco de dados. Mas, e as transações que não sofreram COMMIT antes do crash? Foram perdidas, pois estavam totalmente em memória ou desfeitas se parcialmente gravadas no WAL. Observando a figura 2, pode-se entender o que acontece com as transações, nos seus possíveis estados, em caso de crash no banco de dados:

Figura 2 – Gerenciamento de transações

O PostgreSQL utiliza um método conhecido como REDO para recuperar transações presentes no WAL. O REDO consiste em refazer toda a transação através das informações contidas no WAL. Sendo assim, em caso de falha, a transação TR1 da figura acima, estaria no arquivo de dados após o CHECKPOINT, portanto não necessitaria de recuperação. A TR2 e a TR3 estariam completamente no WAL, sendo necessário o REDO para refazê-las totalmente. A TR4 sofreria o ROLLBACK do sistema e para TR5 nada precisaria ser feito, pois foi eliminada na memória.

Mas e a replicação, como acontece? Com a cópia base do banco principal no servidor Standby, após o CHECKPOINT e antes da reciclagem, os arquivos WAL podem ser transferidos para um diretório do servidor Standby. O pg_standby é responsável pela aplicação dos logs no arquivo de dados do servidor Standby, aguardar o sinal para finalizar a restauração e disponibilizar o acesso imediato ao banco recuperado.

Reforçando tecnicamente as vantagens, o arquivamento do WAL ocorre em paralelo e de forma assíncrona, portanto não interfere no desempenho do banco de dados. A constante restauração do servidor Standby, permite o início imediato do mesmo após o crash do servidor principal. Os logs podem permanecer para backup, tanto no servidor principal, quanto no servidor Standby ou podem ser eliminados após a restauração. Todo o processo de sincronização entre memória e WAL, WAL e arquivo de dados, arquivamento, transferência e restauração dos logs podem ser configurados baseados no ambiente em que está inserido. Esta técnica pode ser combinada com técnicas de identificação de indisponibilidade do servidor, podendo todo o processo ser automatizado ou monitorado.

Melhorias para essa técnica de replicação são esperadas para a versão 8.5 do PostgreSQL. Dentre elas destacam-se a implementação da replicação síncrona, conhecida como Hot Standby, o arquivamento de transações que ainda estão em memória e a disponibilização do servidor Standby para leitura.

Concluindo, esta é uma técnica de replicação que pode ser ideal para vários ambientes, porém existem várias técnicas para implementação de alta disponibilidade em ambientes críticos. A Dextra possui grande experiência na implementação de alta disponibilidade no PostgreSQL, disponibilizando esse conhecimento no treinamento de Alta disponibilidade, onde o aluno será habilitado a configurar alta disponibilidade através do PostgreSQL Warm Standby e ferramentas como SLony-I, Pgpool, entre outras.

Enviado por: Matheus Ricardo Espanhol
Administrador de Banco de Dados, Dextra Sistemas

Como o intuito de disseminar conhecimento, a Dextra Sistemas lançou este espaço para que nós, Administradores de Banco de Dados, possamos compartilhar nossas experiências diárias sobre o tema.

Neste primeiro post falaremos sobre o PostgreSQL, apresentando de forma resumida, duas funcionalidades que estarão disponíveis na versão 8.4, com lançamento previsto para maio ou junho deste ano. Uma versão beta da versão 8.4 já está disponível no site www.postgresql.org.

Um problema recorrente que os administradores de bancos de dados encontram  é em relação à configuração da codificação (conhecida como charset ou encoding) e localização (conhecida como locales) em aplicações de ambientes que possuem regras heterogêneas de linguagens e países distintos. Localização são regras que definem parâmetros de ordenação, classificação e agrupamento da informação de acordo com a localidade e a linguagem de cada região.

Em aplicações onde se tenha o requisito de suporte a múltiplas regras de localidade, precisamos que o servidor de banco de dados possua suporte, e a boa notícia é que o PostgreSQL, a partir da versão 8.4 terá esse suporte. Na nova versão, o PostgreSQL se desprende da codificação e da localização do sistema operacional e permite que em um mesmo cluster seja possível trabalhar com distintas codificações e localizações.

Após uma contextualização e a importância de se possuir uma flexibilidade e adaptação a qualquer conjunto de regras (locales), é apresentado como implementar esta funcionalidade no PostgreSQL.

Primeiro é necessário realizar a conexão a um banco de dados, e em seguida executar o comando create database.

A conexão com o PostgreSQL pode ser realizada a partir da seguinte linha:

psql postgres -U postgres

O próximo passo é a criação do banco de dados na codificação e localização desejada.

CREATE DATABASE dextra ENCODING='Latin1' COLLATE='pt_BR' CTYPE='pt_BR' TEMPLATE=template0;

Um detalhe é importante: Ao criar um banco de dados e especificar um locale diferente do padrão do cluster é necessário usar o template0 como template.

Uma forma de visualizar o banco, sua respectiva codificação e localização é:

SELECT datname,pg_encoding_to_char(encoding),datcollate,datctype FROM pg_database;

Um outro problema enfrentado pelos administradores de banco de dados é o momento de realizar um processo de restore, quando este é relativamente grande. Como uma solução de minimizar este problema, a partir da versão 8.4 será possível paralelizar o processo de restauração. Isso poderá ser feito através do parâmetro -m (multi-thread) do utilitário pg_restore.

Enviado por: João Paulo Müller da Silva
Administrador de Banco de Dados, Dextra Sistemas