İçindekiler

Günümüz dünyasında veri kritik bir emtiadır ve bu nedenle verileri tek bir yerde saklamak risklidir, bu nedenle bir arızadan mümkün olan en kısa sürede kurtulmanızı sağlamak için bir stratejiniz ve bir planınız olması gerekir.

Replikasyon, yüksek kullanılabilirlik (HA- High Availability) ve etkili felaket kurtarma (DR – Disaster Recovery) stratejisi sağlamayı amaçlayan herhangi bir veritabanı sisteminin kritik bir parçasıdır. HA ve DR’ın yanında replikasyon performans, yedeklilik, veri aktarımı ve test sistemlerinin kurulumu içinde kullanılabilir.

Replikasyon terimi, bir veya daha fazla yazılım veya donanım sistemi arasında bilgi paylaşımı sürecini tanımlamak için kullanılır; güvenilirlik, kullanılabilirlik ve hata toleransı sağlamak için. Bu sistemler aynı veri merkezinde olabileceği gibi, tek bir makinede olabilir veya farklı veri merkezinde olup  ağ üzerinden bağlanabilir. Replikasyon, genel olarak Donanım ve Yazılım kategorilerine ayrılabilir, bu kategorileri kısaca inceleyeceğiz, ancak ana odak noktası veritabanı replikasyonudur. Önce kısaca veritabanı replikasyonu tanımını yapmak istiyorum; Veritabanı replikasyonu, verilerin veritabanı instance’ından bir veya daha fazla veritabanı instance’ına kopyalanması sürecini açıklar.

Donanım Tabanlı Replikasyon

Donanım tabanlı replikasyon, birden çok bağlı sistemi senkronize tutar. Bu veri senkronizasyonu, sistemde bir I/O gerçekleştirilir gerçekleştirilmez depolama düzeyinde yapılır, yapılandırılmış depolama modüllerine/cihazlarına/sistemlerine yayılır. Bu tür bir replikasyon, depolama alanının tamamı veya seçilen partition için yapılabilir. Bu tür bir çözümün en büyük avantajı, (genellikle) kurulumunun kolay olması ve yazılımdan bağımsız olmasıdır. Bu, çok daha iyi performans göstermesini sağlar, ancak replikasyon üzerindeki esnekliği ve kontrolü azaltır. Bu tür çoğaltmanın  artıları;

  • Gerçek zamanlı : Tüm değişiklikler sonraki sistemlere hemen uygulanır.
  • Kurulumu Kolay : Hiçbir komut dosyası veya yazılım yapılandırması gerekmez.
  • Uygulamadan Bağımsız : Replikasyon, depolama katmanında gerçekleşir ve işletim sistemi/yazılım uygulamasından bağımsızdır.
  • Veri Bütünlüğü ve Tutarlılığı : Mirror işlemi, depolama diskinin tam bir kopyasını depolama katmanında gerçekleştiğinden, veri bütünlüğü ve tutarlılığı otomatik olarak sağlanır.

Donanım tabanlı replikasyonun bazı avantajları olmasına rağmen, yine de kendi sınırlamaları ile birlikte gelir. Genellikle donanım üreticisi firma bağımlılığına dayanır, yani aynı tip donanım kullanılmalıdır ve buda çoğu zaman çok uygun maliyetli olamıyor.

Yazılım Tabanlı Replikasyon

Bu replikasyon tipi genel çözümlerden ürüne özgü çözümlere kadar değişebilir. Genel çözümler, verileri yazılım düzeyinde farklı sistemler arasında kopyalayarak donanım çoğaltmasını taklit etme eğilimindedir. Replikasyonun gerçekleştirilmesinden sorumlu olan yazılım, yazılan her biti kaynak depolamaya kopyalar ve hedef sistemlere yayar. Oysa ürüne özgü çözümler, ürün gereksinimlerine daha duyarlıdır ve genellikle belirli bir ürün içindir. Yazılım tabanlı çoğaltmanın artıları ve eksileri vardır. Bir yandan, replikasyonun nasıl yapıldığına ilişkin esneklik ve kontrol sağlar ve genellikle donanım tabanlı repliksayona göre düşük maliyetlidir ve çok daha iyi bir dizi özellik sağlar. Ancak öte yandan, çok fazla konfigürasyon gerektirir ve sürekli izleme ve bakım gerektirir.

