CircleCI kesintisi: zamanlanmış Temporal temizliği Postgres log hacmini doldurdu, pipeline'lar 12 saat durdu

Zamanlanmış bir silme işlemi, yük artışı değil

CircleCI, 9 Ekim 2026'da Temporal kuyruklama katmanının arkasındaki Postgres örneğinin disk alanı tükendiği için pipeline ve workflow'ları yaklaşık 12 saat boyunca işlemedi. CircleCI'nin 12 Ekim tarihli olay raporunun dev.to'daki özetine göre tetikleyici bir trafik artışı değil, şirketin günler önce zamanladığı bir temizlik işiydi: Temporal'ın tamamlanmış workflow geçmişini rutin olarak silen işi, CircleCI'nin 6 Ekim'de çözdüğünü düşündüğü olayın kuyruğa aldığı silmeler.

Arızanın arka planındaki yapı

dev.to'ya göre CircleCI'nin Temporal dağıtımı, write-ahead log'u 3.000 IOPS ile sağlanmış ayrı bir 1TB'lık hacimde yaşadığı çok bölgeli (multi-AZ) bir Postgres örneğine dayanıyor — AWS bu üst sınırları yükseltmiyor. Postgres WAL kayıtlarını yedekleme deposuna arşivlenme hızından daha hızlı yazarsa hacimdeki boş alan düşer; sıfıra ulaştığında veritabanı yazmaları tamamen kabul etmeyi bırakır.

6 Ekim kesintisi, sıradan tablo bakımının arşivlemeyi geçen WAL yazıları üretmesiyle başladı. CircleCI'nin çözümü işlem logunu ayrı hacmine geri taşıdı ve yazma kaynaklarından büyük birını azaltmak için Temporal'ın temizlik ayarlarını düzenledi. Gözden kaçan şey şuydu: Temporal, tamamlanmış workflow geçmişini tamamlanmadan birkaç gün sonra temizliyor; yani olağandışı derecede yoğun 6 Ekim iş yükü 9 Ekim'de silinmek üzere zaten takvime alınmıştı.

Günün gelişimi

9 Ekim'de saat 08:00'de silme işi bu birikimi işlemeye başladı. Log hacmindeki kullanılabilir alan 10:10'a kadar 0,8TB'den 0,1TB'ye indi; izleme sistemi 10:28'de uyarı verdi ve üç dakika sonra olay ilan edildi. 11:15'e kadar hacim doldu, Postgres salt-okunur moda geçti ve Temporal işlemesi durdu.

6 Ekim geçici çözümünün yeniden uygulanması — logun veri hacmine taşınması — veritabanını 12:59'a kadar geri getirdi ve 11:15'ten beri biriken kuyruk 14:40'a kadar eridi.

Toparlanmadan sonra ikinci bir arıza

Saat 15:15'te daha yavaş bir sorun ortaya çıktı. Normalde silinmeyi bekleyen on binlerce satır taşıyan yönlendirme temizliği tabloları on milyonlarca satıra şişti ve her Temporal işlemi bunları tarayarak geçmek zorunda kaldı. Manuel vacuum işleri canlı sorgularla CPU için rekabet ederek durumu kötüleştirdi ve 17:45'te iptal edildiler. 20:48'ye kadar mühendisler veritabanının WAL darboğazından CPU'nun çöküşüne kaydığını, zaten başarısız olmuş işleri yeniden gönderen upstream sistemlerin yarattığı bir yeniden deneme fırtınasının durumu ağırlaştırdığını fark etti. Tüm yeni ve yeniden denenen işleri duraklatmak, Postgres'in sonunda yetişmesini sağladı.

CircleCI'nin yanıtı

dev.to'nun özetine göre CircleCI o zamandan beri Temporal'ı bağımsız veritabanlarına sahip birden çok sharded örneğe böldü, sabit boyutlu log hacmini kaldırdı, WAL arşiv gecikmesi ve yazma hızı için uyarılar ekledi — postmortem'üne göre bu, sorunu saatler önce yakalayabilirdi — ve sistemlerinin sağlıksız bir Temporal örneğine karşı yeniden deneme şeklini değiştirdi.

Neden önemli

Büyük ölçekli Postgres veya workflow motoru dağıtımları yürüten ekipler için öğretici olan kısmı arızanın biçimi: birinci olay için alınan önlem o anda teşhis edilen yazma desenine göre kapsamlandırılmıştı, ikinci ve gecikmeli bir tetikleyici ise takvimde oturuyordu. 6 Ekim semptomlarında, üç gün sonra ateşlenecek olan silme işine işaret eden hiçbir şey yoktu. dev.to yazarı genel dersi şöyle ifade ediyor: bir postmortem düzeltmesi, önümüzdeki günlerde aynı kaynağa dokunacak şekilde zamanlanmış diğer her işe karşı test edilmeden doğrulanmış sayılmaz.

İki pratik kontrol buradan çıkıyor. Birincisi, yalnızca boş disk alanı yerine doğrudan WAL arşiv gecikmesi ve yazma hızına uyarı verin; bu sinyaller sorunu çok daha erken ortaya çıkarır. İkincisi, retention veya temizlik işlerinin sistem yükünden bağımsız olarak sabit bir takvimde çalışıp çalışmadığını doğrulayın; böylece en kötü saatte devreye giremezler. Yeniden deneme davranışı da bir denetimi hak ediyor — upstream yeniden denemeleri gerçek bir kesintinin üstüne yük ekledi; bu nedenle zorlanan bir downstream bağımlılığını algılayan backoff mantığı toparlanmayı ciddi ölçüde kısaltabilir.