PostgreSQL Yükseltmesi Kesinti Olmadan: Blue/Green, Replikasyon ve Üretim ERP Veritabanları İçin Geri Dönüş Planı

Bir PostgreSQL yükseltmesi kesinti olmadan ilk bakışta bulut dünyasından bir vaat gibi gelebilir. Üretimdeki bir ERP veritabanı gerçekliğinde ise bu daha çok bir disiplin: Veri tutarlılığını, arayüz davranışını, toplu iş çalıştırmalarını, raporlamayı, yetkilendirmeleri ve işletme süreçlerini öyle bir şekilde uyumlu hale getirmeniz gerekir ki gerçek sürüm değişikliği sadece kontrollü bir geçiş anı olsun. Burada „kesinti olmadan“ nadiren mutlak olarak anlaşılmalıdır. Pratikte anlamı şudur: kullanıcılar için hissedilir bir kesinti yok, plansız geri dönüşler yok, saatler süren kilitlenmeler yok — ve her şeyden önemlisi gerçekten işleyen bir geri dönüş yolu bulunması.

Bu yazı, ERP ortamlarındaki tipik PostgreSQL yükseltme yollarını sınıflandırıyor — Blue/Green, replikasyon (fiziksel ve mantıksal) ve kağıt üzerinde olmayan bir geri dönüş planı ile. Odak kasıtlı olarak işletme ve karar sorularında: Hangi mimari gerekiyor? Riskler nerede yoğunlaşıyor? Hangi ön çalışmalar zaman alır? Ve bir yükseltmenin sürücülerin, iş zincirlerinin veya belirsiz veri sahipliğinin gibi yan konularda başarısız olmasını nasıl önlersiniz?

Warum ERP-Datenbanken bei Upgrades besonders heikel sind

ERP sistemleri OLTP-ağırlıklı (Online Transaction Processing), yani çok sayıda kısa işlem için optimize edilmiştir: belgelerin yazılması, stok hareketlerinin kaydedilmesi, fiyatların hesaplanması, ödemelerin muhasebeleştirilmesi. Bu işlemler net beklentilere dayanır: gecikme (latency) stabil olmalı, kilitler (Locks) tırmanmamalı ve sistem yük zirvelerinde öngörülebilir kalmalıdır.

Bir PostgreSQL yükseltmesi tam da bu stabilitenin içine müdahale eder — hatta uygulama değişmese bile. Nedenleri arasında şunlar vardır:

• Sorgu optimizatöründeki değişiklikler (planlayıcı): Sorgular aniden farklı yürütme planları seçebilir. Bu „yanlış“ değildir, fakat yük altında yeni sıcak noktalar veya darboğazlar ortaya çıkabilir.
• Parametre ve varsayılan değer değişiklikleri: Konfigürasyon değerleri veya bunların varsayılan davranışları major sürümler arasında değişir. Örneğin Autovacuum, WAL (Write-Ahead Log, işlem günlüğü) veya work_mem gibi bellek ayarları etkilenir.
• Sürücü ve protokol konuları: ODBC/JDBC/Npgsql sürümleri, SSL/TLS parametreleri, kimlik doğrulama (ör. SCRAM vs. MD5) ve sertifika zincirleri çoğunlukla gizli engellerdir.
• Arayüz ekosistemi: ERP nadiren „sadece tek bir uygulama“ demektir. Raporlama, EDI, web servisleri, ETL/BI, belge yönetimi ve toplu entegrasyonlar veritabanına doğrudan veya dolaylı erişir.

Sonuç: Bir yükseltme sadece bir veritabanı değişikliği değildir. Uygulama, işletme ve komşu sistemler üzerinde koordine edilmiş bir sürümdür. Tam da bu yüzden Blue/Green ve replikasyon değerli araçlardır: teknik geçişi uzun bir bakım penceresinin riskinden ayırırlar.

Ziele sauber definieren: „ohne Downtime“ bedeutet nicht „ohne Umschalten“

Mimariyi seçmeden önce, işletme metrikleri doğrultusunda net bir hedef tanımı yapmak önemlidir:

• RTO (Recovery Time Objective): Bir arızadan sonra ERP veritabanının ne kadar hızlı yeniden stabil ve erişilebilir olması gerekir?
• RPO (Recovery Point Objective): En kötü durumda ne kadar veri (zaman aralığı) kaybedilebilir? Gerçek sıfır-kesinti migrasyonlarında hedef genellikle RPO≈0’dır.
• Wartungsfenster: Cutover için „küçük“ bir pencere (ör. birkaç dakika) var mı, yoksa hiç yok mu? ERP’de bir geçiş genellikle planlanabiliyorsa mümkündür (vardiya değişimleri, ay sonu gibi zamanları avoid etmek gerekir).

Bu hedefler, Replikation plus Cutover ile çalışıp çalışamayacağınızı veya ek olarak yazma-ayırma mekanizmalarına ihtiyaç duyup duymadığınızı (ör. arabirimlerde Queueing) belirler. Bu konuda belirsiz kalanlar, Go-live sırasında doğaçlama yapmanın bedelini öder.

PostgreSQL için Blue/Green: Prensip, Fayda, Tipik Tuzaklar

Blue/Green şunu ifade eder: İki tam ortam paralel olarak var olur. „Blue“ üretimdir, „Green“ yeni sürümdür. Karar verici avantaj yalnızca geçiş yapılabilmesi değil, aynı zamanda gerçekçi koşullar altında test edilebilmesidir: Green, kullanıcıların geçiş yapmasından önce prodüksiyona yakın veriler, gerçek arabirimler ve gerçek izleme ile doğrulanabilir.

PostgreSQL’in ERP bağlamında Blue/Green tipik olarak şunları kapsar:

• yeni Hosts/VMs üzerinde veya ayrı örneklerde ayrı bir PostgreSQL-Cluster (Green)
• aynı ağ ve güvenlik parametreleri (Firewall, TLS, DNS-Auflösung, Service-Accounts)
• tanımlı bir veri devralma süreci (initiale Kopie + Delta)
• bir Cutover mekanizması (DNS-/VIP-Umschaltung, Connection-String-Switch, Proxy)

Blue/Green’in size operasyonel olarak gerçekten sağladıkları

Pratikte farkı yaratan üç nokta vardır:

• Geri dönüş hızlıdır: Hata durumunda yükseltmeyi „tersine“ onarmaya çalışmak yerine geri dönebilirsiniz.
• Ön doğrulama ile risk azaltma: Green üzerinde performans ve işlev kontrolleri yapılabilir; buna tipik ERP yükleri (Batchläufe, Druck, Buchungswellen) dahildir.
• Veritabanı ve uygulama riskinin net ayrımı: Green çalıştığında birçok bilinmeyen zaten çözülmüştür (Treiber, Auth, Extensions, Parameter).

En sık görülen Blue/Green hata senaryoları

Blue/Green nadiren fikirde başarısız olur; başarısızlık genellikle detaylarda ortaya çıkar:

• Eksik bağımlılıklar: Raporlama araçları veya entegrasyonlar eski hosta „sert“ şekilde erişir (IP, Alias, Zertifikat-Pinning). Cutover sırasında takılma yaşanır.
• Arabirimlerin belirsiz sahipliği: Kimse, tüm Consumer’ların geçiş yapmasından veya en azından test edilmesinden sorumlu hissetmez.
• Eksik veri doğrulaması: „Daten sind repliziert“ demek, iş açısından her şeyin doğru olduğu anlamına gelmez (ör. Sequenzen/Identitäten, Zeitstempel, Nebenbuchlogik).

Replikation als Upgrade-Werkzeug: physisch vs. logisch

Downtime olmadan bir PostgreSQL yükseltmesi için replikasyon genellikle verileri paralel tutmanın temel mekanizmasıdır. PostgreSQL bunun için farklı yaklaşımlar sunar ve bunlar farklı trade-off’lara sahiptir. Önemli: „Replikation“ otomatik olarak „Hochverfügbarkeit“ anlamına gelmez. Yükseltmelerde replikasyonu bir Migrationsbrücke olarak kullanın.

Physische Replikation (Streaming Replication): schnell, nah an der Maschine

Fiziksel replikasyon WAL düzeyinde çalışır: Standby işlem günlüklerini alır ve uygular. Bu, yüksek performanslı ve stabil bir yöntemdir, ancak major yükseltmeler için merkezi bir sınırlama vardır: Genelde Primary ve Standby aynı major sürüme uymalıdır. Örneğin PostgreSQL 13’ten 16’ya bir sürüm atlamada fiziksel replikasyon, doğrudan bir major-yükseltme yolu olmaktan ziyade sürüm içi kullanım (HA, bakım) için uygundur.

