Errore Hot Backup PostgreSQL 9.1: il sistema di database si sta avviando

Ho lavorato su un backup caldo per Postgres 9.1 per un po 'e ho riscontrato un problema coerente. Dopo aver riavviato Postgres sul server slave, il file di registro pgstartup e il file di registro giornaliero nella directory pg_log vengono letti senza errori. Tuttavia, quando provo ad accedere al database usando il comando psql, ottengo l'errore:

FATAL: il sistema di database si sta avviando.

Anche il file recovery.conf non si trasforma in recovery.done. Ho studiato a fondo questo errore e trovo costantemente la stessa risposta: il database non è stato chiuso in modo pulito prima di provare a riavviare Postgres. L'unico modo in cui ho riavviato Postgres è tramite i comandi service postgresql-9.1 restarto /etc/init.d/postgresql-9.1 restart. Dopo aver ricevuto questo errore, interrompo tutti i processi e provo nuovamente a riavviare il database e ancora ricevo lo stesso errore. Sono a corto di dove andare da qui e come risolvere questo problema. Di seguito è riportato il processo esatto che ho fatto per completare il backup a caldo.

Configurazioni del server principale:

pg_hba.conf, ha aggiunto la riga:

replica host postgres Trust IPAddressOfSlaveServer

postgresql.conf:

wal_level = hot_standby
max_wal_senders = 5
hear_address = '*'
porta = 5432
max_wal_senders = 5
wal_keep_segments = 32

Configurazioni del server slave:

postgresql.conf:

hot_standby = attivo

recovery.conf:

standby_mode = on
primary_conninfo = host = IPAddressOfMasterServer
porta = 5432
utente = postgres
restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'

Dopo aver configurato entrambi i server

Passo all'utente postgres sul server principale ed eseguo i comandi:

psql -c "Seleziona pg_start_backup ('label', true);";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data slave: /var/lib/pgsql/9.1/data \
        --exclude postmaster.pid
pgsql -c "seleziona pg_stop_backup ();";

Dopo aver sincronizzato il database con il server slave

Riavvio del server slave e l'avvio non ha esito negativo. Il pgstartup.log recita:

Successo. È ora possibile avviare il server database utilizzando:

    /usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
o
    /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l inizio file di log

il file di registro del giorno corrente, postgresql-Thu.log, recita:

Registro: spegnimento
Registro: il sistema di database è spento
Registro: il sistema di database è stato chiuso in fase di ripristino nel 2012-4-10
Registro: accesso alla modalità standby
Registro: file di registro "logFileName" ripristinato dall'archivio
Registro: stato di recupero coerente raggiunto a 0 / BF0000B0
Registro: la ripetizione inizia da 0 / BF000020
Registro: file di registro "logFileName" ripristinato dall'archivio
Registro: pageaddr imprevisto 0/85000000 nel file di registro 0, segmento 192, offset 0
Registro: pageaddr imprevisto 0/85000000 nel file di registro 0, segmento 192, offset 0
Log: replica dello streaming connessa correttamente al primario

Ho studiato pageaddr inaspettati e dagli archivi di Postgres, ho capito che è abbastanza normale e uno dei modi previsti per rilevare la fine del WAL.

Qualsiasi consiglio sarebbe molto apprezzato.

Il messaggio "Il sistema di database si sta avviando". non indica un errore. La ragione per cui si trova a livello FATAL è che sarà sempre presente nel registro, indipendentemente dall'impostazione di log_min_messages:

http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

Dopo il rsync, hai davvero eseguito quello che hai mostrato ?:

pgsql -c "seleziona pg_stop_backup ();";

Dal momento che, per quanto ne so, non esiste alcun pgsqleseguibile che lascerebbe il backup incompleto e lo slave non uscirà mai dalla modalità di ripristino. D'altra parte, forse hai davvero corso psql, perché altrimenti non vedo come lo schiavo avrebbe registrato messaggi di successo come:

Registro: stato di recupero coerente raggiunto a 0 / BF0000B0

e:

Log: replica dello streaming connessa correttamente al primario

Hai provato a connetterti allo slave a questo punto? Quello che è successo?

Il messaggio "Successo. Ora puoi iniziare ..." di cui parli è generato da initdb, che non dovrebbe essere eseguito come parte della configurazione di uno slave; quindi penso che potresti essere confuso su qualcosa lì. Sono anche preoccupato per queste dichiarazioni apparentemente contrastanti:

L'unico modo in cui ho riavviato Postgres è tramite il servizio postgresql-9.1 restart o /etc/init.d/postgresql-9.1 comandi di riavvio. Dopo aver ricevuto questo errore, interrompo tutti i processi e provo nuovamente a riavviare il database ...

Hai provato a interrompere il servizio tramite lo script di servizio? Quello che è successo? Potrebbe essere utile comprendere i registri se si aggiungono prefissi alle righe con ulteriori informazioni. Noi usiamo:

log_line_prefix = '[%m] %p %q<%u %d %r> '

La recovery.confsceneggiatura sembra strana. Stai copiando dalla directory pg_xlog del master, dalla directory pg_xlog attiva dello slave o da una directory di archivio?

Ho avuto anche alcuni problemi con questo, tranne che ero su 9.3, non 9.1. Comunque, la correzione si è rivelata abbastanza banale:

Il postgresql.conffile veniva copiato dal master allo slave e lo lasciavo non modificato sullo slave. Pensavo che tutto ciò che dovevi fare fosse aggiungere un recovery.conffile e tutto avrebbe funzionato (bene, ma non riuscivo ad accedere al server slave replicato, ma veniva replicato).

Ho modificato il postgresql.conffile dello slave e:

• ha commentato il archive_mode=on
• archivecomando commentato ; e
• commentata hot_standby=on

Ciò ha fatto: sono stato in grado di ottenere il database come server di sola lettura pronto ad accettare query di sola lettura.

Esiste uno script chiamato pg_basebackupche creerà la directory bootstrap per lo slave. Questa è la directory dei dati con il database al suo interno. È necessario modificare il postgresql.conffile prima che possa essere utilizzato come slave come descritto, qualcosa di piuttosto semplice per uno pg_basebackupscript post .

È interessante notare che ho risolto questo nel modo opposto di Paul.

Ho aggiunto:

hot_standby = on

o, piuttosto, cambiato #hot_standby = offin quanto sopra. (Questo stava usando 9.5)

Ho ottenuto questo nei registri:

MSK FATAL:  the database system is starting up

Per correggere l'avvio infinito del server, procedere come segue: Interrompere il servizio (se esiste), terminare il processo 'postgres' (di solito esiste). Esegui questo in console:

pg_resetxlog.exe -D ../Data -f

Questo utilizzo appare perché la directory xLog ha dei dati che non possono essere scritti prima della chiusura del servizio. E poi all'avvio del servizio tenta di correggere quei dati. A volte si blocca l'avvio e non finisce mai .. Comando in alto questi dati non corretti, che applicano il servizio per iniziare solo con dati fissi. Forse alcune parti di dati non corretti andranno perse, ma il server di database funzionerà normalmente e sarà accessibile dalle app.