Skip to main content

PostgreSQL ile Physical Replication Slot ve Pg_Basebackup

Physical Replication Slot

Physical Replicatio slot, disk bloklarındaki değişikliklerini karşı tarafa gönderir. Aktarılan WAL dosyalarını kontrol eder. Replication Slot yazısına buradan ulaşabilirsiniz.

Physical slot oluşturmak için pg_create_physical_replication_slot() fonksiyonu kullanılır. Tam kullanımı şöyledir.
Checkpoint sonrası güncel WAL dosyasının hangisi olduğu bilgisi bu fonksiyonu kullanarak oluşturduğumuz slot ile tutulmaz. Açıkcası bunu tercih etmemek için geçerli sebeplerim var ve açıklamasını aşağıda yaptım.

select pg_create_physical_replication_slot('slot_name');

Aynı fonksiyona gelen ikinci parametre ile checkpoint sonrası güncel WAL dosyası bilgisi tutulur. Bunun önemi ve asıl farkı aşağıdaki örneklerin altında açıklanmıştır.

select pg_create_physical_replication_slot('slot_name',true);
 
 

gunce=# select pg_create_physical_replication_slot('slot_first_standby');
pg_create_physical_replication_slot
-------------------------------------
(slot_first_standby,)
(1 row)


İkinci bir physical slot daha oluşturacağım. Bu sefer true parametresini de ekliyorum.gunce=# select pg_create_physical_replication_slot('slot_second_standby',true);
pg_create_physical_replication_slot
-------------------------------------
(slot_second_standby,1/A46F9418)
(1 row)


Restart_lsn sütunu, bu slot'un ihtiyaç duyduğu en eski WAL adresi tutar böylece bu değer bir sonraki checkpoint sırasında otomatik olarak değiştirilmeyecektir. Eğer bir sonraki checkpoint sırasında bu değer değişirse ihtiyaç duyduğu en eski WAL ile checkpointin yapıldığı WAL dosyası arasında fark oluşacak. Bu durumu önlemek için pg_create_physical_replication_slot() fonksiyonuna true parametresi ekliyorum.


gunce=# select slot_name,restart_lsn from pg_replication_slots;
slot_name | restart_lsn
---------------------+-------------
slot_first_standby |
slot_second_standby | 1/A46F9418
(2 rows)

 

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)
 

Ayrıca kullanılmak istenmeyen bir slot'u silmek için aşağıdaki betiği çalıştırabilirsiniz.

SELECT pg_drop_replication_slot('slot_name');

Standby tarafında veritaabnını oluşturmak için pg_basebackup kullanacağım. Not olarak yeni data dizininin daha önceden oluşturulmasına gerek yok, pg_basebackup komutu kendisi otomatik olarak oluşturacaktır.
 

[postgres@localhost ~]$ pg_basebackup -S slot_second_standby -D /var/lib/pgsql/11-2/data/ -R -v
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 1/A7000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: write-ahead log end point: 1/A7000130
pg_basebackup: waiting for background process to finish streaming ...

pg_basebackup: base backup completed

Pg_basebackup sonrası standby tarafında data klasörü altında recovery.conf
dosyası oluşturuldu. İçeriği şöyle;

standby_mode = 'on'
primary_conninfo = 'user=postgres passfile=''/var/lib/pgsql/.pgpass'' port=5432 scram_channel_binding=''tls-unique'' sslmode=prefer sslcompression=0 krbsrvname=postgres target_session_attrs=any'
primary_slot_name = 'slot_second_standby'


primary_slot_name=slot_second_standby olarak geldi.

Standby'ı ayağa kaldıralım.

[postgres@localhost data]$ /usr/local/pgsql/bin/pg_ctl -D /var/lib/pgsql/11-2/data -l logfile start
waiting for server to start.... done
server started


Log dosyasına bakıp bağlantının kurulduğundan emin olalım.

2018-06-21 19:35:45.942 +03 [3944] LOG: listening on IPv4 address "0.0.0.0", port 54112
2018-06-21 19:35:45.942 +03 [3944] LOG: listening on IPv6 address "::", port 54112
2018-06-21 19:35:45.944 +03 [3944] LOG: listening on Unix socket "/tmp/.s.PGSQL.54112"
2018-06-21 19:35:45.979 +03 [3945] LOG: database system was interrupted; last known up at 2018-06-21 19:32:28 +03
2018-06-21 19:35:46.049 +03 [3945] LOG: entering standby mode
2018-06-21 19:35:46.059 +03 [3945] LOG: redo starts at 1/A7000028
2018-06-21 19:35:46.073 +03 [3945] LOG: consistent recovery state reached at 1/A7000130
2018-06-21 19:35:46.073 +03 [3944] LOG: database system is ready to accept read only connections
2018-06-21 19:35:46.092 +03 [3949] LOG: started streaming WAL from primary at 1/A8000000 on timeline 1