Yine de pratik fayda, fiziksel replikasyonu Blue sistemi içinde bir güvenlik ağı olarak kullandığınızda ortaya çıkar: Cutover’dan önce mevcut üretimin yedekli olduğunu doğrulayabilir ve paralel olarak Green’i kurabilirsiniz.

Logische Replikation: Delta-Übernahme über Publikationen/Subscriptions

Mantıksal replikasyon tablolar seviyesinde değişiklikleri (INSERT/UPDATE/DELETE) aktarır ve bu nedenle Publisher ile Subscriber farklı major sürümlerde olabildiğinden major-yükseltmeler için uygundur (ilgili uyumluluk dikkate alınarak). ERP veritabanlarında bu genellikle minimum kesinti penceresiyle en pratik yoldur.

Planlamanız gereken tipik özellikler:

• Initialer Snapshot + laufende Änderungen: Veri seti başlangıçta kopyalanır ve sonrasında değişiklikler eşlenir.
• DDL ist nicht automatisch dabei: Şema değişiklikleri (DDL, yani tablolar/sütunlar/index’ler) veri değişiklikleri gibi replike edilmez. Yükseltmelerde bu genelde kabul edilebilir çünkü şema çoğunlukla aynıdır – ancak Extensions, roller ve izinleri bilinçli olarak taşımanız gerekir.
• Sequence/Identity-Themen: Sekanslar (ör. belge numaraları için) ERP’de kritiktir. Kuruluma göre sekans durumlarının tutarlı şekilde devralındığından ve Cutover sonrasında doğru şekilde devam ettiğinden emin olmalısınız.
• Konfliktfreiheit: Replikasyon aşamasında yalnızca tek tarafta yazma yapılmalıdır. Aksi halde ERP işletiminde çözülmesi zor çatışmalar oluşur.

Der Upgrade-Pfad in der Praxis: ein belastbares Vorgehensmodell

Kullanılan araca bakılmaksızın, ERP ortamlarında kesinti süresini en aza indiren bir yükseltme genellikle belirgin aşamalarda ilerler. Pratikte uygulanabilir bir yapı şöyledir:

1) Voranalyse: Was muss wirklich mit umziehen?

Burada amaç „PostgreSQL X’i kur“ değil, bağımlılıklar üzerinedir:

• Extensions (z. B. für Volltext, Jobs, spezielle Datentypen): Hangileri üretimde aktif, hangileri geçmişten kalan mevcut?
• Auth und Rollen: yerel roller, LDAP/AD bağlantısı, SCRAM, sertifika doğrulaması. Roller ve izinlerin dışa aktarımı ayrı bir iş adımıdır.
• Jobs und Batchläufe: Zamanlama dışarıda mı çalışıyor (ör. bir jobserver üzerinden) yoksa veritabanında mı (ör. eklentiler aracılığıyla)? Hangi işler cutover açısından kritik (gece işleme, faturalama, MRP)?
• Consumer-Landschaft: Kim okur/yazar? ERP-Backend, Webportale, entegrasyon servisleri, BI/ETL, iş ortağı bağlantıları, DMS, Monitoring.

Basit ama etkili bir artefakt bir Application-Map’tir: ortada veritabanı, tüm sistemlere oklar dahil olmak üzere owner ve geçiş yöntemi (DNS, yapılandırma, Secret, Proxy). Bu, cutover’un aniden timeout olan „unutulmuş“ okuyucular yüzünden başarısız olmasını engeller.

2) Green’i oluşturma: sadece veritabanı değil, işletme yetkinliği

Green ancak „operasyonel olarak gerçek“ olduğunda anlamlıdır. Buna şunlar dahildir:

