Erro de backup quente do PostgreSQL 9.1: o sistema de banco de dados está inicializando

Estou trabalhando em um backup quente do Postgres 9.1 por um tempo e encontrei um problema consistente. Após reiniciar o Postgres no servidor escravo, o arquivo de log pgstartup e o arquivo de log diário no diretório pg_log são lidos sem erros. No entanto, quando tento entrar no banco de dados usando o comando psql, recebo o erro:

FATAL: o sistema de banco de dados está sendo inicializado.

O arquivo recovery.conf também não liga para recovery.done. Pesquisei extensivamente esse erro e encontrei consistentemente a mesma resposta: o banco de dados não foi desligado corretamente antes de tentar reiniciar o Postgres. A única maneira de reiniciar o Postgres é através dos comandos service postgresql-9.1 restartou /etc/init.d/postgresql-9.1 restart. Depois de receber esse erro, eu mato todos os processos e tento reiniciar o banco de dados e ainda recebo o mesmo erro. Estou sem saber para onde ir e como corrigir esse problema. Abaixo está o processo exato que eu fiz para concluir o backup ativo.

Configurações do servidor principal:

pg_hba.conf, adicionou a linha:

replicação de host postgres IPAddressOfSlaveServer trust

postgresql.conf:

wal_level = hot_standby
max_wal_senders = 5
listen_address = '*'
port = 5432
max_wal_senders = 5
wal_keep_segments = 32

Configurações do servidor escravo:

postgresql.conf:

hot_standby = ativado

recovery.conf:

standby_mode = ativado
primary_conninfo = host = IPAddressOfMasterServer
port = 5432
usuário = postgres
restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'

Depois de configurar os dois servidores

Mudo para o usuário do postgres no servidor principal e executo os comandos:

psql -c "Selecione 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 "selecione pg_stop_backup ();";

Após sincronizar o banco de dados com o servidor escravo

Eu reinicio o servidor escravo e a inicialização não falha. O pgstartup.log lê:

Sucesso. Agora você pode iniciar o servidor de banco de dados usando:

    /usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
ou
    /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l logfile start

o arquivo de log do dia atual, postgresql-Thu.log, lê:

Log: desligando
Log: o sistema de banco de dados está desligado
Log: o sistema de banco de dados foi encerrado em recuperação em 10/04/2012
Log: entrando no modo de espera
Log: arquivo de log restaurado "logFileName" do arquivo
Log: estado de recuperação consistente atingido em 0 / BF0000B0
Log: refazer começa em 0 / BF000020
Log: arquivo de log restaurado "logFileName" do arquivo
Log: inesperado pageaddr 0/85000000 no arquivo de log 0, segmento 192, deslocamento 0
Log: inesperado pageaddr 0/85000000 no arquivo de log 0, segmento 192, deslocamento 0
Log: replicação de streaming conectada com êxito ao primário

Pesquisei pageaddr inesperado e, nos arquivos do postgres, entendo que é bastante normal e uma das maneiras esperadas de detectar o fim do WAL.

Qualquer conselho seria muito apreciado.

A mensagem "O sistema de banco de dados está iniciando". não indica um erro. A razão pela qual está no nível FATAL é para que ele sempre chegue ao log, independentemente da configuração de log_min_messages:

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

Após o rsync, você realmente executou o que mostra ?:

pgsql -c "selecione pg_stop_backup ();";

Como, até onde eu sei, não há pgsqlexecutável, isso deixaria o backup incompleto e o escravo nunca sairia do modo de recuperação. Por outro lado, talvez você realmente tenha executado psql, porque, caso contrário, não vejo como o escravo teria registrado mensagens de sucesso como:

Log: estado de recuperação consistente atingido em 0 / BF0000B0

e:

Log: replicação de streaming conectada com êxito ao primário

Você tentou se conectar ao escravo neste momento? O que aconteceu?

A mensagem "Sucesso. Agora você pode iniciar ..." mencionada é gerada por initdb, que não deve ser executada como parte da configuração de um escravo; então eu acho que você pode estar confuso sobre algo lá. Também estou preocupado com essas declarações aparentemente conflitantes:

As únicas maneiras pelas quais reiniciei o Postgres é através do serviço postgresql-9.1 restart ou dos comandos /etc/init.d/postgresql-9.1 restart. Depois de receber esse erro, eu mato todos os processos e tento reiniciar novamente o banco de dados ...

Você tentou parar o serviço através do script de serviço? O que aconteceu? Pode ajudar a entender os logs se você prefixar as linhas com mais informações. Nós usamos:

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

O recovery.confscript parece estranho. Você está copiando do diretório pg_xlog do mestre, do diretório pg_xlog ativo do escravo ou de um diretório de archive?

Eu também tive alguns problemas com isso, exceto que eu estava na 9.3, não na 9.1. De qualquer forma, a correção acabou sendo bastante trivial:

O postgresql.confarquivo estava sendo copiado do mestre para o escravo, e eu o deixava sem modificação no escravo. Eu pensei que tudo que você precisava fazer era adicionar um recovery.confarquivo e tudo funcionaria (bem, funcionou, mas não consegui efetuar login no servidor escravo replicado, mas estava sendo replicado).

Editei o postgresql.confarquivo do escravo e:

• comentou o archive_mode=on
• archivecomando comentado ; e
• comentado hot_standby=on

Foi o que fiz: consegui que o banco de dados fosse um servidor somente leitura pronto para aceitar consultas somente leitura.

Existe um script chamado pg_basebackupque criará o diretório de inicialização para o escravo. Este é o diretório de dados com o banco de dados. Você precisa modificar o postgresql.confarquivo antes que ele possa ser usado como escravo, conforme descrito, algo bastante simples para um post pg_basebackupscript.

Curiosamente, eu resolvi isso da maneira oposta que Paulo fez.

Eu adicionei:

hot_standby = on

ou melhor, alterado #hot_standby = offpara o acima. (Isso estava usando 9.5)

Eu consegui isso nos logs:

MSK FATAL:  the database system is starting up

Para corrigir o início infinito do servidor, faça o seguinte: Interrompa o serviço (se existir), interrompa o processo 'postgres' (normalmente existe). Execute isso no console:

pg_resetxlog.exe -D ../Data -f

Este uso aparece porque o diretório xLog possui dados que não são gravados antes do encerramento do serviço. E então, na inicialização do serviço, ele tenta consertar esses dados. Às vezes, congela a inicialização e nunca termina. Comando na limpeza desses dados não corrigidos, que aplicam o serviço para iniciar apenas com dados fixos. Talvez algumas partes dos dados não corrigidos sejam perdidas, mas o servidor de banco de dados será executado normalmente e poderá ser acessado por aplicativos.