Karşılaştırma · Veritabanları
PostgreSQL Logical ve Physical Replication Karşılaştırması
Physical replication WAL akışını cluster düzeyinde uygular; logical replication seçili tablo değişikliklerini publication/subscription modeliyle aktarır. Logical yöntemde tablo seçimi ve…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Physical replication WAL akışını cluster düzeyinde uygular; logical replication seçili tablo değişikliklerini publication/subscription modeliyle aktarır. Logical yöntemde tablo seçimi ve sürüm geçişi olanakları vardır, ancak bütün cluster nesnelerinin otomatik kopyası değildir.
DDL, sequence, large object ve replica identity koşullarını sürüm belgesinden doğrulayın. Logical subscriber’a bağımsız yazma çatışma yaratabilir. Physical standby’nin okuma rolü, promotion ve timeline yönetimi de ayrı işletim adımlarıdır.
Replication slot, subscriber geride kalınca WAL tutulmasını artırabilir. Replikasyon yedek değildir; hatalı DELETE de hedefe taşınabilir. Ayrı PITR/yedek ve gerçek failover kabulü gerekir.
- 1Kaynak transaction/WAL
- 2Publication veya WAL stream
- 3Hedef apply
- 4Cutover ve veri doğrulama
Tasarım parametreleri
- Kapsam
- Cluster tamamı veya seçili tablolar kararını uygulama gereksinimine bağlayın.
- Şema
- Logical DDL değişikliklerini koordineli yayın sürecine dahil edin.
- Lag/WAL
- Alınan, yazılan ve uygulanan konumu ayırın; slot kaynaklı disk kullanımını izleyin.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Ölçüt | Physical | Logical |
|---|---|---|
| Kapsam | Cluster/WAL | Publication tabloları |
| Şema | Fiziksel akış parçası | DDL ayrıca koordine edilir |
| Tipik kullanım | Standby ve failover | Seçili veri ve geçiş |
Hesap ve uygulama örneği
500 GB cluster’ın yalnız 30 GB referans tablosunu başka sisteme aktarmak logical kapsamına uygun olabilir; bütün cluster’ın sıcak yedeği için physical yaklaşımı değerlendirin. Cutover öncesi son commit’in hedefte uygulanmasını kanıtlayın ve sequence değerlerini ayrıca kontrol edin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| WAL disk doluyor | Subscriber gecikiyor, slot tutuyor. | Slot retained WAL ve apply lag değerlerini inceleyin. |
| Yeni kolon hedefte yok | DDL koordinasyonu eksik. | İki şemayı ve yayın değişikliğini karşılaştırın. |
Kabul ve doğrulama kontrolleri
- Kapsamı tablo/cluster olarak yazın.
- Replica identity’yi doğrulayın.
- DDL değişimini pilotlayın.
- WAL retention alarmı kurun.
- Cutover veri kontrolünü yapın.
- Bağımsız PITR/yedeği koruyun.
İlgili kavramlar
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.
İş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.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
RPO ve gerçek veri kaybı penceresi
RPO, olay sonrasında kabul edilebilecek veri kaybı süresidir. Yedek zamanlaması tek başına RPO kanıtı değildir; işin başarısız olması veya kopyanın karşı merkeze geç ulaşması pencereyi büyütebilir. Olay anı ile kullanılabilir son tutarlı kurtarma noktasının zamanını karşılaştırın. Örneğin olay 14.00'te, doğrulanmış kopya 13.20'deyse o testteki veri kaybı penceresi 40 dakikadır. Hedefi uygulama bazında belirleyin: dosya arşivi ile sürekli sipariş alan veritabanının gereksinimleri aynı olmayabilir.
Failover ve failback
Failover, hizmetin başka bir bileşene geçmesidir; failback, tercih edilen konuma geri alınmasıdır. İkisi aynı risk ve işlem sırasına sahip olmayabilir. DNS güncellemesi, yönlendirme, oturumlar, veri geriliği ve uygulama bağımlılıkları kullanıcı kesintisini belirler. Otomatik geçişin hangi koşulda tetiklendiğini, yanlış alarmda ne olacağını ve geri dönüş onayını tanımlayın. Arızayı yalnız sanal makineyi kapatarak test etmek tüm hata türlerini kapsamaz. Ağ, depolama ve yönetim katmanı arızalarının ayrı etkilerini ölçün.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
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.