The message "The database system is starting up." does not indicate an error. The reason it is at the FATAL level is so that it will always make it to the log, regardless of the setting of log_min_messages
:
http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN
After the rsync, did you really run what you show?:
pgsql -c "select pg_stop_backup();";
Since there is, so far as I know, no pgsql
executable, that would leave the backup uncompleted, and the slave would never come out of recovery mode. On the other hand, maybe you really did run psql
, because otherwise I don't see how the slave would have logged such success messages as:
Log: consistent recovery state reached at 0/BF0000B0
and:
Log: streaming replication successfully connected to primary
Did you try connecting to the slave at this point? What happened?
The "Success. You can now start..." message you mention is generated by initdb
, which shouldn't be run as part of setting up a slave; so I think you may be confused about something there. I'm also concerned about these apparently conflicting statements:
The only ways I have restarted Postgres is through the service
postgresql-9.1 restart or /etc/init.d/postgresql-9.1 restart commands.
After I receive this error, I kill all processes and again try to
restart the database...
Did you try to stop the service through the service script? What happened? It might help in understanding the logs if you prefixed lines with more information. We use:
log_line_prefix = '[%m] %p %q<%u %d %r> '
The recovery.conf
script looks odd. Are you copying from the master's pg_xlog directory, the slave's active pg_xlog directory, or an archive directory?
My locale settings were not properly configured when PostgreSQL was installed. Purging and reinstalling didn't help. I followed the instructions here and that did the trick for me.
Essential parts of the linked information reproduced below:
The problem showed itself in the following manner:
warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
...
are supported and installed on your system.
The first one was very easy to solve by executing:
#dpkg-reconfigure locales
...and choosing the preferred locales.
But after that PostgreSQL still refused to start. This is due to the fact that the installation process tried to create a cluster at installation time but because of the bad locales this wasn't done. So we have to redo this step by executing:
#pg_createcluster 9.3 main --start
(For the 9.3 version of PostgreSQL)
After that step PostgreSQL starts flawlessly via
#/etc/init.d/postgresql start
Best Answer
You specified
#!/bin/sh
in your script's shabang line. This gives you a POSIX shell. Under POSIX style shells you can only specify numbers for redirection, as noted in the documentation under section 2.7 Redirection.&>
is a "bashism", shown here in the bash documentation under io-redirection.This can cause undefined behavior under POSIX compliant shells acting as
/bin/sh
, and by runningshellcheck -s sh
on the contents of the script in the above question, as stated under the warning for SC2039, which warns that&>
is non-standard, and might fail under different contexts.You might have better luck, if you specify
#!/usr/bin/env bash
, or if you change the way that you're doing the redirection, if you want to keep using the#!/bin/sh
shell.As for the
$BACKUP_PATH
, you might want to double-quote it to prevent any sort of weirdnesses with globbing or word splitting that can happen, which could also possibly explain the zero size tar file.Hope that helps. =)