Skip to main content

PostgreSQL ile Logical Replication Slot

Logical Replication Slot 

Logical Decoding

Replication Slot yazısına buradan ulaşabilirsiniz. Giriş bilgisi bu yazıda yer almaktadır. 

Logical Replication, logical decoding kullanır. Logical decoding, veritabanı tabloları üzerinde commit edilmiş processlerin karşı tarafa row-by-row aktarılmasıdır. Oluşturulan her bir slot sadece bir veritabanı için kullanılabilir. Bir veritabanında birden fazla birbirinden bağımsız slot oluşturulabilir.

 Logical replication Slot'lar alıcı tarafla ilgili herhangi bilgiye sahip olmadıkları için yukarıda bahsettiğim disk size'ının dolması durumunun yaşanması kontrol edilmeyen bir sistemde kaçınılmaz olacaktır. Unlogged veya temp tables slot ile karşı tarafa aktarılmadığı unutulmamalıdır.

Logical Replication kullanılmadan önce wal_level=logical olarak set edilmeli ve max_replication_slots değeri en az 1 olarak set edilmeli.

Logical Replication Slot oluşturulması Physical Replication Slot ile benzerdir.

Logical Replication Slot oluşturmak için pg_create_logical_replication_slot() fonksiyonu kullanılabilir. Bu fonksiyonun iki parametresi bulunmaktadır. Bu parametreden ilki logical replication slot ismidir. İkincisi ise WAL içinde deconding yapmak için kullanılan output plugin dir. İki output plugin bulunmaktadır contrib/test_decoding. Bu ikisi dışında slot oluşturduğunuzda logical decoding adımlarını görmek istediğinizde kullanacağınız pg_logical_slot_get_changes() fonksiyonu sonucunda hata alacaksınız.

Logical Replication Slot oluşturalım.

gunce=# SELECT * FROM pg_create_logical_replication_slot('log_repl_slot','test_decoding');
   slot_name   |    lsn    
---------------+------------
 log_repl_slot | 1/B0021008
(1 row) 

Oluşturduğumuz physical ve logical replication slotlara ait bilgileri pg_replication_slots view'i ile görüntüleyebiliriz.

Select * from pg_replication_slots;

gunce=# Select slot_name,plugin,slot_type,database, restart_lsn,confirmed_flush_lsn  from pg_replication_slots;
      slot_name      |    plugin     | slot_type | database | restart_lsn | confirmed_flush_lsn
---------------------+---------------+-----------+----------+-------------+---------------------
 log_repl_slot       | test_decoding | logical   | postgres | 1/B0045558  | 1/B0045600
 slot_first_standby  |               | physical  |          |             |
 slot_second_standby |               | physical  |          | 1/B004F3D0  |
(3 rows)

Logical Slot için mevcut değişiklik var mı kontrol ettiğimizde aşapıda bir sonuç dönmediğini görüyoruz.Bunun anlamı, slot oluşturulduktan sonra veritabanı üzerinde sonucu kesin veritabanında gerçekleştirilmiş bir process'in olmamasından kaynaklıdır.

Dummy bir tablo oluşturup içine veri ekliyorum.

gunce=# create table aa(a int);
CREATE TABLE 
gunce=# insert into aa values(1);
INSERT 0 1
gunce=# insert into aa values(1);
INSERT 0 1 
gunce=# insert into aa values(1);
INSERT 0 1

 test_decoding output plugin'i kullanarak oluşturulan logical replication slot'umuz üzerinden geçen değişiklikler için
pg_logical_slot_get_changes() fonskiyonu kullanılır.

Tüm değişiklikler için;
Select pg_logical_slot_get_changes('slot_name',Null,Null);

Sadece transactional işlemleri görmek için 'include-xids','0' parametreleri eklenir.
Select pg_logical_slot_get_changes('slot_name',Null,Null, 'include-xids','0' );

Sadece timestamp değişikliklerini görmek için 'include-timestamp','on' parametreleri eklenir.
Select pg_logical_slot_get_changes('slot_name',Null,Null, 'include-timestamp','on' );

gunce=# SELECT * FROM pg_logical_slot_get_changes('log_repl_slot', NULL, NULL, 'include-xids', '0');
    lsn     |  xid   |                 data                 
------------+--------+---------------------------------------
 1/B0021038 | 314353 | BEGIN
 1/B0032C18 | 314353 | COMMIT
 1/B0032C50 | 314354 | BEGIN
 1/B0032C50 | 314354 | table public.aa: INSERT: a[integer]:1
 1/B0032CC0 | 314354 | COMMIT
 1/B0032CC0 | 314355 | BEGIN
 1/B0032CC0 | 314355 | table public.aa: INSERT: a[integer]:1
 1/B0032D30 | 314355 | COMMIT
 1/B0032D30 | 314356 | BEGIN
 1/B0032D30 | 314356 | table public.aa: INSERT: a[integer]:1
 1/B0032DA0 | 314356 | COMMIT
(11 rows)

Slot oluşturulduktan sonra yaptığım tüm değişiklikler WAL içinde yer almaktadır. Bu değişiklikleri görüntülemek için pg_logical_slot_get_changes() kullanıyoruz. gunce=# create table bb (b timestamp);
CREATE TABLE
gunce=# insert into bb values(now());
INSERT 0 1
gunce=# insert into bb values(current_date);
INSERT 0 1

Timestamp değişiklikleri aşağıda 'include-timestamp','on' ile görüntüleyebiliriz. 

gunce=# SELECT * FROM pg_logical_slot_get_changes('log_repl_slot', NULL, NULL, 'include-timestamp', 'on');

    lsn     |  xid   |                                         data                                        
------------+--------+--------------------------------------------------------------------------------------
 1/B0032EE8 | 314357 | BEGIN 314357
 1/B0044690 | 314357 | COMMIT 314357 (at 2018-06-27 16:23:00.491118+03)
 1/B00446C8 | 314358 | BEGIN 314358
 1/B00446C8 | 314358 | table public.bb: INSERT: b[timestamp without time zone]:'2018-06-27 16:23:32.678428'
 1/B0044738 | 314358 | COMMIT 314358 (at 2018-06-27 16:23:32.679398+03)
 1/B0044770 | 314359 | BEGIN 314359
 1/B0044770 | 314359 | table public.bb: INSERT: b[timestamp without time zone]:'2018-06-27 00:00:00'
 1/B00447E0 | 314359 | COMMIT 314359 (at 2018-06-27 16:23:39.717562+03)
(8 rows)

Sevgiler,
Labels:

Comments

Post a Comment

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ı...
Post a Comment
Read more..

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...
Post a Comment
Read more..

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...
Post a Comment
Read more..