• Monitoring (Metriken, Logs, Alarme): Blue ile aynı görünürlük; aksi takdirde Go-live kör olur.
• Backup/RESTore: Green üzerindeki yedeklemeler çalışmalı, RESTore testi dahil (en azından rastgele örnekleme ile). Ancak bu şekilde hata halinde iki kat kaybetmeyeceğiniz netleşir.
• Security-Parität: TLS yapılandırması, Cipher, sertifika zinciri, HBA kuralları (Host-Based Authentication), güvenlik duvarı. „Sonradan sertleştirmek“ geçişte başınıza iş açar.
• Performance-Basis: Depolama gecikmesi, IOPS, CPU, RAM. Bir yükseltme, elverişsiz depolama sınıfları veya modası geçmiş VM profillerini düzeltmek için iyi bir zamandır.

3) Datenübernahme: initiale Kopie und Delta-Phase

Büyük ERP veritabanlarında ilk kopya genellikle en uzun adımdır. Bunu düzgün şekilde ayrıştırırsanız bakım penceresinde olması gerekmez. Belirleyici olan, delta aşamasının (Replikation) kararlı çalışması ve izlenmesidir: gecikme, hatalar, bekleyen değişiklikler.

Operasyonel olarak önemli: Cutover’u ne zaman başlatacağınızı belirleyen eşik değerleri tanımlayın. Eğer Green sürekli geride kalıyorsa, geçiş mümkün olsa da problemi canlı sisteme taşırsınız.

4) Validierung: fachlich und technisch, ohne Perfektionismus

Doğrulama aylardır süren bir test projesi değildir, ama „SELECT COUNT(*)“ten daha fazlasıdır. ERP ortamlarında aşağıdaki kontroller iyi çalışır:

• Önemli tablolar üzerinde örneklemeler: açık kalemler, stok seviyeleri, belge başlıkları/kalemleri, fiyatlandırma tabloları, Borçlu/Alacaklı.
• Toplam karşılaştırmaları: tanımlı dönemler için toplamlar (ciro, miktarlar), kaba sapmaları hızlı görmek için.
• Teknik göstergeler: indeks ve istatistik durumu, autovacuum etkinliği, replikasyon gecikmesi, bağlantı limitleri, sorgu gecikmeleri.

Önemli olan karar, neyin kabul için gerçekten gerekli olduğudur. Bir yükseltme fonksiyonel bir sürüm yayını değildir. Kanıtlamak istediğiniz: aynı veriler, aynı davranış, kararlı performans. Bunun için güvenilir, yeniden üretilebilir kontrol noktaları yeterlidir.

5) Cutover: der Umschaltmoment muss wie ein Runbook funktionieren

Cutover kendisi nadiren karmaşıktır, ancak zaman açısından kritiktir. İyi bir runbook yalnızca adımları değil, aynı zamanda kontrol noktalarını ve abort kriterlerini de tanımlar. Tipik bileşenler:

• Yazmayı durdurmayı kontrol edin: ya uygulamanın bakım modu ile ya da teknik bir kilitle (örn. yazma rollerine ait bağlantıları kesmek). Amaç: son aşamada Blue üzerinde yeni yazma işlemi olmaması.
• Replikasyonu „sıfıra“ getirmek: Green tüm değişiklikleri alana kadar beklemek (RPO≈0).
• Uygulamanın geçişi: Connection-Strings, DNS, VIP, Proxy kuralı. Belirleyici olan: tüm bileşenler için tutarlı olması, sadece ERP-Backend için değil.
• Smoke testleri: Giriş, temel verilerin açılması, belge kaydı, tipik rapor, arayüz ping’i. Kısa ama anlamlı.

Geri dönüş planı (Rollback) yanılsamalar olmadan: Gerçekten neleri geri alabilirsiniz

Geri dönüş planı, en çok „ihtiyaç duymadığınız“ kısımdır. Tam da bu yüzden somut olmalıdır. Blue/Green kurulumlarında geri dönüş özünde Blue’a geri geçiştir. Ancak: Cutover’dan sonra Green üzerinde üretken yazma işlemleri gerçekleşmeye başlarsa, Blue aynı aralıkta tüm yazmaları almadıysa „geri“ dönme teknik olarak sorun haline gelir.

Rollback varyantları ve sonuçları

