Postgres failover postmortem'ü: standby beş saatlik WAL aldı ama hiçbirini uygulamadı

Ne oldu

Bir ekip, Ağustos ayında primary'nin kernel'ine yama uygulanabilmesi için ana Postgres veritabanlarının iki dakika sürmesi planlanan bir switchover gerçekleştirdi. Sergey Shinder'ın dev.to'daki postmortem'üne göre standby sabah yedide promote edildi ve ilk yazmayı kabul etmesi 41 dakika sürdü. O 41 dakika boyunca hiçbir şey yazamayan tüm servisler durdu.

Çarpıcı detay şu: replikasyon aslında hiç kopmadı. Standby gece boyunca primary'den gelen her değişikliği aldı. Tek yapmadığı şey, bunlardan hiçbirini uygulamak oldu.

Replay finans raporlarının arkasında nasıl takıldı

Standby hem streaming replica hem de finans ekibinin raporlama veritabanı olarak çifte görev yapıyordu ve hot standby üzerinden raporlamanın bilinen bir başarısızlık modu var. Primary, standby'daki uzun bir sorgunun hâlâ görebildiği satırları vacuum ile temizlediğinde, bu temizliği uygulamak söz konusu satırları çalışmakta olan sorgunun altından çekmiş olur. Postgres bunu max_standby_streaming_delay ile yönetir: varsayılan olarak standby replay'i 30 saniye duraklatır, ardından ilgili sorguyu "canceling statement due to conflict with recovery" hatasıyla iptal eder.

Finans, ay sonu çalışmalarında yaşanan bu iptallere itiraz etti ve bahar aylarında biri bu değeri -1 olarak ayarladı; dokümantasyon bunu açıkça süresiz bekleme olarak tanımlıyor. Değer de tam olarak bunu yaptı. Switchover'dan bir önceki akşam finans, ay sonu uzun sorgu paketini çalıştırdı. Replay, ilk sorgunun arkasında durdu ve gerisinde kalmaya devam etti. Standby primary'den WAL almayı ve diske yazmayı sürdürdü, ancak sabaha geldiğinde uygulanan değişikliklerde beş saat gerideydi.

Promotion, tek bir yazmayı kabul etmeden önce standby'nın çoktan aldığı her şeyin replay'ini bitirmek zorundadır ve beş saatlik birikmiş WAL'ın uygulanması 41 dakika sürdü.

Switchover öncesi kontrol neden sorunsuz görünüyordu

Runbook'ta her switchover öncesinde bir replikasyon kontrolü确实 vardı. Kontrol, primary'nin anlık konumunu standby'nın diske flush ettiği konumla karşılaştırıyordu; bu konum birkaç kilobyte gerideydi ve kusursuz görünüyordu. Asıl önemli olan sayı, yani replay konumu, pg_stat_replication içindeki daha ilerideki bir sütunda yer alıyordu ve onu izleyen hiçbir şey yoktu.

Ekip neleri değiştirdi

Shinder'ın anlattığı düzeltmeler hem iş yükü karışımını hem de izleme açığını ele alıyor:

• Finans artık kendi replikasına sahip; uzun gecikmelere izin verecek şekilde yapılandırıldı ve failover'da hiçbir rolü yok.
• Promote edilebilir standby tekrar 30 saniyelik gecikmeye döndü.
• Lag uyarısı özellikle replay'i ölçüyor; hem replay_lag sütununu hem de replay_lsn'e olan byte farkını kullanıyor ve bir dakika sonra tetikleniyor.
• Switchover scripti, replay lag birkaç saniye içinde değilse başlamayı reddediyor.
• Staging ortamında her ay bir switchover provası yapılıyor; promotion'dan ilk başarılı yazmaya kadar süre ölçülüyor.

Neden önemli

Shinder'ın çıkardığı ders bu tek olayın ötesine genelleniyor: değişikliklerinizi güvenle diske yazmış bir standby, devralmaya hazır bir standby demek değildir. Onun kontrolleri teslim alımı ölçüyordu; failover ise uygulamaya bağımlıydı. Flush lag ile replay lag saatlerce ayrışabilir ve dashboard'lar yeşil kalmaya devam edebilir; sorgu konforu için ayarlanmış tek bir parametre sessizce bir failover saati bombasına dönüşebilir. Raporlama iş yükleriyle birlikte hot standby çalıştıran herkes, flush lag yerine replay lag üzerine uyarı kurmalı ve failover'ları uçtan uca prova etmelidir; verinin sadece ulaştığını kanıtlayan metriklere güvenmek yerine.