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 diske yazıldıktan 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,
No comments