• Üretken yazmalardan önce anında Rollback: İdeal durum. Kullanıcı erişimi açılmadan önce temelde bir sorun olduğunu fark ederseniz, veri çatışması olmadan geri dönebilirsiniz.
• Birkaç yazmadan sonra Rollback: mümkün, ama sadece net bir strateji ile: ya işsel olarak manuel sonradan kaydetme (nachbuchen) ya da teknik olarak geçici karşı replika/delta devralma; ERP süreçlerinde bu nadiren sorunsuz gerçekleşir.
• Rollback yok, bunun yerine „Fix forward“: Eğer Green zaten üretken yazma yapıyor ve oradaki veri durumu yeni „Single Source of Truth“ ise, genellikle geri dönmek hedefe göre daha risklidir; bunun yerine öne doğru planlı bir stabilizasyon tercih edilebilir. Bu seçenek önceden kabul edilmiş olmalıdır.

Bu nedenle sağlam bir geri dönüş planı açıkça belirtmelidir:

• Rollback’ın ne zamana kadar „güvenli“ olduğu (zaman penceresi veya Runbook’taki aşama)
• hangi iptal kriterlerinin geçerli olduğu (ör. Smoke-test başarısızlığı, arayüz hatası, tutarsız toplamlar)
• iletişim ve onay süreçlerinin nasıl işleyeceği (kim karar veriyor, kim bilgilendiriliyor)

Rollback’tan daha önemli: arayüzler için acil işletim

ERP ortamlarında arayüzler, cutover sonrası panik durumlarının daha yaygın nedenidir. Partner bağlantıları veya dahili entegrasyon servisleri aniden veri sağlamazsa, bir acil işletim düzenine ihtiyacınız olur: ara tamponlar (Queues), yeniden başlatma kuralları, net retry stratejileri. „Retry“ burada idempotent olmalıdır (tekrarlandığında çift kayıt oluşturmayacak şekilde). Bu bir veritabanı işlevi değil, uygulama ve entegrasyon tasarımı meselesidir – ancak bir yükseltmeyi kesinti olmadan gerçekleştirip gerçekleştiremeyeceğinizi belirler.

Yükseltme sonrası performans ve stabilite: neden ilk 48 saat belirleyicidir

Birçok ekip cutover tamamlandığında yükseltmeyi „tamamlanmış“ sayar. Pratikte ise, yük profilleri, önbellek davranışı ve Autovacuum ancak o aşamadan sonra oturmaya başlar. Etkili olduğu kanıtlanmış tipik önlemler:

• İlk 48 saatte yoğun izleme: sorgu gecikmeleri, kilitler, I/O bekleme süreleri, WAL hacmi, Autovacuum çalışmaları.
• Plan-Regresyonlarını tespit edin: Önceden “tamam” olan tekil sorgular yükseltme sonrasında baskın hale gelebilir. Burada en çok kaynak tüketen sorgu listeleri ve kimlerin tune yapabileceğine dair net bir eskalasyon (DBA vs. uygulama ekibi) yardımcı olur.
• Raporlama/ETL’i ayrı izleyin: Okuma ağırlıklı araçlar genellikle ilk sorun çıkaranlardır (uzun sorgular, yeni planlar). Okuma replika sunucuları yardımcı olabilir, ancak bunların genel mimariye uyması gerekir.

IT yöneticileri için önemli: Bu stabilizasyonu değişiklikin bir parçası olarak planlayın. Downtime olmadan yapılan bir yükseltme “emeksiz” değildir; doğru zamanda ve kontrollü risk formatında yapılması gereken iştir.

ERP çevresinde tipik mimari kararlar: DNS, Connection Strings, Proxies

Geçiş ne kadar net bir anahtar noktasıyla tanımlanırsa o kadar temiz olur. Sık görülen varyantlar:

• DNS-Alias (z. B. db-erp.prod): basit, fakat TTL (Time To Live) ve istemci önbelleklemesi geçiş sürelerini uzatabilir. Bazı sürücüler için DNS önbellekleme beklenmedik şekilde kalıcı olabilir.
• Sanal IP / Load Balancer: Geçiş teknik olarak hızlıdır, ancak net bir health-check konseptine ihtiyacınız var; aksi halde kararsız durumlara yönlendirme yaparsınız.
• Connection-String konfigürasyon/secret üzerinden: Merkezi konfigürasyon dağıtımınız varsa iyi kontrol edilebilir. Risk: Tüm bileşenler yeni konfigürasyonu aynı anda çekmeyebilir.
• DB-Proxy: Geçişleri merkezi hale getirmede yardımcı olabilir, fakat ek karmaşıklık ve zincire yeni bir kritik hizmet getirir.

