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?
This won't work. Don't even try feeding mysqldump
output directly into psql
. You'll need to dump schema and data separately, convert the schema either by hand or with a tool, load the converted schema into PostgreSQL then load the dumped data.
mysqldump
's compatibility flags are moderately useful for dumping data but pretty useless for dumping schema definitions.
The "relation does not exist" error will be a follow-up error caused by a prior one. Try running with psql --set ON_ERROR_STOP=1 ....
.
Best Answer
Your question is very unclear (see comment) but I'm going to make a guess at it anyway.
I think you
DROP
ped thepostgres
database. You're used to always connecting to PostgreSQL as thepostgres
superuser using thepostgres
database, probably via sudo andpeer
authentication with something like:where you don't specify a database name to connect to. So with no
postgres
database, you don't know how to connect anymore. You get an error like:If so, you just need to connect to a different database and re-create the
postgres
database. It only exists as a convenient scratch area - the system doesn't actually care if thepostgres
database exists or not, and doesn't use it for anything.Something like:
will do the trick.
If you dropped the
template1
database as well, you could still recover by connecting to any other database on the server and re-creatingtemplate1
from the locked, protectedtemplate0
database; see the documentation on template databases.Key things to understand:
You don't have to connect to the
postgres
database. It doesn't get used for anything except a default place to connect to when using thepostgres
user. If youDROP
it the system doesn't care.psql
connects by default to the database with the same name as the current user. You can just pick another one withpsql databasename
.psql
connects by default with the username of the current unix user. You can just pick another one with (eg)psql -U someuser
. This will work fine ifpg_hba.conf
is configured to permit the connection.While the
postgres
user is the default superuser, you can create another one, and you don't have to rely onpeer
authentication to use it either; you can usemd5
password auth or whatever you want. So while you're probably used to just usingsudo -u postgres psql
you can actually set things up in a variety of flexible ways. I frequently create a database superuser for my regular unix user account (CREATE USER myuser WITH SUPERUSER ENCRYPTED PASSWORD 'blah';
) when I'm on a scratch/development box, so I'm not messing about withsudo
all the time.