PostgreSQL e SQL

Nos três primeiros labs do PostgreSQL Reliability Lab, o desafio principal era construir um ambiente reproduzível, inicializar uma base coerente e provar que backups podiam ser restaurados. Nos três seguintes, a pergunta mudou. Já não bastava reconstruir um estado conhecido depois de uma falha. Era preciso manter outra cópia do banco, coordenar a troca de liderança e reunir sinais para explicar o comportamento do ambiente. Essa evolução adicionou PostgreSQL em streaming replication, Patroni, etcd, HAProxy, Prometheus, Grafana e Loki. Mas o aprendizado mais importante não foi acumular ferramentas. Foi perceber que replicação, failover e observabilidade resolvem problemas diferentes — e que cada camada precisa de uma evidência própria. ...

Sistemas legados e integrações nem sempre entregam datas em uma coluna do tipo date. É comum encontrar um campo de texto com oito caracteres no formato AAAAMMDD, além de valores vazios e conteúdos que parecem datas, mas não existem no calendário. Converter tudo diretamente com ::date torna a consulta frágil: basta uma linha inválida para interromper o relatório inteiro. Ignorar o problema também não resolve. Se os valores ruins desaparecerem silenciosamente, o total exibido pode parecer correto sem representar toda a carga recebida. ...

No Lab 05 do PostgreSQL Reliability Lab , o cluster detectou a queda do líder, promoveu a réplica, retomou a escrita pelo mesmo endpoint e reintegrou o antigo líder. O mecanismo funcionou, mas operar esse ambiente exige responder a outra classe de perguntas: O banco está disponível? Quem é o líder? A réplica está atrasada? As conexões estão crescendo? Que erro ocorreu e em qual nó? O Lab 06 já está disponível no GitHub . Ele acrescenta Prometheus, PostgreSQL Exporter, Grafana, Loki e Promtail ao cluster de alta disponibilidade e cria uma cadeia reproduzível de métricas, logs, visualização e regras de alerta. ...

Uma integração recebe documentos XML e precisa distribuí-los entre vários workers. Cada documento deve ser processado por apenas um consumidor, mas todos consultam a mesma tabela em busca do próximo item pendente. Se as sessões tentarem bloquear a primeira linha da fila com um FOR UPDATE comum, elas podem acabar aguardando o mesmo item enquanto existem outros documentos disponíveis. O PostgreSQL oferece SKIP LOCKED para outro tipo de coordenação: em vez de esperar por uma linha já bloqueada, a consulta a ignora e procura a próxima candidata. ...

Duas instâncias de uma integração recebem solicitações quase ao mesmo tempo. Ambas consultam o mesmo saldo disponível, verificam que existe limite suficiente e aprovam uma reserva. Cada consulta, isoladamente, está correta. O problema aparece porque as duas decisões foram tomadas sobre o mesmo estado inicial. Quando uma leitura serve de base para uma alteração posterior, um SELECT comum pode não ser suficiente. No PostgreSQL, SELECT ... FOR UPDATE permite bloquear as linhas selecionadas até o fim da transação e serializar decisões concorrentes sobre elas. ...

Quando alguém fala em usar PostgreSQL com Protheus, pode estar descrevendo duas arquiteturas bem diferentes. Na primeira, o PostgreSQL é o banco transacional do ERP. AppServer, DBAccess, driver e banco fazem parte do caminho usado pelas operações do Protheus. Na segunda, o ERP continua em seu banco atual, enquanto uma instância PostgreSQL separada recebe dados para integrações, APIs, relatórios ou aplicações próprias. As duas opções são válidas, mas resolvem problemas distintos. Misturá-las na mesma conversa costuma gerar expectativas erradas sobre homologação, acesso aos dados, desempenho e responsabilidade operacional. ...

No Lab 04 do PostgreSQL Reliability Lab , construí uma réplica física por streaming e validei que ela recebia as alterações do servidor principal. Ainda faltava responder à pergunta mais importante diante de uma falha: Quem decide que a réplica deve assumir, como os clientes encontram o novo servidor de escrita e o que acontece quando o antigo servidor retorna? O Lab 05 já está disponível no GitHub . Ele evolui o cenário anterior para um cluster local com PostgreSQL 16, Patroni, etcd e HAProxy. O roteiro interrompe abruptamente o líder, aguarda a promoção automática, volta a escrever pelo mesmo endereço e reintegra o antigo líder como réplica. ...

Um painel consulta pedidos várias vezes ao dia para mostrar quantidade e valor por data e situação. Quando a consulta precisa percorrer e agrupar muitas linhas a cada acesso, recalcular sempre o mesmo resultado pode deixar de ser uma boa troca. Uma materialized view permite armazenar o resultado dessa consulta no PostgreSQL. A leitura passa a usar dados já consolidados, mas surge uma decisão nova: quando atualizar essa cópia? Neste episódio, vamos criar indicadores de pedidos, alterar os dados de origem e observar que a materialized view permanece desatualizada até receber um REFRESH. ...

Uma integração que recebe documentos fiscais costuma registrar mais do que o documento: origem da importação, tentativas de processamento e eventos recebidos ao longo do caminho. Parte desses dados tem estrutura estável. Outra parte varia conforme a origem ou a etapa do processamento. Neste episódio, vamos consultar essa segunda parte com jsonb, mantendo a identificação do documento em colunas relacionais. O laboratório do episódio 09 já está disponível no GitHub, com os cinco documentos e as consultas deste artigo. Execute os scripts para observar as diferenças entre chave ausente, JSON null e array vazio. ...

O Lab 04 já está disponível no GitHub . Ele mantém uma réplica física do PostgreSQL atualizada por streaming e permite observar o que acontece quando ela fica temporariamente indisponível. Depois de exercitar backup, restore e PITR no Lab 03 , o próximo passo é acompanhar alterações continuamente. A replicação envia registros de WAL (Write-Ahead Log, o registro de alterações do PostgreSQL) do servidor principal, ou primary, à réplica, que os reproduz sobre uma cópia física do cluster. ...