Olgulu (heritage) kurumsal yazılımlar için genellikle bir karışım gerçekçidir: Merkezi servisler konfigürasyonla, “eski bileşenler” DNS ile geçiş yapar. Önemli olan bunu runbook’ta belgeleyip test etmektir — eski bir uygulama sunucusundaki “unutulmuş” job’lar dahil.

Güvenlik ve Uyumluluk: Yükseltme bir fırsattır, ama yan sahne olmamalı

PostgreSQL yükseltmeleri, güvenlik açıklarını kapatmak için iyi bir vesiledir: eskimiş kimlik doğrulama yöntemleri, aşırı geniş roller, belirsiz ağ paylaşımları gibi. Aynı zamanda Security’nin kontrolsüz bir kapsam büyümesi haline gelmemesi gerekir.

Pragmatik yaklaşım:

• Cutover’da güvenlik paritesi: Green en azından Blue kadar güvenli olmalı; küçük, net iyileştirmelerle daha iyi olabilir (ör. TLS varsayılanları, MD5 yerine SCRAM, daha sıkı HBA kuralları).
• Daha büyük değişiklikleri sonradan uygulayın: Rol refaktoringi, katı ağ segmentasyonu veya kapsamlı secret-rotasyonu değerli değişikliklerdir, ancak stabilizasyon sonrası ayrı bir change paketi olarak yapılması daha doğrudur.

Çabayı gerçekçi değerlendirin: Projelerin sahada zaman kaybettiği noktalar

Planlama ve iletişim için dürüst bir iş yükü yapısı yardımcı olur. Deneyimle sabit olan, zaman yiyen işler genellikle “PostgreSQL kurmak” değil, şunlardır:

• Tüketici envanteri: Tüm okuma/yazma tüketicileri bulun, sahipleri netleştirin, geçiş yolu tanımlayın.
• Test verisi ve test ortamı: Üretime yakın veriler (veri koruma/gizlilik dikkate alınarak) ve gerçekçi yük kritik önemdedir; aksi halde problemi doğru şekilde test etmezsiniz.
• Runbook’lar ve onaylar: Bakım penceresinde kim ne yapabilir? Rollback kim karar verir? Kim iletişim kurar? Netlik yoksa kritik anda gecikmeler oluşur.
• Sürücü/TLS konuları: Küçük uyumsuzluklar büyük semptomlar üretebilir (ara sıra bağlantı kopmaları, kimlik doğrulama hataları, zaman aşımı).

Bu maddeleri baştan ayrı iş paketleri olarak ele alırsanız, “yükseltme” gergin bir hafta sonu yerine yönetilebilir bir projeye dönüşür.

Sonuç: Kesinti olmadan PostgreSQL yükseltmesi her şeyden önce bir işletim tasarımıdır

Kesinti olmadan bir PostgreSQL yükseltmesi tek bir hileyle değil, geçişi ve geri dönüşü yönetilebilir kılan bir mimariyle başarılır. Blue/Green gerekli ayrımı sağlar, replikasyon veri köprüsünü sunar ve gerçekçi bir geri dönüş planı, ekipte bir hata durumunda veri kaybı ile saatler süren kesinti arasında seçim yapma zorunluluğunu engeller.

Tüketici yapısını temiz şekilde envanterlerseniz, Green’i çalışır durumda bir ortam olarak kurar (izleme, yedeklemeler, güvenlik), veri devrini izler ve Cutover’ı iptal kriterleriyle bir Runbook olarak prova ederseniz, versiyon atlaması kontrol edilen bir değişime dönüşür — çok sayıda arayüze sahip üretim ERP veritabanlarında bile.

ERP veritabanınızın yükseltmesini yapılandırılmış şekilde hazırlamak ve bu süreçte mimariyi, arayüzleri ve geri dönüş planını birlikte ele almak isterseniz, bizimle konuşun:

Bu konu için Blue/Green Deployment ve Cutover planı da önemlidir. Bu yazı bu noktaları anlaşılır şekilde sınıflandırır ve günlük kullanımda nelere dikkat edilmesi gerektiğini gösterir.

Proje veya modernizasyon girişimini Net-Base ile görüşün.