PostgreSQL Reliability Lab
Projeto autoral de DBRE com PostgreSQL: ambiente reproduzível, recuperação, alta disponibilidade, métricas, logs e alertas validados.
Projeto autoral de DBRE com PostgreSQL: ambiente reproduzível, recuperação, alta disponibilidade, métricas, logs e alertas validados.
Projeto autoral para estudar Protheus em Docker com configuração versionada, automação operacional e práticas iniciais de DevOps.
Uma conta começa o dia com determinado saldo e recebe créditos e débitos ao longo do tempo. O relatório precisa preservar cada movimentação e mostrar o saldo resultante depois de cada uma. Uma função de janela resolve a parte do acumulado sem remover as linhas individuais. Mas escrever apenas sum() over (order by ...) deixa uma decisão importante implícita: quais linhas pertencem ao cálculo da linha atual? Essa parte da janela é chamada de window frame, ou moldura. No PostgreSQL, ROWS, RANGE e GROUPS podem produzir resultados diferentes, principalmente quando existem valores repetidos na ordenação. ...
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. ...