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

pg_ctl: command not found

Hi, If you can not reach pg_ctl command in bash also you are sure this command exists in your server, check $PATH. -bash-4.2$ echo $PATH /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin So, the directory of pg_ctl is not seem in PATH. Input directory of pg_ctl and check it then run it.
Post a Comment
Read more..

PostgreSQL Foreign Data Wrappers

Hi all, I would like to mention about generating Foreign Data Wrappers(FDW) on PostgreSQL 9.6. FDW is used for remote access to tables from external data storage. If needed to use remote table in a query, you can use FDW tables. For instance you can get a table from remote database, but there is a condition. The condition is that user should have proper privileges on FDW table. There is two extension for FDW on PostgreSQL. First one is used for accessing PostgreSQL database to PostgreSQL database, called postgres_fdw . Second one is used for accessing PostgreSQL database to different databases (SQL Server, Sysbase) called tds_fdw .  Foreign Data Wrappers feature lets you to cross-query between remote database tables. Postgres_fdw and tds_fdw has different structure. Tds_fdw usign Tabular Data Stream application layer protocol to transfer data between database server and client. Generating Tds_fdw and Postgres_fdw is similar. I share an example for generating FDW between tw...
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..