Skip to main content

PostgreSQL İle Replication Slot

Merhaba,

PostgreSQL 9.4 ile Logical Decoding kavramı gelmesiyle Replication Slot yapısının temeli atıldı diyebiliriz. Çünkü Logical Replication, Logical Decoding yapsının üzerinde geliştirilmiştir. Sonrasında ise PostgreSQL 9.6 ile Logical Replication ve Physical Replication kavramlarıyla tanıştık. Öncesinde Replication Slot kavramından, daha sonra Logical ve Physical Replication kavramlarından bahsedeceğim.

Tabii öncesinde WAL kavramıyla ilgili küçük bir açıklama yapmak isterim. Çünkü Replicatiın Slot aslında kabaca WAL dosyalarının bir yerden başka bir yere kopyalanması olarak düşünebilirsiniz. 

WAL(Write-Ahead-Log)
PostgreSQL de transactional loglar 16MB lik dosyalarda saklanmaktadır. Bu dosyalar WAL(Write-Ahead-Log) dosyalarıdır. Data file'lar üzerindeki değişiklikler commit edildikten sonra ancak loglanır. Log record'lar okunduktan sonra değişiklikler kalıcı olarak diske yazılır. Aslında bunların yapılmasının tek bir amacı var o da bir sorun olması durumunda WAL dosyaları recovery sırasında kabaca dönüş biletimizin olmasıdır.

Küçük bir WAL dosyası paragrafından sonra Replication Slots konusuna devam edelim.

Replication Slots kullanılması, WAL segment'lerinin tüm standby'lar tarafından alınmadan master üzerinden silinmemesinin otomatik hale getirilmesini sağlar. Bu cümle biraz karışık gelmiş olabilir. Aslında primary sunucu (sender), standby tarafına (receiver) WAL dosyalarını aktardığından emin olduktan sonra kullanılmayan WAL dosyaları primary üzerinden siler. Bunun bir diğer anlamı aksi durumda karşı tarafa yani standby tarafına aktarılmamış tüm WAL dosyalarını aktarana kadar WAL dosyalarını primary üzerinde saklamaya devam edecektir.

Primary sunucuya bağlı olan bir standby sunucuya primary üzerinden ihtiyaç duyulan WAL dosyalarının aktarılmasının bir kaç yolu vardır. Replication Slots'ları kullanmak bu yöntemlerden sadece biri. Diğer yolları ise Wal_keep_segments ve archive_command komutlarını kullanmak.Replication slots yöntemini kullanmak için aşağıda bahsedeceğim bu iki parametrenin konfigüre edilmesine gerek yoktur. Wal_keep_segments parametresi ile sunucu üzerinde saklanması istenen WAL sayısını belirleyebiliriz. Diğer bir yöntem de archive_command parametresini arşivlemeyi istediğiniz dizini belirterek WAL dosyalarının arşivlenmesini yapmaktır.  

Wal_keep_segments: WAL dosyaları database üzerinde çalıştırılan transactionlara ait bilgileri tutar. Diske bu veriler yazıldıktan sonra kullanılmayan WAL dosyaları server üzerinden silinecektir. Wal_keep_Segments parametresini kullandığımızda bizim istediğimiz kadar WAL dosyaları PostgreSQL 9.6 ve öncesi için pg_xlog dizininde PostgreSQL 10 ve sonrasında pg_wal dizininde saklanacağı için kullanılmayan ve silinmesi gereken WAL dosyaları da saklanmak zorunda kalacaktır. Örneğin wal_keep_Segments parametresini çok büyük bir değer için set ederseniz sadece diskinizde gereksiz yer kaplamasına sebep olacaktır.
Archive_command: Archive_command komutunu kullanarak WAL dosyalarınızı istediğiniz bir dizine yada replikasyon için bir sunucuya yedekleyebilirsiniz. Eğer WAL dosyalarınızı farklı bir yerde arşivliyorsanız kullanılmayan WAL dosyalarının örneğin arşivlenen yerden silinmesi için archive_cleanup_command parametresinde pg_archivecleanup komutu kullanabilirsiniz. 
 
