In repmgr, I had register the master server, but at the Standby server, i had cloned the Master backup to Standby data directory sucessfully. But after cloning while starting the Standby server, I got the following error.
Use of uninitialized value $info{"pgdata"} in -d at /usr/bin/pg_ctlcluster line 354.
Use of uninitialized value $info{"pgdata"} in concatenation (.) or string at /usr/bin/pg_ctlcluster line 355.
Error: is not accessible or does not exist
Please help in this issue.
After some research, I able to solve it. I had to clone the Master backup to the Data directory of the (Default) Standby data Directory (/var/lib/postgresql/9.3/main).
If we need to keep the data directory separate (Apart from Default), It raises the error. If anyone solved by configuring the data directory separately, please help me.
Related
I tried to synchronize between source/target clusters by using pg_rewind by the following command.
And I know 100% the content of in the source/target clusters are not the same anymore.
/usr/pgsql-12/bin/pg_rewind --source-server="192.168.100.100 user=postgres password=mypassword" -D /var/lib/pgsql/12/data --progress
but pg_rewind gives the following message
pg_rewind: source and target cluster are on the same timeline
pg_rewind: no rewind required
I didn't understand how the content of pg_wal & base directories are different between source/target but pg_rewind did't realize that !!
pg_rewind only undoes data modifications on the target server later than the latest common checkpoint.
Modifications that have happened on the source server after the latest common checkpoint are ignored – these will be recovered anyway when the target server becomes a standby of the source server.
So the target server probably was shut down cleanly before the source server got promoted.
The message about the timeline is coincidental, it is not the cause of the second message.
I'm trying to setup a basic master slave configuration using streaming replication for postgres 10 and docker
Since the official docker image provides a docker-entrypoint-initdb.d folder for placing initialization scripts i thought it would be a swell idea to start placing my preparation code here.
What i'm trying to do is automate the way the database is restored before starting the slave in standby mode, so i run
rm -rf /var/lib/postgresql/data/* && pg_basebackup 'host=postgres-master port=5432 user=foo password=foo' -D /var/lib/postgresql/data/
and this succeeds.
Then the server is shutdown and restarted as per the docker initialization script, which pops up a message saying
database system identifier differs between the primary and standby
Now I've been sitting online for a while now, and the only 2 explanations i got is that I either have a misconfigured recovery.conf file, which looks like this
standby_mode = 'on'
primary_conninfo = 'host=postgres-master port=5432 user=foo password=foo'
trigger_file = '/tmp/postgresql.trigger'
Where the connection string is the same one i used for the base backup.
The second solution circulating is that the backup command could be messed up, but the only thing i add to the data folder after backup is the recovery.conf file.
Anyone have any idea where i'm messing up?
Should i just go for repmgr and call it a day?
Thanks in advance
To give an answer to my own question, the issue lied in how the dockerfile entrypoint scripts were called. Rather, they would end up starting the instance as a master or slave according to variables that were not properly set by me.
I'm trying to access the postgreSQL database from CLI. When I login as postgres and enter command
I'm getting error
psql: FATAL: could not open file "base/11951/11717": Read-only file system
I'm new to this. Any pointers on where to look at would be a great help. TIA
Seems like the VM where the database was hosted went to Read-only mode for an unknown issue.
$ fsck
command helped to repair linux filesystems and was able to access psql db.
Most likely your system has detected disk errors and put the filesystem in read-only mode to protect its self from possible corruption.
Check dmesg and the kernel log files.
I strongly advise you to read and act on https://wiki.postgresql.org/wiki/Corruption .
Sometimes It indicates that the server had a general error...(Happened to me yesterday, the moment the server was restarted, the "FATAL: could not open file" disappeared.
I have a master-slave setup using postgres 9.5.3 and got the following error in my postgres log
"could not start WAL streaming: ERROR: requested starting point 0/D000000 on timeline 2 is not in this server's history"
I would like to know if there is sql query that can tell me that my server no longer has the requested starting point so I will be able to automatically start full copy of the master data directory.
Thanks
Avi
I don't think that you can get this information with SQL; you'd have to examine the contents of pg_xlog.
Wouldn't it be a better solution to use a replication slot to ensure that WAL is kept long enough?
I have three different databases for my different environments (hsprd, hstst,hstrn). hsprd is my production environment with live data.
Every so often, a request comes through to restore production data to hstrn or hstst. I typically run this command (after stopping, then dropping the db):
db2 restore db hsprd taken at 20140331180002 to /dbs into hstrn newlogpath /dbs/log/hstrn without rolling forward;
When running this, I receive this message:
SQL2537N Roll-forward is required following the Restore.
Could someone advise how to fix this?
Thanks.
edit: My backups are here:
(/home/dbtmp/backups)> ll
total 22791416
-rwxrwxr-x 1 hsprd cics 11669123072 Mar 31 18:03 HSPRD.0.hsprd.NODE0000.CATN0000.20140331180002.001
After restoring my database and omitting without rolling forward, I receive this message when trying to query the database:
SQL1117N A connection to or activation of database "HSTRN" cannot be made
because of ROLL-FORWARD PENDING. SQLSTATE=57019
When I try to rollforward, with this command, I receive this response:
(/home/dbtmp/backups)> db2 rollforward db hstrn to end of backup and complete;
SQL4970N Roll-forward recovery on database "HSTRN" cannot reach the specified
stop point (end-of-log or point-in-time) on database partition(s) "0".
Roll-forward recovery processing has halted on log file "S0006353.LOG".
The first error suggests that you are restoring an online backup, which must be rolled forward. Alternatively, use an offline backup image, then you can include the without rolling forward option.
The second error means that you need to issue the ROLLFORWARD command before you can use the database restored from an online backup.
Finally the third error means that the ROLLFORWARD command is unable to find the logs required for it to succeed. Assuming the logs are included in the backup image, you'll need to specify the LOGTARGET option on the RESTORE command to extract them, presumably to the NEWLOGPATH location.