¿Por qué mi proceso de postmaster (a veces) se vuelve inmanejable después de una restauración de la base de Wal?

Question

TL; DR: El administrador de correos inutilizable e inutilizable se está generando cuando Postgres se inicia justo después de restaurar su directorio de datos desde una copia de seguridad de la base WAL. ¿Por qué?

Contexto:

Ejecutamos PostgreSQL 8.4, en CentOS 6, utilizando los paquetes PGDG. Tenemos un script para usar en entornos de prueba de desarrollador que restaura una copia de seguridad nocturna del directorio de datos de nuestro servidor de producción (creado entre llamadas a pg_start_backup y pg_stop_backup). El script descomprime el archivo y usa restore_command Para volver a aplicar cualquier WALS que se generara durante el tiempo en que se tomó la copia de seguridad en la producción.

Eso normalmente funciona bien y restaura cientos de veces más rápido que una restauración basada en SQL de un pg_dump'ED Archivo.

Problema:

A veces, después de desabrochar el Dir de datos, el script comienza a Postgres ejecutándose /etc/init.d/postgresql start (que es un enlace simbólico para /etc/init.d/postgresql-8.4. Esto lo convierte en un script init predecible para cuando finalmente actualizamos a 9.*). Informa "OK", como en: comenzó correctamente. Entonces las Wals no restauran; cuelga indefinidamente esperando un recovery.done archivo para aparecer.

Lo que he probado:

Cuando corrí /etc/init.d/postgresql status Durante el Hang indefinido, informa el script de inicio dead but pid file exists.

Entonces corrí ps -ef | grep post. Curiosamente, el proceso de postmaster y los arqueros, etc. se estaban ejecutando. Todos los parámetros de invocación fueron correctos (DataDir de derecha, etc.).

Cuando corrí psql, detectó un administrador de correos y un postgres DB, pero no detectó el DB principal, el que nos importa restaurar a través del guión WAL.

Luego revisé las permanentes en el directorio de datos, y todo se veía bien.

Correr /etc/init.d/postgresql stop informó "OK", y mató a los procesos de Archiver/Observador, pero el jefe de correos se mantuvo en funcionamiento.

Lo mismo pasó cuando lo intenté killall -r '*.postmaster*.'.

Lo único que funcionó para reanudar el Restauración de Wal Stuck fue un killall -s 3 -r '.*postmaster.*' (La señal 3 es sigquit), y luego un /etc/init.d/postgresql start.

lo comprobé pg_startup.log y los archivos diarios en pg_log Durante el estado inmanejable, y todo se veía bien. pg_startup.log registró un comienzo exitoso como la última entrada.

Posibles Causas:

Un par de cosas (menores) no son estándar sobre nuestra configuración.

• Nuestro script init está simulado, como dije antes, a un script de la versión agnóstica en /etc/init.d/postgresql. Esto apunta donde quiera que lo hagamos. En la actualidad señala /etc/init.d/postgresql-8.4.

• Nuestro postgresql.conf presentar vidas en /etc/ (con un propietario y un grupo del usuario de Postmaster), y tiene un enlace simbólico en el directorio de datos. Nuestro script de Restauración de WAL asegura que el enlace simbólico se recree antes de intentar comenzar Postgres.

• Recientemente actualizamos nuestra infraestructura de PostgreSQL 8.4.11 a 8.4.12. Estamos probando la nueva versión para la estabilidad. Nuestros servidores de producción se ejecutan 8.4.11. Sin embargo, les estamos sacando datos a través de pg_dump, limpiándolo y luego 'empaquetarlo' para WAL Restaure en otro lugar (en 8.4.12), por lo que no estamos restaurando WALS en versiones incompatibles de Postgres.

Pregunta:

¿Por qué está haciendo esto? ¿Es una de las causas posibles enumeradas a continuación, posiblemente la culpa?