Replikasyon başarılı görünüyor. Master tarafında students tablosunu oluşturuyorum.

gunce=# CREATE TABLE students( id INT, name CHARACTER VARYING(50));
CREATE TABLE


Standby üzerinde tabloya bakıyorum oluşturulup oluşturulmadığını kontrol etmek için.

gunce=# SELECT * FROM students ;
id | name
----+------
(0 rows)

 

Standby üzerindeki veritabanında tablo oluşturulmuş.

Peki standby servisi durduğu zaman ne olacak? Standby üzerinde çalışan PostgreSQL servisini kapatalım ve master üzerinde WAL dosyası yaratacak transactionlar çalıştıralım pgbench ile. WAL dosyalarının standby tarafındaki hareketine bakalım.


[postgres@localhost data]$ /usr/local/pgsql/bin/pg_ctl -D /var/lib/pgsql/11-2/data -l logfile stop
waiting for server to shut down.... done
server stopped


Master üzerindeki WAL dosyaları pgbench öncesi şöyle;

[postgres@localhost data]$ ls -la /var/lib/pgsql/11/data/pg_wal/
total 65556
drwx------.  3 postgres postgres    12288 Jun 21 19:37 .
drwx------. 19 postgres postgres     4096 Jun 21 19:38 ..
-rw-------   1 postgres postgres 16777216 Jun 21 19:42 0000000100000001000000A8
-rw-------   1 postgres postgres 16777216 Jun 21 19:30 0000000100000001000000A9
-rw-------   1 postgres postgres 16777216 Jun 21 19:32 0000000100000001000000AA
-rw-------   1 postgres postgres 16777216 Jun 21 19:32 0000000100000001000000AB
drwx------.  2 postgres postgres     4096 May 30 12:25 archive_status


Pgbench ile WAL dosyasının oluşmasına yardımcı olalım.

[postgres@localhost data]$ pgbench -c 10 -j 2 -t 1000 gunce
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 50
query mode: simple
number of clients: 10
number of threads: 2
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
latency average = 16.280 ms
tps = 614.247051 (including connections establishing)
tps = 614.326453 (excluding connections establishing)


WAL dosyalarının bulunduğu pg_wal dosyasına baktığımızda 3 adet WAL dosyasının geldiği görünüyor.

[postgres@localhost data]$ ls -la /var/lib/pgsql/11/data/pg_wal/
total 114708
drwx------.  3 postgres postgres    12288 Jun 21 23:14 .
drwx------. 19 postgres postgres     4096 Jun 21 19:38 ..
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000A8
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000A9
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000AA
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000AB
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000AC
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000AD
-rw-------   1 postgres postgres 16777216 Jun 21 23:14 0000000100000001000000AE
drwx------.  2 postgres postgres     4096 May 30 12:25 archive_status


Standby tarafındaki PostgreSQL servisini yeniden başlatalım ve pg_wal klasörüne bakalım.

[postgres@localhost data]$ /usr/local/pgsql/bin/pg_ctl -D /var/lib/pgsql/11-2/data -l logfile start
waiting for server to start.... done
server started
 

Standby üzerindeki aktarılmış WAL dosyalarına bakalım.

[postgres@localhost data]$ ls -la /var/lib/pgsql/11-2/data/pg_wal/
total 114700
drwx------  3 postgres postgres     4096 Jun 21 23:17 .
drwx------ 19 postgres postgres     4096 Jun 21 23:17 ..
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000A8
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000A9
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AA
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AB
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AC
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AD
drwx------  2 postgres postgres     4096 Jun 21 23:17 archive_status
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 xlogtemp.4312


Replication için kullandığımız slot'un restart_lsn değerine bakalım.

postgres=#  select slot_name,restart_lsn from pg_replication_slots;
      slot_name      | restart_lsn
---------------------+-------------
 slot_first_standby  |
 slot_second_standby | 1/AE488818
(2 rows)

En son checkpoint'in yapıldığı yeri redo_lsn sütununda görebiliriz.

postgres=# select redo_lsn from pg_control_checkpoint();
redo_lsn
------------
1/AE488818
(1 row)
 

Burada en son aktarılan WAL dosyasının AE ile biten olduğunu anlayabiliriz. Standby tarafındaki pg_wal klasörüne yeniden baktığımızda gelen yeni WAL'i görebiliriz.

[postgres@localhost data]$ ls -la /var/lib/pgsql/11-2/data/pg_wal/
total 114700
drwx------  3 postgres postgres     4096 Jun 21 23:17 .
drwx------ 19 postgres postgres     4096 Jun 21 23:17 ..
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000A8
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000A9
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AA
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AB
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AC
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AD
-rw-------  1 postgres postgres 16777216 Jun 21 23:17 0000000100000001000000AE
drwx------  2 postgres postgres     4096 Jun 21 23:17 archive_status


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...