Question

I was doing migrations while the server was still accessing the slave DB. I have a master / slave setup. After I restarted the server, I realized I couldn't connect to the SLAVE anymore. I went into the SLAVE and tried restarting Postgres, this is what it returned:

$ sudo /etc/init.d/postgresql start
 * Starting PostgreSQL 9.3 database server                                       
 * The PostgreSQL server failed to start. Please check the log output:
2014-12-16 22:14:20 UTC LOG:  database system was interrupted while in recovery at log time 2014-12-16 20:57:20 UTC
2014-12-16 22:14:20 UTC HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
2014-12-16 22:14:20 UTC LOG:  entering standby mode
2014-12-16 22:14:20 UTC LOG:  redo starts at 0/38620168
2014-12-16 22:14:20 UTC LOG:  consistent recovery state reached at 0/38680BF0
2014-12-16 22:14:20 UTC LOG:  database system is ready to accept read only connections
2014-12-16 22:14:20 UTC PANIC:  heap2_redo: unknown op code 32
2014-12-16 22:14:20 UTC CONTEXT:  xlog redo UNKNOWN
2014-12-16 22:14:21 UTC LOG:  startup process (PID 18357) was terminated by signal 6: Aborted
2014-12-16 22:14:21 UTC LOG:  terminating any other active server processes

Any idea on what could be causing this and what I can do to fix this? I'm going into a PANIC frenzy.

Was it helpful?

Solution

http://www.postgresql.org/docs/9.3/static/release-9-3-3.html

Fixing this required changing the WAL record format for tuple freezing. While this is no issue for standalone servers, when using replication it means that standby servers must be upgraded to 9.3.3 or later before their masters are. An older standby will be unable to interpret freeze records generated by a newer master, and will fail with a PANIC message. (In such a case, upgrading the standby should be sufficient to let it resume execution.)

Licensed under: CC-BY-SA with attribution
Not affiliated with dba.stackexchange
scroll top