Veritabanı Replikasyonu

Şimdi asıl konumuz olan veritabanına replikasyonuna girmeden önce veritabanı dünyasındaki bir replikasyon sisteminin farklı bileşenlerini tanımlamak için kullanılan terminolojilerden bahsedelim; Primary-Standby, Master-Slave, Publisher-Subscriber, Master-Master/Multimaster replikasyon kurulumuna katılan veritabanı sunucularını tanımlamak için en sık kullanılan terimlerdir. Primary, Master ve Publisher terimleri kendisi tarafından alınan değişiklikleri diğer düğümlere yaymaya çalışan aktif düğümü tanımlamak için kullanılır. Standby, Slave ve Subscriber terimleri aktif düğümlerden yayılan değişiklikleri alacak pasif düğümleri tanımlamak için kullanılır. Ben aktif düğümü tanımlamak için Primary ve pasif düğüm için Standby terimlerini kullanacağım.

Veritabanı Replikasyonun nasıl çalıştığı hakkında anlamamız gereken bazı temel noktalar vardır;

  • Postgres, primary sunucu arızalandığında otomatik olarak yük devretme işlevi sağlamaz. Yük devretmeyi yönetmek için 3. parti araç kullanmadığınız sürece bu manuel bir işlemdir.
  • Standby ile yük denegeleme(load balancing) otomatik değildir. Yük dengeleme, uygulamanız için bir gereksinimse, read-write işlemleri için primary sunucuyu ve read only işlemler için standby sunucuyu kullanan bir yük dengeleme çözümü sağlamalısınız.

Primary-Standby (Single Master) ve Multi Master Replikasyon

Veritabanı replikasyonu Primary-Standby  ve Multi-Master olmak üzere 2 model ile kurgulanabilir.

Primary-Standby  Replikasyon : Belirlenen primary veritabanındaki değişiklikler bir veya daha fazla standby sunucusuna çoğaltılır. Standby veritabanının read write kullanımına izin verilmez. (Bir şekilde standby veritabanında read write yapılsa bile bu değişiklikler primary veritabanına kopyalanmaz) Bu kullanımda, uygulamaların trafiği primary veritabanına yönlendirmesi gerektir. Tek primary’dan dolayı çatışma(conflict) ihtimali yoktur. Yapılandırma ve yönetme daha az karmaşık olduğu için çoğu zaman tek primary yeterlidir.

Multi-Master Replikasyon : Master görevi gören birden fazla sunucu olduğu anlamına gelir. Veriler, sunucular arasında çoğaltılır ve read write işlemleri bir grup master sunucu üzerinde mümkün olabilir. Bu durumda, verilerin birden çok kopyası vardır. Sistem aynı zamanda eşzamanlı değişiklikler arasında meydana gelen herhangi bir çatışmanın(conflict) çözümünden de sorumludur.

NOT : Yukarıdada yazdığım gibi, primary-standby replikasyon çoğu durumda yeterlidir, ancak yine de, multi-master replikasyon gereksiniminin olduğu bazı durumlar vardır. PostgreSQL internal olarak multi-master replikasyon modeline sahip değildir. Bazı Multimaster replikasyon çözümleri (BDR, xDB, PostgreSQL-XL, PostgreSQL-XC2, Rubyrep, Bucardo) mevcuttur, bunlardan bazıları uygulama olarak geliştirilmiş ve bazıları PostgreSQL fork larıdır. Bu forkların kendi toplulukları vardır ve çoğunlukla tek bir şirket tarafından yönetilir, ancak bunlar ana PostgreSQL community tarafından yönetilmez.

Senkron ve Asenkron Replikasyon

Veritabanı replikasyonu Senkron ve Asenkron olmak üzere iki strateji ile kurgulanabilir;

