Até a versão 8.4 o PostgreSQL conta com a replicação conhecida como warm standby. Esta replicação é baseada em arquivos e não cria um canal de comunicação entre os servidores master e slave. Neste tipo de replicação, o servidor master envia segmentos de logs para o servidor slave com os seguintes critérios:

• ocorrência de checkpoint de acordo com o intervalo de tempo definido no parâmetro checkpoint_timeout;
• preenchimento de certa quantidade de segmentos de logs de 16 MB, definida no parâmetro checkpoint_segments;
• ocorrência de cópia de segmentos de logs de acordo com intervalo de tempo definido no parâmetro archive_timeout.

A ferramenta do contrib do PostgreSQL, pg_standby, inicia um processo no servidor slave que aguarda por segmentos de logs enviados de tempos em tempos pelo servidor master e aplica-os no servidor de contingência. Porém, o servidor de contingência permanece iniciado exclusivamente para o processo pg_standby, ou seja, em modo de recuperação.

Replicação Warm Standby

Portanto, tem-se nesta solução de alta disponibilidade um intervalo razoável de atualização do servidor slave, além do mesmo não permitir acesso para consultas.
A partir da versão 9.0, a opção da criação de um canal de comunicação (stream) entre os servidores foi implementada, tornando a replicação mais eficiente. Esta nova funcionalidade é chamada de streaming replication.

A streaming replication permite que um servidor slave permaneça em comunicação constante como servidor master, facilitando o recebimento de segmentos de logs. Isto é possível devido aos processos Walreceiver e Walsender, iniciados nos servidores slave e master respectivamente. Esses processos utilizam um canal de comunicação criado via TCP/IP. A criação desse canal inicia-se quando o Walreceiver envia uma requisição de conexão ao servidor master, se a conexão for estabelecida, o processo Walsender é criado. A partir de então o Walsender envia ao Walreceiver as alterações efetivadas no servidor master a serem aplicadas no servidor slave.

Diferente da replicação warm standby, a streaming replication envia somente as alterações, sem considerar critérios de rotação de segmentos de logs definidos no servidor master.

Assim como na warm standby, a streaming replication também é uma replicação assíncrona, por isso ainda há um pequeno atraso entre submeter uma transação no servidor master e essas mudanças se tornarem visíveis no servidor slave. O atraso, no entanto, é muito menor se comparado com o envio de logs baseado em arquivo.

Replicação Streaming Replication/Hot Standby

Um indicador importante da eficiência da streaming replication é a quantidade de registros do WAL gerados no servidor master, mas ainda não aplicado no servidor slave. Pode-se calcular esse atraso, comparando a localização atual do WAL no servidor master com a localização do WAL recebido pelo servidor slave. Essas informações podem ser recuperadas usando as funções pg_current_xlog_location no servidor master e pg_last_xlog_receive_location no servidor slave. A ultima localização do WAL recebida pelo servidor slave também é exibida no status do processo Walreceiver.

Além desta nova característica, o sistema de replicação nativo do PostgreSQL, conta com uma nova funcionalidade, na qual as bases replicadas permanecem em modo read-only, onde são possíveis somente comandos de leitura (hot standby).

O termo hot standby se refere à capacidade do servidor slave mover operações de recuperação para operações normais, ou seja, possibilitar a execução de consultas ao mesmo tempo em que as alterações efetivadas no servidor master estejam sendo replicadas.  Isto é útil tanto para fins de replicação quanto para restaurar um backup para um estado desejado com grande precisão (PITR).

A replicação streaming replication/hot standby garante a segurança sem afetar  significativamente a performance do servidor de produção. A replicação do servidor master para vários slaves possibilita a definição de  estratégias de alta disponibilidade, sem a necessidade de ferramentas de terceiros.

Portanto o PostgreSQL 9.0, realça ainda mais o objetivo da comunidade de software livre em desenvolver um SGBD cada vez mais avançado e robusto. Visando assim, atender as necessidades de  ambientes corporativos que exigem segurança, performance e alta disponibilidade dos dados.

Este tipo de replicação já faz parte do conteúdo do curso de Alta Disponibilidade promovido pela Dextra Sistemas. Esta e outras estratégias de replicação praticadas no treinamento, fornecem ao aluno o conhecimento necessário para definir estratégias de alta disponibilidade voltadas a diversos ambientes.

• 0 Comentários

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.

• 0 Comentários

O Sistema Gerenciador de Banco de Dados (SGBD)  PostgreSQL possui vários recursos para replicação de dados, método essencial para promover a alta disponibilidade de sistemas. Neste artigo será abordada a técnica de replicação Warm Standby, que é realizada através do arquivamento dos logs de transação (log shipping).

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.

• 1 Comentário