Her iki yöntem için, wal_keep_segments veya archive_command parametrelerinin kullanılması, kullanılmayan WAL segmentlerinin de saklanacaktır. Dolayısıyla bu iki yöntem için yaptığınız konfirürasyondan emin olmalısınız.

Replication Slots ise yukarıdaki iki yöntemin aksine sadece ihtiyaç olunan WAL segment numarasını tutar. Böylece hangi WAL dosyalarının alınması gerektiğini bilir.

Asıl konuya dönmek gerekirse, Replication Slot, WAL achiving yapmak ve streaming replcation'ı daha fazla stabil ve effektif kullanmak için kullanılabilir. Kaynaklarda Replication Slot kullanımının WAL dosyalarının taşınmasından sonra oluşturulan slot'ların silinmesi gerektiği yazıyor, bunun haklı sebeplerinden biri disk space'inin primary-secondary arasındaki sorundan dolayı dolması. Eğer Replika yapısı slot üzerine kurulduysa dikkat edilmesi gereken bazı konular olduğunun bilinmesinde fayda var. 


Replikanın offline olması durumunda master server, replikadaki son WAL kaydını bilir. Replika online olduğunda ise aktarılmak üzere master'da biriktirilen WAL dosyaları karşı tarafa geçmeye başlar. Tam da burada bir handikap bulunmakta. Standby'a erişemediği sürece silmesi gereken WAL dosyalarını silemeyecek ve master tarafında standby'a aktarana kadar eski WAL dosyalarını saklayacak. Ta ki master diski dolana kadar. Hatta bunun için şöyle bir senaryo da söz konusu; beş adet standby mevcut olsun. Eğer beş standby dan biri bile geride kalırsa master üzerinde ki silnmesi gereken eski WAL dosyaları silinmeyecektir ve disk sorunu ortaya çıkacaktır.

İki farklı Replication Slot vardır: logical decoding için Logical Slot ve replikasyon için Physical Slot'tur. Logical replication row-by-row bazında değişikliği standby tarafına aktarır. Slot, decoding için ihtiyaç olan WAL dosyalarını master sunucu üzerinde tutulduğunu bilir. Physical replication ise disk bloklarındaki değişiklikleri gönderir. Standby'a aktarılana kadar eski WAL dosyalarının master sunucu üzerinden silinmesi önlenir.

Replication Slot'lar özel isimlerle tanımlanmalıdırlar. Ayrıca bir slot sadece bir replikasyon için kullanılmaktadır. Birden fazla standby üzerinde Replication Slot kullanmayı planlıyorsanız her biri için ayrı slot oluşturmalısınız. Ya da benzer şekilde Logical Replication Slot kullanmak isterseniz her replikasyon için farklı slot oluşturmalısınız.
 

Bu yazının hemen ardından Logical ve Physical Replication Slot kullanımı için iki blog yazısı daha ekledim. Logical Replication Slot yazısına buradan, Physical Replication Slot yazısına buradan ulaşabilirsiniz.

Replication Slots'un nasıl oluşturulduğunu sizle paylaşmadan önce Replication Slot yöntemini kullanmak için postgresql.conf dosyasında bazı alanların düzenlenmesi gerekmektedir.

wal_level alanı hot_standby veya daha fazla veri içeren diğer replikasyon seçeneklerinden biri olmalı. Yani minimal seçmemelisiniz. PostgreSQL 11 ile wal_level değeri sadece minimal, replication ve logical olarak gelmekte conf dosyasında. Biz master tarafında wal_level=logical olarak kullanacağız. 


Replikasyonu ilk kez kuracaksanız eğer REPLICATION yetkisiyle oluşturulmuş bir kullanıcınızın olduğundan ve pg_hba.conf içinde gerekli ayarlamanın yapıldığından emin olmalısınız. 

Bir sonraki konuda görüşmek üzere, hoşçakalın.

Sevgiler,

Comments

Popular posts from this blog

