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

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.

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 two Po

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