PostgreSQL 9.0: Hot Standby e Streaming Replication

A documentação descreve o Warm Standby como uma solução de alta disponibilidade no PostgreSQL, presente desde a versão 8.2 e aprimorada na versão 9.0. Nesta versão, destaca-se a eliminação da necessidade de instalar a extensão pg_standby. O Warm Standby utiliza o arquivo recovery.conf no servidor slave com o parâmetro standby_mode = 'true', indicando que o PostgreSQL permanecerá em modo de restauração, utilizando restore_command ou WalReceiver. O parâmetro wal_level é crucial, controlando o nível de informação gravada no WAL (Write-Ahead Log): minimal registra o mínimo para recuperação após falha, enquanto archive registra informações para recuperação via arquivamento do WAL ou streaming replication. O comando archive_command, por exemplo, pode ser configurado como 'scp %p dextra02:/archives/%f', copiando os logs de transação para servidores de contingência. A configuração também envolve o archive_timeout e restore_command, gerenciando o tempo de arquivamento e a cópia dos logs arquivados para o diretório $PGDATA/pg_xlog. A criação de um arquivo de gatilho (trigger_file) é fundamental para o processo de failover.

O Hot Standby permite a criação de instâncias secundárias (standby) que são atualizadas com as transações da instância principal. Um servidor standby em Hot Standby pode aceitar conexões de leitura (read-only), conforme demonstrado pelo log LOG: database system is ready to accept read only connections. No entanto, operações de escrita (UPDATE, INSERT, DELETE) falham com a mensagem ERROR: cannot execute UPDATE in a read-only transaction. A restauração ocorre paralelamente às consultas, potencialmente causando conflitos. Um exemplo citado é a remoção de um registro 'morto' por um VACUUM replicado, enquanto uma transação read-only o utiliza. As limitações do Hot Standby incluem a possibilidade de conflitos entre consultas no servidor standby e as operações de restauração. Para mitigar conflitos, o parâmetro vacuum_defer_cleanup_age pode ser usado para postergar transações VACUUM no servidor de produção.

A Streaming Replication estabelece um canal de comunicação via TCP/IP entre o servidor mestre e os servidores slaves, transferindo continuamente fragmentos do log de transação. A configuração envolve o arquivo pg_hba.conf no servidor mestre, com a diretiva host replication all 192.168.40.128/32 trust para permitir a conexão do servidor standby. O arquivo recovery.conf no servidor slave precisa definir standby_mode = 'true' e primary_conninfo, especificando a string de conexão com o servidor de produção. O parâmetro wal_sender_delay controla o tempo de espera entre envios de dados. A Streaming Replication, isoladamente, não disponibiliza o servidor standby para consultas; sua principal função é a sincronização contínua. O monitoramento é possível usando as funções pg_last_xlog_receive_location() (último fragmento recebido) e pg_last_xlog_replay_location() (último fragmento aplicado), que retornam valores idênticos na ausência de informações pendentes. O aplicativo pg_controldata exibe informações de controle do WAL para comparação entre servidores mestre e escravos.

A combinação de Streaming Replication e Hot Standby oferece vantagens significativas. No servidor mestre, o arquivo postgresql.conf deve configurar wal_level = hot_standby, max_wal_senders, wal_keep_segments, e max_standby_delay. Este último parâmetro aguarda a finalização de transações que causam conflitos no servidor standby. Essa combinação é ideal quando consultas são mais importantes que a sincronização imediata. Cenários possíveis incluem o uso de backups WAL, Point In Time Recovery (PITR), geração de relatórios em servidores standby, e balanceamento de carga para consultas. Com esta configuração o servidor standby é atualizado a cada alteração, permitindo alta disponibilidade e melhor performance em consultas.

A seção destaca a simplificação na administração de privilégios de usuários no PostgreSQL. Anteriormente, conceder ou revogar privilégios requeria especificar o nome de cada tabela individualmente. Agora, o comando GRANT SELECT ON ALL TABLES IN SCHEMA ... TO ... permite conceder permissões de seleção (SELECT) a um usuário em todas as tabelas de um schema específico de forma eficiente. Isso representa uma melhoria significativa na gestão de permissões, especialmente em schemas com um grande número de tabelas. Exemplos práticos mostram como, antes da melhoria, era necessário listar todas as tabelas individualmente para configurar permissões, resultando em comandos extensos e propensos a erros. A nova abordagem permite definir privilégios padrão para tabelas criadas futuramente, simplificando o processo de configuração inicial e manutençao de acessos. O texto ilustra a diferença com exemplos práticos, mostrando mensagens de erro ao tentar acessar tabelas sem as devidas permissões (ERROR: permission denied for relation ...). Essa nova funcionalidade melhora significativamente a eficiência e praticidade na gestão de segurança de dados em bancos de dados PostgreSQL.

