Mimari ve çalışma modeli
PostgreSQL replication slot, fiziksel standby veya mantıksal tüketicinin henüz almadığı WAL'ın kaldırılmasını engeller. Tüketici durursa slot ilerlemez ve `pg_wal` büyüyebilir. Slot veri kopyası değildir; yalnız gerekli WAL konumunu ve mantıksal decoding durumunu korur. İzlenmeyen slot, disk doluluğu üzerinden birincil veritabanının kullanılabilirliğini etkileyebilir.
Fiziksel slotta `restart_lsn`, mantıksal slotta ayrıca `confirmed_flush_lsn` tüketici ilerlemesini gösterir. `pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)` yaklaşık tutulan WAL baytını verir. `wal_status` reserved, extended, unreserved veya lost durumunu gösterebilir. `safe_wal_size`, yapılandırılmış sınır altında slot kaybolmadan önce üretilebilecek yaklaşık WAL miktarıdır; `max_slot_wal_keep_size=-1` sınırsız tutma anlamına gelir.
Kök neden tüketici kesintisi, ağ, yetki, uzun işlem, decoding eklentisi veya downstream backpressure olabilir. Slotu hemen drop etmek disk baskısını azaltabilir fakat tüketicinin kaldığı yerden sürmesini imkânsızlaştırır ve yeniden başlangıç kopyası gerektirebilir. Önce slot sahibi, tüketici RPO'su, mevcut LSN ve yeniden senkronizasyon planı belirlenmelidir. Acil durumda WAL büyüme hızı ile kalan disk zamanı hesaplanır.
Koruma için slot başına gecikme, WAL byte farkı, inactive_since, wal_status ve disk doluluğu alarmı kurun. Sınır seçerken en uzun kabul edilen tüketici kesintisi × pik WAL üretim hızını hesaplayın. `max_slot_wal_keep_size` bir emniyet supabı olabilir fakat aşıldığında slot lost durumuna düşebilir. Bu nedenle sınır, otomatik düzeltme değil kontrollü veri kaybı/yeniden senkronizasyon kararıdır.
- 1Birincil WAL üretimi
- 2Slot restart/confirmed LSN
- 3Standby veya mantıksal tüketici
- 4İlerleme, retention sınırı ve disk alarmı
Tasarım parametreleri
- WAL üretim hızı
- P95 ve pik saatlik WAL baytını en az bir iş döngüsünde ölçün.
- Kesinti toleransı
- Her tüketicinin kabul edilen maksimum durma süresi ve yeniden kurulum yöntemini kaydedin.
- Slot sınırı
- max_slot_wal_keep_size değerini disk, RPO ve re-seed süresiyle birlikte belirleyin.
- Disk payı
- pg_wal, arşiv, geçici dosya ve işletim sistemi için ayrı boş alan eşikleri kullanın.
- Sahiplik
- Her slotu uygulama, ekip, iletişim ve son kullanım tarihiyle envantere bağlayın.
Hesap ve uygulama örneği
Pik WAL üretimi 120 GiB/saat ve mantıksal tüketicinin dört saat durabilmesi gerekiyorsa yalnız bu slot için 480 GiB tutma bütçesi gerekir. Yüzde 25 dalgalanma payıyla 600 GiB planlanabilir; diğer slotlar ve arşiv alanı ayrıca eklenir. Diskte 350 GiB kaldıysa dört saatlik RPO hedefi fiziksel olarak karşılanmıyordur.
Slot farkı 240 GiB ve son iki saatte 80 GiB/saat büyüyorsa mevcut 400 GiB boş alan yaklaşık beş saatlik teorik süre verir. Full-disk eşiklerinden dolayı kullanılabilir süre daha kısadır. Tüketiciyi onarmak 30 dakika, yeniden seed üç saat sürüyorsa karar sahibi bu süreleri ve veri tekrar işleme etkisini karşılaştırmalıdır.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
SELECT slot_name,slot_type,active,active_pid,restart_lsn,confirmed_flush_lsn,wal_status,safe_wal_size,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) AS retained
FROM pg_replication_slots ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn) DESC;
SELECT pg_size_pretty(sum(size)) FROM pg_ls_waldir();
SHOW max_slot_wal_keep_size;
SELECT pid,usename,application_name,state,write_lag,flush_lag,replay_lag FROM pg_stat_replication;Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| pg_wal hızla büyüyor | İnaktif veya geride kalan bir slot WAL kaldırılmasını engelliyor olabilir. | Slot byte farklarını, active durumunu ve WAL büyüme hızını karşılaştırın. |
| Slot wal_status=lost | Sınır sonrası gerekli WAL kaldırılmış olabilir; mevcut tüketici kaldığı yerden devam edemez. | Tüketici hata kaydı ve başlangıç LSN'ini doğrulayın; yeniden seed planını uygulayın. |
| Aktif slot ilerlemiyor | Tüketici bağlı olsa da downstream backpressure, uzun işlem veya flush onayı gecikiyor olabilir. | confirmed_flush_lsn değişimini, tüketici kuyruğunu ve uzun transactionları inceleyin. |
| Slot drop edilemiyor | Aktif bağlantı slotu kullanıyor veya operasyon yanlış slotu hedefliyor olabilir. | active_pid, slot_type, database ve uygulama sahibini doğrulayın. |
Kabul ve doğrulama kontrolleri
- Bütün slotları sahip ve tüketiciyle eşleştirin.
- restart_lsn farkını bayt olarak ölçün ve zaman serisine alın.
- Pik WAL/saat ile kalan güvenli disk süresini hesaplayın.
- wal_status ve safe_wal_size için uyarı eşikleri kurun.
- Slot drop veya sınır değişiminden önce yeniden seed planını onaylayın.
- Düzeltme sonrası tüketici LSN ilerlemesi ve disk düşüşünü doğrulayın.
İlgili kavramlar
İşlem günlüğü ve recovery zinciri
WAL, redo veya transaction log gibi mekanizmalar, veri değişikliklerinin kalıcılaştırılması ve kurtarılması için sıralı kayıt tutar; ürünler arasında ayrıntılar farklıdır. Veri dosyası kopyası ile işlem günlüklerinin zamanı ve zinciri uyumlu olmalıdır. Günlüklerin bulunması tek başına belirli bir zamana dönülebileceğini kanıtlamaz: başlangıç yedeği ve kesintisiz gerekli günlük aralığı da gerekir. Arşivleme gecikmesini, günlük hacmini ve geri oynatma süresini ölçün. Günlükleri kapasite kazanmak için rastgele silmeyin; saklama ve temizleme ürünün desteklediği yöntemle yapılmalıdır.
Replikasyonun kapsamı
Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.