PGConf Europe 2018 Güncesi 1

Merhaba, Diğer tüm veritabanları arasında en popüler açık kaynak kodlu veritabanı olan PostgreSQL, tüm yıl boyunca farklı ülkelerde bir çok konferansa sahiplik yapmaktadır. En bilinenleri PGDay ve PGConf'dur. Ayrıca her yıl 2 Şubatta Brüksel’de yapılan FOSDEM etkinliğinde de PostgreSQL konuşmalarının yapıldığı bir oturum mutlaka olmaktadır. PostgreSQL etkinlik detaylarına bu linkten ulaşabilirsiniz. Bu yıl ki PGConf Europe konferansı Lizbon'da yapıldı. Konferansla ilgili izlenimlerimi, yaptığım neredeyse 6 günlük yolculuğun en başından tüm detaylarıyla birlikte paylaşmak istiyorum. Yolculuğumuz sevgili Seda ile birlikte Atatürk Havalimanı’ndan sabah 07:30’da Lizbon’a direk uçuşla başladı.  Hava şahaneydi ve uçuşumuz konforlu geçti. Koltuğumuz cam kenarı ve uçağın kanadının hemen yanındaydı (benim favori koltuklarım 24, 25, 26, 27 ve 28. sıradakiler) ve biz 27. sıradaydık. Bol bol resim çektik bulutların üstündeyken ve uçak kanatlı olanlardan.  Lizbon’a vardığımı...

PostgreSQL High Availability - Patroni 2

Patroni kurulumuyla ilgili oldukça fazla kaynak bulunmakta fakat kurulum ve yönetimini beraber barındıran kaynağa denk gelmedim. Bu yazıda hem Patroni kurulumu hem de kurulum sonrası yönetimiyle alakalı detaylara ulaşabilirsiniz. PostgreSQL cluster'larının yönetimi için kullanılan Patroni ile ilgili temel bilgilerin yer aldığı Autofailover üzerine hazırladığım yazı serisine aşağıdaki linklerden erişebilirsiniz. PostgreSQL ve Autofailover PostgreSQL'de Autofailover ve Patroni 1 (Giriş) PostgreSQL'de Autofailover ve Patroni 2 (Kurulum, Konfigürasyon ve Yönetim) PostgreSQL'de Autofailover ve Patroni 3 (Mevcut PostgreSQL Cluster'inin Patroni'ye Geçirilmesi) Patroni, PostgreSQL veritabanlarının kurulumundan ve konfigürasyonundan sorumludur. Yani Patroni'yi kurduğumuz sunucular aynı zamanda Patroni ile kurulmuş PostgreSQL'leri barındıracak. Üç node'lu PostgreSQL ve üç node'lu ETCD cluster'larını oluşturacağım. Kuruluma önce üç no...

PostgreSQL High Availability - Patroni 1

Patroni, PostgreSQL HA (High Availability) Cluster yapısının kurulması ve yönetimi için kullanılan open source bir araçtır. Patroni, PostgreSQL Cluster’inin kurulumu (bootstrap), replikasyonunun kurulumu, PostgreSQL otomatik failover yapılması amacıyla kullanılır. Python ile yazılmıştır. Bir önceki yazıda PostgreSQL'de Autofailover araçlarının ne olduğu ve neden Autofailover'a gereksinim duyulduğu konusunda yazı paylaşmıştım. Yazıya buradan ulaşabilirsiniz. Patroni Kurulumu İçin Gereksinimler nedir? Patroni’nin tek başına kurulumu autofailover yapısını yapılandırmak için yeterli değildir. Patroni ile Autofailover yapısının kurulması için DCS (Distributed Configuration Store) araçlarından birine ihtiyaç vardır. Bunlardan bazıları; ETCD, Consul, ZooKeeper, Kubernetes. PostgreSQL üzerinde Autofailover araçlarından Patroni entegre edecekseniz DCS araçlarından birini kullanmanız gerekecek. DCS dediğimiz şey aslında Service Discovery araçlarından biri olduğundan bu iki tan...