O documento detalha as melhorias de desempenho implementadas no comando VACUUM FULL. A nova versão do comando é significativamente mais rápida, pois agora funciona duplicando a tabela, eliminando a tabela original e recriando os índices. Este método otimizado elimina a necessidade de executar o comando REINDEX após o VACUUM FULL, que era previamente necessário para reconstruir os índices após a compactação da tabela. A eliminação do REINDEX representa uma redução no tempo total de execução do processo de manutenção do banco de dados. A abordagem anterior, de compactar a tabela in-place, era mais demorada e mais sujeita a problemas de desempenho e bloqueios. A melhoria descrita garante um processo mais eficiente e rápido para manter a integridade e o desempenho do banco de dados PostgreSQL, sendo uma atualização relevante para administradores de banco de dados.

A seção descreve a ferramenta pg_upgrade, presente no contrib do PostgreSQL, como uma solução para migração entre versões. Anteriormente, a migração usualmente exigia um processo de dump/restore, que podia ser muito demorado e propenso a falhas. pg_upgrade permite a migração diretamente através dos arquivos de dados (datafiles), sem a necessidade de dump/restore, resultando em um processo de migração muito mais rápido. Embora o texto destaque a migração de 8.4 para 9.0 como exemplo, a ferramenta é apresentada como um recurso geral de migração. A ferramenta está disponível no diretório /usr/local/src/postgresql-9.0beta4/contrib/pg_upgrade_support e deve ser compilada e instalada (make; make install). O texto demonstra claramente que a pg_upgrade reduz drasticamente o tempo de inatividade e o esforço envolvidos no processo de atualização do PostgreSQL, simplificando a manutenção de sistemas de banco de dados.

A seção descreve os blocos anônimos em PL/pgSQL como uma forma eficiente de executar funções sem a necessidade de defini-las previamente com CREATE FUNCTION. Sua sintaxe, DO [ LANGUAGE nome_linguagem ] código, permite executar código procedural diretamente, simplificando tarefas administrativas. A principal vantagem é a eliminação dos passos de CREATE FUNCTION e DROP FUNCTION, tornando o processo mais conciso e ágil. Isso é particularmente útil para comandos que são executados apenas uma vez, como tarefas de administração ou scripts de configuração. Um exemplo de aplicação seria a adição de uma coluna em múltiplas tabelas, onde um bloco anônimo itera sobre as tabelas desejadas e executa o comando ALTER TABLE para cada uma. Essa funcionalidade torna a administração do banco de dados mais eficiente, permitindo a automatização de tarefas repetitivas e complexas com maior clareza e menor quantidade de código.

O documento apresenta triggers condicionais no PostgreSQL, que permitem executar uma função de trigger somente quando uma condição específica é atendida. A cláusula WHEN permite definir essa condição, evitando a execução desnecessária da função em situações irrelevantes. Um exemplo é uma trigger que apenas executa uma ação em um evento UPDATE quando o valor de uma coluna foi realmente alterado, como WHEN (OLD.activebool IS DISTINCT FROM NEW.activebool). Esse tipo de trigger melhora significativamente o desempenho, reduzindo a sobrecarga da execução de funções em eventos que não exigem nenhuma ação, evitando processamentos desnecessários. A utilização da cláusula WHEN proporciona um código mais limpo e mais eficiente, focando a ação da trigger apenas nos eventos que realmente requerem processamento.

A seção discute triggers que são acionadas apenas por atualizações em colunas específicas. Em vez de monitorar todas as alterações em uma linha, essas triggers são disparadas somente quando há uma modificação em uma ou mais colunas pré-definidas. Isso reduz a frequência de execução da função da trigger, melhorando o desempenho e a eficiência. Um exemplo é CREATE TRIGGER tg_log_ativo BEFORE UPDATE OF activebool ON customer ..., que monitora exclusivamente as atualizações na coluna activebool da tabela customer. Ao focar apenas nas colunas relevantes, esse tipo de trigger elimina condições lógicas complexas e comparações de valores dentro da função, tornando o código mais conciso, legível e eficiente. A funcionalidade permite um controle mais preciso e otimizado sobre os eventos que acionam as triggers em um banco de dados PostgreSQL.