Întârzierile Standby-ului Postgres au Cauzat o Pană de 41 de Minute în Timpul Comutării Bazei de Date

O operațiune de mentenanță planificată pentru aplicarea unui patch pe kernelul bazei de date Postgres primare a dus la o pană semnificativă de 41 de minute, atunci când serverul standby, promovat ca primar, nu a putut accepta imediat scrieri. Problema a apărut din cauza unei configurări greșite a `max_standby_streaming_delay`, care a fost setată la 'așteaptă pentru totdeauna' în loc de limita implicită de 30 de secunde. Această modificare a fost implementată pentru a preveni erorile de anulare a interogărilor pentru rapoartele echipei financiare, dar a determinat standby-ul să întârzie indefinit aplicarea modificărilor Write-Ahead Logging (WAL) primite de la primar.

Raportările de sfârșit de lună ale echipei financiare, care implicau mai multe interogări de lungă durată, au fost rulate în seara dinaintea comutării planificate. Aceste interogări au blocat standby-ul să redea WAL-ul, determinând-o să rămână în urmă cu cinci ore față de primar. Când standby-ul a fost promovat, a trebuit să redea aceste cinci ore de WAL înainte de a putea accepta scrieri, rezultând în timpul de inactivitate extins. Verificarea replicării din runbook a fost insuficientă, deoarece a comparat doar poziția WAL-ului scris pe disc, nu poziția de redare, care a fost metrica critică.

Pentru a preveni repetarea, echipa a implementat mai multe măsuri. Echipa financiară are acum o replică dedicată care permite întârzieri lungi fără a afecta failover-ul. `max_standby_streaming_delay` al standby-ului primar a fost revenit la 30 de secunde, iar alertele de lag monitorizează acum poziția de redare. În plus, se efectuează un test lunar de comutare în staging pentru a valida procesul de failover, asigurându-se că verificările reflectă cu exactitate pregătirea standby-ului de a prelua controlul.