patternsqlMinor
Streaming Replication in PostgreSQL
Viewed 0 times
postgresqlstreamingreplication
Problem
I'm trying to set up two PostgreSQL servers on one machine and perform a streaming replication. I have succeeded once, but when i've tried again following exactly the same steps it doesn't work.. Those are the steps:
I have $PGDATA = home/postgresql/9.1/data
and $STANDBY = home/postgresql/9.1/data2
initdb -D $PGDATA
initdb -D $STANDBY
-
In the master node in postgresql.conf set:max_wal_senders = 1
archive_mode = on
archive_command = 'cp %p ~/postgresql/backup/archivedir/%f'
wal_level = archive
wal_keep_segments = 32
-
Start the master node and do the base backup:psql -d dellstore2 -c "SELECT pg_start_backup('backup for replication', true)"
rsync -av ${PGDATA}/ $STANDBY --exclude postmaster.pid
psql -d dellstore2 -c "select pg_stop_backup()"
pg_stop_backup says that everything is fine, all the WAL files were archived
-
In the standby (data2) node I create recovery.conf with:standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=5432 user=repuser password=haslo'
trigger_file = '/home/michau/postgresql/replication.trigger'
restore_command = 'cp /home/michau/postgresql/backup/archivedir/%f "%p"'
-
Start the master node, then start the standby node - replication should start and standby should catch up with the master. That was exactly what happened the first time.
Now when I start the standby I get: "Address already in use" error.
Of course both standby and master have the same port specified in postgresql.conf (they have exactly the same postgresql.conf files). If I change the port in standby to let's say 5433 then I get:
LOG: database system was shut down in recovery at 2012-06-12 19:48:01 CEST
LOG: entering standby mode
cp: cannot stat /home/michau/postgresql/backup/archived
I have $PGDATA = home/postgresql/9.1/data
and $STANDBY = home/postgresql/9.1/data2
- Set up two nodes:
initdb -D $PGDATA
initdb -D $STANDBY
- In the master node create a user for replication. I do that in pgAdmin (it does have superuser privileges)
- In the master node in pg_hba.conf add the part that allows standby to connect:
host replication repuser 127.0.0.1/0 md5-
In the master node in postgresql.conf set:max_wal_senders = 1
archive_mode = on
archive_command = 'cp %p ~/postgresql/backup/archivedir/%f'
wal_level = archive
wal_keep_segments = 32
-
Start the master node and do the base backup:psql -d dellstore2 -c "SELECT pg_start_backup('backup for replication', true)"
rsync -av ${PGDATA}/ $STANDBY --exclude postmaster.pid
psql -d dellstore2 -c "select pg_stop_backup()"
pg_stop_backup says that everything is fine, all the WAL files were archived
-
In the standby (data2) node I create recovery.conf with:standby_mode = 'on'
primary_conninfo = 'host=127.0.0.1 port=5432 user=repuser password=haslo'
trigger_file = '/home/michau/postgresql/replication.trigger'
restore_command = 'cp /home/michau/postgresql/backup/archivedir/%f "%p"'
-
Start the master node, then start the standby node - replication should start and standby should catch up with the master. That was exactly what happened the first time.
Now when I start the standby I get: "Address already in use" error.
Of course both standby and master have the same port specified in postgresql.conf (they have exactly the same postgresql.conf files). If I change the port in standby to let's say 5433 then I get:
LOG: database system was shut down in recovery at 2012-06-12 19:48:01 CEST
LOG: entering standby mode
cp: cannot stat /home/michau/postgresql/backup/archived
Solution
PostgreSQL replicas never finish recovering. This is by design. Basically a replica is always in "recovering from disaster" mode except that it is using receiving the WAL segments from the master rather than on disk.
So what you are seeing is not cause for concern. If it is not working yet, then you will need to provide a more detailed description of what you are trying to do and what is not working. But as far as you are posting it seems normal.
So what you are seeing is not cause for concern. If it is not working yet, then you will need to provide a more detailed description of what you are trying to do and what is not working. But as far as you are posting it seems normal.
Context
StackExchange Database Administrators Q#19138, answer score: 8
Revisions (0)
No revisions yet.