Confused by the behavior of pg_basebackup with replication slot - Mailing list pgsql-general

From Yi, Yi
Subject Confused by the behavior of pg_basebackup with replication slot
Date
Msg-id C82A1D88ED30274FB6187060757EC7DC0140722001@G08CNEXMBPEKD02.g08.fujitsu.local
Whole thread Raw
Responses Re: Confused by the behavior of pg_basebackup with replication slot  (Julien Rouhaud <julien.rouhaud@dalibo.com>)
List pgsql-general
Hello,

I had an issue with the behavior of pg_basebackup command. I was convinced previously that pg_basebackup command always
madethe binary copy of the database cluster files of the postgres master. However, I recently noticed that
pg_basebackupdid not copy the the replication slot object of the master, in comparison with the fact that the
copy-command-based-backupdid copy the replication slot object. Is this difference designed on purpose ? 

Considering the difference mentioned above, I'm wandering that is there anything else that the pg_basebackup would NOT
copyfrom the master ? 
In other words, what is the no-copying rules of pg_basebackup ?

Any help will be greatly appreciated. Thanks.

Best Regards.


P.S.    The details of my test is shown as follows.


1.  Edit the postgresql.conf of the master to add replication slot

## ~(Skipping the edit operation of postgresql.conf)~
wing@master:~$ cat /mnt/data/pgdata/master/postgresql.conf | grep "max_replication"
max_replication_slots = 2 # max number of replication slots


2. Create one replication slot on master.

testdb=# select * from pg_create_physical_replication_slot('slot1');
 slotname | xlog_position
----------+---------------
 slot1    |
(1 row)

testdb=# SELECT * FROM pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restar
t_lsn
-----------+--------+-----------+--------+----------+--------+------------+------+--------------+-------
------
 slot1     |        | physical  |        |          | f      |            |      |              | 7/AD00
0220
(1 row)


3. Execute the pg_basebackup to make the base backup on the slave machine as slave1

## ~(Skipping the preparation operation of the pg_basebackup )~
wing@ubslave:~$ pg_basebackup -h {Master IP} -p 5432-U wing -F p -P -x -R -D /home/wing/pgdata/slave1  -l
baseup_slave1.log


4. Confirm the replication slot settings of slave1

## ~(Skipping the operation for starting the slave1 cluster )~
## The 'max_replication_slots' settings of postgresql.conf equals with the one on master.
wing@ubslave:~$ cat /home/wing/pgdata/slave1/postgresql.conf | grep "max_replication"
max_replication_slots = 2 # max number of replication slots

## However, there is NO RECORD in “pg_replication_slots” of slave1.
testdb=# SELECT * FROM pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restar
t_lsn
-----------+--------+-----------+--------+----------+--------+------------+------+--------------+-------
------
(0 rows)


5. Use the “pg_start_backup -> copy -> pg_stop_backup” method to make the base backup on the slave machine as slave2

## 5.1 execute pg_start_backup() on master
## 5.2 scp the data files from master to slave2.
## 5.3 execute pg_stop_backup() on master


6. Confirm the replication slot settings of slave2

## ~(Skipping the operation for starting the slave2 cluster )~
## The 'max_replication_slots' settings of postgresql.conf equals with the one on master.
wing@ubslave:~$ cat /home/wing/pgdata/slave2/postgresql.conf | grep "max_replication"
max_replication_slots = 2 # max number of replication slots

## Differing from slave1, slave2 had a record in “pg_replication_slots” which is similar to the one of master.
testdb=# SELECT * FROM pg_replication_slots;
 slot_name | plugin | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restar
t_lsn
-----------+--------+-----------+--------+----------+--------+------------+------+--------------+-------
------
 slot1     |        | physical  |        |          | f      |            |      |              | 7/AB00
C540
(1 row)


Both master and slave are running PostgreSQL 9.5.0 on Ubuntu Server 14.04(64 bit)

--
Best Regards
---------------------------------------------------
FNST) Yi Yi
---------------------------------------------------






pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Error: insufficient data in the message
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Request - repeat value of \pset title during \watch interations