I found a temporary solution to my problem. I edited the pg_hba.conf of the 9.3 server to say trust in the first two active lines. And after restarting (sudo service postgresql restart) I can connect to the server again using pgadmin. The downside is that the server might now not be password protected (I will open a separate question if I encounter any problems with that).
# Database administrative login by Unix domain socket
local all postgres trust
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
You seem to be trying to replicate from one server to another that wasn't set up using a copy of the original server. That's why:
database system identifier differs between the primary and standby. The primary's identifier is 6022019027749040119, the standby's identifier is 6033562405193904122.
Because each newly initdb
'd PostgreSQL gets a new random system identifier. When you copy an existing PostgreSQL install, it keeps the same system identifier. That's how PostgreSQL can keep track of whether one server can replay WAL from another.
You can only use physical replication if the replica is a copy (file-system level backup e.g. pg_basebackup
) of the master. See the manual's detailed coverage on replication for more information.
Update:
The instructions shown above should be fine, but they're not as clear as they could be.
The standby server's data directory is supposed to be replaced by the base backup you create at step 8, if it exists in the first place.
You can't make an existing PostgreSQL instance into a standby for another without replacing its data directory. You need a copy of the master's data directory to run a standby. A common way to set that up is to take an existing standby, delete its data directory, replace it with a copy of the master's data directory, and then configure it as a replication slave. That's what I think step 8 is supposed to be doing.
Instead of doing that I think you probably used an existing data directory for the slave and tried to start it up as a replica of the master. That will not work, and will result in the errors you showed.
The main PostgreSQL documentation on replication is the recommended and primary resource for information. I suggest going there first.
You might also want to check out repmgr, which helps automate replication and failover tasks.
Best Answer
I have recently installed postgresql 9.4 from source
My install directory structure is as follows
Then I searched for files name xxxx.opts
So, it exists in 9.4 - it appears from Googling that it generally lives in the data directory. I have never edited it manually.
So, it appears that it still has a function in the system.