Physical Replication Slot
Replication Slot konusu oldukça uzun bir konu. Yazıya Replication Slot, Physical Replication Slot ve Logical Replication Slot konularını tek başlıktan üç farklı başlık olarak böldüm. Dolayısıyla hızlıca konuya giriş yaparsak eğer, 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, <\span>
No comments