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?
At the SQL level, every user can indeed connect to a newly created database, until the following SQL command is issued:
REVOKE connect ON DATABASE database_name FROM PUBLIC;
Once done, each user or role that should be able to connect has to be granted explicitly the connect privilege:
GRANT connect ON DATABASE database_name TO rolename;
Edit:
In a multi-tenant scenario, more than just the connect
privilege would be removed. For multi-tenancy tips and best practices, you may want to read on the postgresql public wiki: Shared Database Hosting and Managing rights in PostgreSQL.
Best Answer
Option 1: remove createdb for 9.1
When in doubt, use
dpkg -S
to learn which packages provide a certain command.Example:
From this it appears that
/usr/lib/postgresql/9.1/bin/createdb
is provided bypostgresql-client-9.1
, and that it's still installed. You may uninstall it since presumably you have nowpostgresql-client-9.3
Option 2: address the right instance without removing anything
Debian allows multiple simultaneous PostgreSQL instances, which is why it allows to have different
createdb
at the same time. Assuming you'd need to keeppostgresql-client-9.1
, that is possible too.The
/usr/bin/createdb
command, in the standard$PATH
(as opposed to deep under /usr/lib), is actually a wrapper that will call the real binary for the correct version depending on the context.That context may be given through the additional option, specific to Debian/Ubuntu, called
--cluster
to specify which version and server it should target. It's also available as an environment variablePGCLUSTER
, as documented in pg_wrapper, and defaults can also be specified in/etc/postgresql-common/user_clusters
.Weird: createdb pointing to 9.1.14 and psql to 9.3.5
The one thing that doesn't look right in your question is this issue. Normally
pgsql
andcreatedb
should reach the same version/cluster, since in fact they should point to the same script to start with:This would require further digging into the environment to find out how your situation differs from the default.