PostgreSQL logical replication lag: veľké transakcie a reorder buffer spilly
Jedna obrovská transakcia vie pripnúť logical replication na hodiny. Runbook na rýchlu identifikáciu, bezpečné tunenie decodingu a kontrakt na bounded transakcie.
32 článkov
Jedna obrovská transakcia vie pripnúť logical replication na hodiny. Runbook na rýchlu identifikáciu, bezpečné tunenie decodingu a kontrakt na bounded transakcie.
Váš EXPLAIN vyzerá perfektne ale produkcia horí. Vinník: PostgreSQL ticho prepol z custom plánu na generic plán po dostatočnom počte vykonaní, a generic plán je katastrofálne zlý.
PostgreSQL LISTEN/NOTIFY funguje perfektne v lokalnom testovani ale notifikacie nahodne prestanu prichodit v produkcii. Vinik: transaction pooling ticho prideluje vase spojenie niekomu inemu.
PostgreSQL môže prejsť do read-only pri XID wraparound. Núdzový playbook: nájsť najstaršie tabuľky, odblokovať vacuum freeze a prevencia do budúcna.
hot_standby_feedback zastaví rušenie query na replike, ale vie nafúknuť primár v dňoch. Diagnostika xmin pinningu, bezpečné mitigácie a guardrails.
Reprodukovateľný postup na diagnostiku a odstránenie checkpoint-induced latency špičiek pomocou pgbench, pg_stat_bgwriter a WAL/IO budgetu.
Aplikácia visí, ale databáza vyzerá zdravo. Najčastejšie je vyčerpaný connection pool. Ukážem detekciu, rozumné dimenzovanie a prevenciu únikov spojení.
Niečo zmazalo riadky z produkcie ale nikto nepriznáva že spustil DELETE. Použi pg_waldump na analýzu WAL súborov a rekonštruuj presne čo sa stalo a kedy.
Pool size 50 lebo tak to bolo vždy? Ukážem ako použiť Little's Law na výpočet optimálnej veľkosti poolu a dokážem to load testom.
Náhodné UUID ako Primary Key spôsobujú index bloat a random I/O. Benchmark s konkrétnymi číslami - veľkosť indexu, cache hit ratio a WAL volume po 100M insertoch.
Vacuum beží úspešne, ale disk rastie a cache hit ratio klesá. Ukážem ako kvantifikovať HOT-update eligibility pomocou pgstattuple a optimalizovať fillfactor.
Rovnaký query, rovnaké parametre, ale prod je pomalý a staging funguje. Ukážem ako reprodukovať generic plan problém s pgBouncer, Java/Go a ako ho fixnúť.
Disk sa plní WAL súbormi. Príčina: logical replication slot consumer odišiel offline a PostgreSQL drží všetok WAL odvtedy pretože by mohol byť potrebný.
Autovacuum je buď ignorovaný alebo cargo-cult tunovaný. Ukážem ako ho premeniť na SLO-driven systém s konkrétnymi číslami, pg_stat metriky a reprodukovateľným testom.
Praktický playbook pre bezpečné databázové migrácie v produkcii. Od expand/contract patternu cez online indexy až po monitoring a rollback.
Pridávate Redis len pre distributed locks? PostgreSQL advisory locks môžu stačiť. Porovnávam oba s failure scenármi a performance benchmarkami.
SELECT * na tabuľke s JSON je 10x pomalší ako očakávané. Ukážem ako TOAST storage funguje a kedy zmeniť stratégie pre veľké stĺpce.
Disk je na 95%, WAL adresár má 400GB. Ukážem ako replication slots bránia WAL cleanup a playbook pre prevenciu a recovery.
Autovacuum nemôže bežať, table bloat rastie, všetko kvôli jednému 'idle in transaction' spojeniu. Tu je detekcia a kill playbook.
Prečo mocky klamú a ako Testcontainers zmení váš prístup k testovaniu. Praktické príklady, CI setup a stratégie izolácie dát.
Full-text search bol rýchly, teraz je pomalý. Príčina: GIN index pending list narástol obrovský počas bulk insertov a každé vyhľadávanie musí teraz skenovať nezoradené pending záznamy.
Reprodukovateľný lab na demonštráciu connection stormu pri K8s rolloutoch. PgBouncer, preStop hooks a jitter - praktické riešenia s benchmarkmi.
Praktická implementácia Outbox patternu v Node.js/TypeScript s PostgreSQL LISTEN/NOTIFY. Race-condition case study a production-ready riešenie.
Praktický rozbor prečo soft delete po rokoch rozbije výkon databázy. Benchmarky, partitioning riešenie a migračný checklist.
Query vracia nesprávne výsledky po upgrade OS. Príčina: ICU library verzia sa zmenila, pravidlá collation sa posunuli a indexy sú teraz zoradené nekonzistentne s novým poradím.
Query skenuje celú tabuľku napriek perfektnému partial indexu. Príčina: WHERE klauzula query sa presne nezhoduje s predikátom indexu, alebo štatistiky zavádzajú plánovač.
Perfektná idempotency logika, ale zákazníci sú stále účtovaní dvakrát. Príčina: kontrola idempotency keys voči read replice ktorá je sekundy za primary počas špičiek.
Dotazy na read replikách zlyhávajú s 'canceling statement due to conflict with recovery'. Riešenie závisí od toho, ktorý z 5 typov konfliktov máte - tu je návod ako diagnostikovať a vyriešiť každý z nich.
Dostávate 'could not serialize access due to concurrent update'? Riešenie nie je len retry logika - je to pochopenie kedy použiť ktorú isolation level a ako znížiť frekvenciu konfliktov.
work_mem vyzerá malé na 256MB, ale parallel hash join so 4 workers naprieč 3 plan nodes používa 3GB. Tu je ako zabrániť PostgreSQL legitímne OOMnúť váš kontajner.
Pridanie indexu pre výkon spôsobilo 10x pomalšie zápisy. Kontra-intuitívna príčina: nový index rozbil HOT updaty, meniaci lacné in-place updates na drahé full-row rewrites s masívnym bloatom.
Rolling deploy zlyháva s cached plan chybami po ALTER TABLE. Príčina: server-side prepared statements cachujú query plány ktoré sa rozbijú pri zmene schémy.