¿Cómo esperar a que PostgreSQL sea iniciable / restaurable?

Estoy probando una actualización de PostgreSQL 8.2.1 a 9.2 en una máquina virtual que ejecuta una distribución de Linux personalizada. El procedimiento de actualización es el siguiente:

Inicia el pgservicio
Aspire todas las bases de datos (no estoy seguro si es necesario)
Copia de seguridad con pg_dumpall
Detener el pgservicio
Aleje el directorio donde se almacenan los datos ( /var/pges una configuración simple de servidor único)
Instalar PostgreSQL 9.2
initdb
Iniciar el servidor
Restaurar los datos volcados
reindexdb todos los DB
Recrea la referential_constraintsvista
Aspire todos los DB (se requiere AFAIK después de esta actualización)

Este procedimiento funciona bien en un host, haciendo copias de seguridad y restaurando sin problemas. En otra máquina con una base de datos diferente, los puntos 1 a 7 funcionan bien, pero el servidor no se iniciará a menos que agregue un sleep 1después initdb, e incluso entonces los datos volcados no se pueden restaurar porque "el sistema de base de datos se está iniciando". ¿Cuáles son las formas estándar de lidiar con esto, a excepción de estos terribles hacks:

sleepDurante un tiempo generoso antes de cualquier operación,
bucle hasta que funcione o hasta que se alcance un tiempo de espera generoso, o
bucle hasta que acepta una consulta trivial o se alcanza un tiempo de espera.

Editar: La " solución " no funcionó después de todo. ¿Qué se necesita para asegurarse de que la base de datos esté lista para ejecutar una restauración?

postgresql restore upgrade

— l0b0
fuente

Solo una idea: ¿puedes probar el initdbestado de salida? Supongo que cuando se establece el trabajo está hecho.

— dezso

@dezso Nope, initdbse ejecuta de forma síncrona, por lo que cuando el servidor se inicia initdbya ha finalizado correctamente.

— l0b0

Entonces no tengo mejor idea que hacer una prueba simple que verifica que las cosas estén listas.

— dezso

2) no es necesario. 10) tampoco es necesario ya que restaurar el volcado volverá a crear todos los índices.

— a_horse_with_no_name

Respuestas:

initdb no regresa hasta que finaliza, por lo que no debería haber ninguna pausa necesaria entre este y el inicio del servidor. Sin embargo, ha habido errores en PostgreSQL donde se completó sin enjuagar todo al disco primero. No sé de ninguna izquierda en este momento, pero la naturaleza de los errores es que no siempre se sabe acerca de ellos.

Si usa el comando pg_ctl para iniciar la base de datos, use los parámetros "-w" para que espere hasta que finalice el inicio antes de regresar. No hace nada elegante, solo hace el "¿está listo todavía?" bucle para ti.

Tenga en cuenta que si se produce un bloqueo del servidor con una gran cantidad de datos que deben reproducirse antes de que el servidor pueda iniciarse, el tiempo de espera establecido por "-t" en la espera pg_ctl podría ser demasiado bajo.

No hay razón para VACUUM las bases de datos de origen antes de hacer una pg_dump de ellas. Si bien puede acelerar un poco el volcado, el vacío en sí llevará más tiempo que esa mejora.

— Greg Smith
fuente

¿Se requiere el paso 12.? Esperaría que las tablas fueran contiguas (o casi contiguas después de un pg_restore -j{morethan1}).

— dezso

Estamos corriendo postmasterpara iniciar el demonio, y no parece tener esa opción.

— l0b0

los ~~trabajando~~La solución rota fue modificar el script de inicio para verificar repetidamente si el puerto relevante está en uso. Si no aparece después de un minuto, se considera que el inicio ha fallado. Pseudocódigo:

start() {
    pg start
    checks=0
    while checks < 30:
        return true if the port is in use
        sleep 2
        checks++
    return false
}

Editar: Resulta que esto no es suficiente. El paso de restauración:

PGOPTIONS='--client-min-messages=warning' psql \
    --no-psqlrc \
    --variable=ON_ERROR_STOP=1 \
    --quiet \
    --log-file="$restore_log" \
    --single-transaction \
    --username postgres \
    --file="$sql_backup"

Mensaje de error:

psql: FATAL:  the database system is starting up

— l0b0
fuente