PostgreSQL veritabanı sunucusu her yıl yeni özellikleri içine kattığı bir majör sürüm yayınlıyor. Önümüzdeki günlerde de PostgreSQL 18 geliyor.
50 senelik bir ilişkisel veritabanı modelini uygulayan bir servis üzerine her sene ne eklenebilir ki diye düşünebilirsiniz. PostgreSQL bir taraftan sadece bir ilişkisel veritabanı servisi olmaktan çıkıp bir platform olmaya ilerlerken, işin servis kısmında ise yüksek erişilebilirliğe (HA) ve ölçeklemeye dair geliştirmeler ve performans iyileştirmeleri geliyor.
PostgreSQL, benzer veritabanı servislerinde bulunmayan çeşitli özgün özelliklere sahip olmasına karşın, onlarda yıllar önce üretilmiş bazı çözümleri içermeyebiliyor. Yüksek erişilebilirliğin temel yapı taşı olan replikasyon (verinin bir sunucudan diğerine taşınması) da bunlardan biri. Yüksek erişilebilirlik ve ölçekleme kurumların öyle ihtiyaç duyduğu bir özellik ki, bunun için geliştirilmiş bir çok dış (üçüncü parti) araç var. PostgreSQL’i forklayıp ayrı ürün yapan, bunu kapatıp satan, servis olarak satan, tamamen bağımsız araç geliştiren vs vs bir çok yancı var. Bazen sırf bu “yancılar” yüzünden PostgreSQL’in kendi içindeki yüksek erişilebilirlik özellikleri daha yavaş gelişiyor diye düşünüyorum. Çünkü PostgreSQL’in kendine eklenen her özellik, çeşitli “yancılar”ın çöpe gitmesine yol açıyor.
Replikasyon için önce veri değişimlerini triggerlarla yakalamaya çalışıyorduk. Sonra PostgreSQL kendisi veri değişimlerini kaydetmeye başlayınca, o araçlar gözden düştü ve veri aktarımını Linux tarafındaki araçlarla halletmeye başladık. PostgreSQL servisleri birbirine veri aktarabilmeye başlayınca, sistem tarafındaki çözümlere de ihtiyaç kalmadı.
PostgreSQL’in ilk replikasyon çözümü, fiziksel replikasyon (physical replication), 2000’lerin ikinci yarısı için bilişim sektörünün gidişatının tersine bir çözümdü. Sektör her şeyi daha üst katmanlarda çözmeye yöneliyordu. PostgreSQL ise veri değişimini disk üzerindeki veri değişimleri şeklinde kaydetmeyi tercih etmişti. Bunu aslında tamamen dışarıdan bir uygulama olarak (ör: DRBD) yapmak da mümkündü. PostgreSQL’in “içinde” olmanın avantajını yeterince kullanmıyordu. Sağlam bir yapı olmakla beraber, esneklik yoktu. Farklı majör sürümler arasında replikasyon olamıyordu. Belirli bir tabloyu aktarma, sadece bazı sorguları aktarma ve benzeri esneklikleri yoktu. Verinin aynı anda birden fazla sunucuya yazılması da mümkün değildi. Çünkü PostgreSQL hangi işlemlerin veriyi değiştirdiğinin kaydını tutmuyordu. Sadece disk üzerindeki “fiziki” dosyalarda yapılan değişime odaklıydı.
2010’ların ikinci yarısında mantıksal replikasyonun (logical replication) temelleri atılmaya başlandı. “Yancı” çözüm üretenlerden 2nd Quadrant firması, PostgreSQL için kendi multi-primary (veri yazabilen birden fazla sunucu olması) çözümünü parça parça resmi PostgreSQL’in içine eklemeye başladı. Önce PostgreSQL mantıksal olarak ne veri değiştirdiğini kaydetmeye başladı. Buradan Foreign Data Wrapper (FDW) gibi farklı entegrasyon ve ölçekleme çözümleri türedi. Sonra 2017’de havai fişeklerle mantıksal replikasyonu karşıladık. PostgreSQL artık birçok esnekliğe sahipti. Belli eksikleri vardı ama bir-iki sürüme o da kalmazdı. 2nd Quadrant en geç 2020’de resmi PostgreSQL’e tam multi-primary çözümü geleceğini söylüyordu. Sonra…
Sonra senelerce “sabunlu” kaldık. Mantıksal replikasyonun üzerine bir çivi daha çakılmadı. Başka bir PostgreSQL firması olan EnterpriseDB, 2nd Quadrant’ı satın aldı.
“Sabunlu” kalmayı tarif etmek gerekirse, örneğin artık birden fazla sunucudan veri değiştirebiliyorduk ve PostgreSQL bunu diğer sunuculara aktarabiliyordu. Ama değiştirilen verinin hangi sunucuda değiştirildiğinin kaydı tutulmadığı için, değişim başka bir sunucuya aktarıldığında o sunucu veriyi kendi değiştirdi zannedip diğerlerine geri aktarıyor ve sonsuz döngüye giriyordu.
Mantıksal replikasyon uzun yıllar “ancak şunlara dikkat ederek kullanabilirsiniz” dediğimiz ve bu eksikleri kendi ürünlerinde kapatanların müşterilerine sattığı bir çözüm olarak kaldı.
Bir-iki yıl önce tekrar hareketlendi ortalık. Hatta PostgreSQL 18 sürümü ile “mantıksal replikasyonda DDL ve şema değişikliklerini artık elle her bir sunucuda yapmamıza gerek kalmayacaak, hatta sekans (sequence) değerleri de artık aktarılabileceek” haberleri çıktıysa da, PostgreSQL 18 dokümanları bu özelliğin sürüme girmediğini söylüyor. Yine de çıkmadık candan umut kesilmez.
Daha hala resmi bir multi-primary çözümü ne yazık ki yok. Mantıksal replikasyonu da insanlara anlatırken utana sıkıla “ama şu ama bu” diyerek kursaklarına diziyoruz.
Var bi hayalimiz: PostgreSQL dünyasında keşke firmalar kendine müslüman olmasa, PostgreSQL’in kaynak kodunu kullanarak ürettiği çözümleri PostgreSQL dünyasının geri kalanı ile de paylaşsa. Aa, bir dakika. Bunu sağlayan GNU’nun fakir ama gururlu bir GPL lisansı yok muydu? Vardı da, PostgreSQL onun yerine, bunu sağlamayan BSD lisansını tercih etmişti. İşte şimdi buradayız.