Senkron Replikasyon : Maksimum veri koruması için bir koruma yöntemidir, standby veritabanı bu modda kullanıcıya sıfır veri kaybı  özelliği sağlar. Bu stratejide kullanıcı başlattığı bir transaction için commit koyduğu anda başlatılan transaction Standby’a uygulanmadan kullanıcıya commit edildiği bilgisi dönmez. Senkron replikasyon, anlık yük devretme gereksinimleri olan üst düzey ortamlarda kullanılır diyebiliriz.

Asenkron Replikasyon : Bu stratejide kullanıcı commit yaptığı anda standby veritabanları beklenmeden(sadece primary veritabanınında wal kaytlarının diske yazılması beklenir)  commit edildiği bilgisi kullanıcıya döner, yani transaction commit edildiğinde sadece primary veritabnına verinin yazılacağının garantisi vardır. Primary veritabanının çöküp standby veritabanlarından devam etme durumunda veri kaybı meydana gelebilir, ancak bu strateji primary veritabanına çok az ek yük sağlar ve bu nedenle çoğu durumda kabul edilebilir.

Postgresql Cluster Replication

NOT : Bazı sistemler ayrıca karar vermek için quorum  kullanır. Quorum kullanılırsa, veritabanlarının yarısından fazlasının cluster içindeki bir eylem üzerinde anlaşması gerekir.  Örneğin 3 PostgreSQL sunucusundan (master, slave-1, slave-2) oluşan bir clusterı düşünürsek, synchronous_standby_names’i ANY 1 (slave-1,slave-2) ayarlayarak quorum replication ayarlayabiliriz. Bu şekilde üç node’dan ikisi daima en yeni verilere sahip olacaktır.

Amacınıza uygun olanı seçebilmeniz için her iki tür replikasyon modunun nasıl çalıştığını anlamak önemlidir. Herhangi bir seçimde performans dikkate alınmalıdır. İşlevsellik ve performans arasında genellikle bir denge vardır. Örneğin, yavaş bir ağ üzerinden tamamen senkron bir çözüm, performansı yarıdan fazla düşürebilirken, asenkron bir çözümün performansı minimum düzeyde etkileyebilir.

Cascading Replikasyon

Şimdiye kadar sadece primary veritabanının transaction verilerini standby veritabanına aldığını gördük. Bu, birden çok sistem arasında dağıtılabilen bir yüktür; yani, veriyi alan ve diske yazılan bir standby veritabanı, verileri ondan almak üzere yapılandırılan standby veritabanlarına iletebilir.

Postgresql Cluster Replication 2

Standby Veritabanı Modları

Warm standby : PostgreSQL’in uyguladığı ilk replikasyon yöntemi (warm standby) (verisyon 8.2, 2006’da), log gönderme yöntemine dayanıyordu. WAL kayıtlarının doğrudan uygulanmak üzere bir veritabanı sunucusundan diğerine taşındığı anlamına gelir. Bunun sürekli bir PITR olduğunu söyleyebiliriz. PostgreSQL, WAL kayıtlarını her seferinde bir dosya (WAL segmenti-16 MB) aktararak dosya tabanlı log gönderimi gerçekleştirir. Bu replikasyon uygulamasının dezavantajı, primary sunucularda büyük bir arıza olması durumunda henüz gönderilmemiş transactionların kaybolacağıdır. Dolayısıyla, veri kaybı ihtimali vardır.(Bunu, birkaç saniye kadar düşük bir değere ayarlanabilen archive_timeout parametresini kullanarak ayarlayabilirsiniz, ancak bu kadar düşük bir ayar, dosya transferi için gereken bant genişliğini önemli ölçüde artıracaktır) Bu modda standby veritabanları read only olarak kullanılamaz. Detaylar linklerdedir link-1 ve link-2.

Hot standby : Hot standby, halihazırda arşiv kurtarma işlemi gerçekleştiren bir standby veritabanında sorgu çalıştırma yeteneğinin adıdır, yani hot standby sayesinde read only standby veritabanına sahibiz.

Postgresql Replikasyon Seçenekleri

PostgreSQL,  internal olarak streaming ve logical replikasyon seçenekleri sunar.

Streaming Replikasyon (SR)

Postgres’te fiziksel ve binary replikasyon olarak da bilinir. Streaming replikasyon, standby sunucusunun dosya tabanlı log gönderimiyle mümkün olandan daha güncel kalmasını sağlar. Bu özellik ile WAL dosyasının doldurulmasını beklemeden, WAL kayıtları oluşturuldukları anda standby veritabanına aktarılır.

Streaming replikasyon varsayılan olarak asenkrondur ancak istenirse senkron da yapılabilir; bu durumda, primary veritabanında bir işlemin gerçekleştirilmesi ile standby modunda değişikliklerin görünür hale gelmesi arasında küçük bir gecikme olur. Wal arşivleme kullanılmadan streaming replikasyon kullanılırsa, standby veritabanı wal kayıtlarını almadan önce eski WAL kayıtları silinebilir. Böyle bir durumda standby veritabanının yeni bir base backupdan döndürülmesi gerekecek.

wal_keep_segments ‘i WAL segmentlerinin çok erken silinmemesini sağlayacak kadar büyük bir değere ayarlayarak veya standby için bir replikasyon slot yapılandırarak bunu önleyebiliriz. Tabi standby tarafından erişilebilen WAL arşiv sistemi kurarsanız bu çözümler gerekli değildir, çünkü standby, yeterli segmenti tutması koşuluyla, arşivi yakalamak için her zaman kullanabilir. Streaming replikasyonun, dosya tabanlı log transferinden temel farkı primary_conninfo parametresinin ayarlanmasıdır. Standby başlatıldığında ve primary_conninfo doğru ayarlandığında arşivde bulunan tüm WAL dosyalarını yeniden oynattıktan sonra standby veritabanı primary veritabanına bağlanacaktır. Bağlantı başarılı bir şekilde kurulursa primary’de walsender, standby’da ise walreceiver prosesleri ayağa kalkar. walreceiver prosesi primary_conninfo parametersi ile sağlanan bağlantı ayrıntılarını kullanıp TCP/IP bağlantısı ile primary sunucuya bağlanır. walsender prosesi ise WAL kayıtlarını oluşturulurken standby sunucusuna göndermekle sorumludur. walreceiver prosesi, WAL kayıtlarını, local olarak bağlı istemcilerin istemci etkinliği tarafından oluşturulmuş gibi WAL’a kaydeder. WAL kayıtları WAL segment dosyalarına ulaştığında, standby sunucusu WAL’ı yeniden çalıştırıp devam eder, böylece standby ve primary eşitlenir.

Replication Slot : Primary’deki WAL kayıtlarının tüm standby veritabanları tarafından alınana kadar WAL kayıtlarının kaldırmamasını ve primary ile standby bağlantısı kesildiğinde bile recovery çakışmasına(recovery conflict) neden olabilecek satırları kaldırmamasını sağlamak için otomatik bir yol sağlar.

Streaming replikasyon ile ilgili örnek kurulum ve detaylar linktedir.

Logical  Replikasyon

Logical  Replikasyon, transactional replikasyon olarak da bilinen replikasyon türü Streaming replikasyona kıyasla PostgreSQL’de oldukça yenidir. Daha kolay anlaşılabilmesi adına stream ile logical arasındaki farkı anlatarak logical replikasyonu anlatmak istiyorum;

  • Streaming replikasyon tek bir tablonun veya primary  sunucudaki verilerin bir alt kümesinin standby’a alınmasına izin vermez. Logical  replikasyon, tüm veritabanını kopyalamak yerine, veritabanındaki belirli nesnelerin standby veritabanına kopyalanmasını sağlar.
  • Streaming replikasyon iki farklı ana sürüm arasında yapılamaz fakat logical’de böyle bir sınırlama yok.
  • Streaming replikasyon’da internal olarak standby sunucuda write işlemi yapılamaz, ama logical’da yapılabilir. (Tabi veri çakışması ihtimali DBA’in sorumluluğundadır)
  • Streaming replikasyon’da farklı platformlar arasında yapılamaz(örneğin, Linux ve Windows) fakat logical’de böyle bir sınırlama yok.

Logical replikasyon ile ilgili örnek kurulum ve detaylar linktedir.

Mustafa Bektaş Tepe
İyi Çalışmalar

Loading