Início / dba / Perguntas / 109312
Accepted
Jamess
Asked: 2015-08-07 21:33:40 +0800 CST

Postgresql - Recuperação pontual usando recovery.conf e trigger. Como minimizar o tempo de espera por arquivos .history

  • 772

Seguindo http://www.postgresql.org/docs/9.1/static/continuous-archiving.html , copio os arquivos WAL para outra máquina e os aplico regularmente. Recentemente, devido a uma falha no servidor pg em meu servidor principal, tentei restaurar o banco de dados pressionando um gatilho (um arquivo vazio, esperando failover inteligente) e os logs são fornecidos abaixo.

prodrestore_error.log

WAL file not present yet. Checking for trigger file...
trigger file found: smart failover
Trigger file:         /app/recovery-prod/trigger/pgsql.trigger.5432
Waiting for WAL file: 0000000100000001000000CC
WAL file path:        /backup/prod/db_backup/archive/0000000100000001000000CC
Restoring to:         pg_xlog/RECOVERYXLOG
Sleep interval:       60 seconds
Max wait interval:    0 forever
Command for restore:  cp "/backup/prod/db_backup/archive/0000000100000001000000CC" "pg_xlog/RECOVERYXLOG"
Keep archive history: 000000000000000000000000 and later
trigger file found: smart failover
running restore:      OK

Trigger file:         /app/recovery-prod/trigger/pgsql.trigger.5432
Waiting for WAL file: 00000002.history
WAL file path:        /backup/prod/db_backup/archive/00000002.history
Restoring to:         pg_xlog/RECOVERYHISTORY
Sleep interval:       60 seconds
Max wait interval:    0 forever
Command for restore:  cp "/backup/prod/db_backup/archive/00000002.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history: 000000000000000000000000 and later
running restore:      cp: cannot stat `/backup/prod/db_backup/archive/00000002.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000002.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000002.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000002.history': No such file or directory
not restored
history file not found
Trigger file:         /app/recovery-prod/trigger/pgsql.trigger.5432
Waiting for WAL file: 00000001.history
WAL file path:        /backup/prod/db_backup/archive/00000001.history
Restoring to:         pg_xlog/RECOVERYHISTORY
Sleep interval:       60 seconds
Max wait interval:    0 forever
Command for restore:  cp "/backup/prod/db_backup/archive/00000001.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history: 000000000000000000000000 and later
running restore:      cp: cannot stat `/backup/prod/db_backup/archive/00000001.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000001.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000001.history': No such file or directory
cp: cannot stat `/backup/prod/db_backup/archive/00000001.history': No such file or directory
not restored
history file not found

postgresql-9.1-main.log

2015-08-03 08:08:44 IST::@:[5542]:LOG:  restored log file "0000000100000001000000CC" from archive
2015-08-03 08:11:44 IST::@:[5542]:LOG:  could not open file "pg_xlog/0000000100000001000000CD" (log file 1, segment 205): No such file or directory
2015-08-03 08:11:44 IST::@:[5542]:LOG:  redo done at 1/CC001E10
2015-08-03 08:11:44 IST::@:[5542]:LOG:  last completed transaction was at log time 2015-08-03 07:59:58.121908+05:30
2015-08-03 08:11:44 IST::@:[5542]:LOG:  restored log file "0000000100000001000000CC" from archive
2015-08-03 08:17:44 IST::@:[5542]:LOG:  selected new timeline ID: 2
2015-08-03 08:23:45 IST::@:[5542]:LOG:  archive recovery complete
2015-08-03 08:23:51 IST::@:[6088]:LOG:  autovacuum launcher started
2015-08-03 08:23:51 IST::@:[5541]:LOG:  database system is ready to accept connections

Todo o processo de procurar dois arquivos de histórico 00000002.historye 00000001.history, 4 vezes e finalmente iniciar o banco de dados levou aproximadamente 12 minutos. Em seguida, cada iteração repetida restaurando um backup de base fresco levou mais tempo, pois começou a procurar por mais arquivos .history.

Como posso tornar isso mais rápido para procurar arquivos de histórico e, se não estiverem presentes, proceder rapidamente para iniciar o banco de dados no modo de leitura/gravação? Caso contrário, não procure arquivos de histórico.

postgresql-9.1 recovery

1 respostas

  1. Best Answer

    Isso não é culpa dos arquivos de histórico.

    Citando o link da documentação que você mencionou:

    Normalmente, a recuperação prosseguirá por todos os segmentos WAL disponíveis, restaurando assim o banco de dados para o momento atual (ou o mais próximo possível, dados os segmentos WAL disponíveis). Portanto, uma recuperação normal terminará com uma mensagem "arquivo não encontrado", o texto exato da mensagem de erro dependendo de sua escolha de restore_command. Você também pode ver uma mensagem de erro no início da recuperação de um arquivo chamado algo como 00000001.history. Isso também é normal e não indica problema em situações simples de recuperação; consulte a Seção 24.3.4 para discussão

    Como parece que você está usando o pg_standby, você tem algumas opções.

    1. Ajuste -r maxretriese -s sleeptime.

      Por padrão -r maxretriesé 3 e, como parece que você tem a -s sleeptimeconfiguração definida como 60, ele aguardará 60 segundos na primeira tentativa, 120 segundos na segunda tentativa e 180 segundos na terceira e última tentativa do comando de cópia antes ele desiste e coloca o servidor de réplica no modo autônomo.

      Assim, além de reproduzir todos os logs, ao final, quando o comando está tentando copiar os arquivos .history, você está esperando um total geral de 360 ​​segundos, ou seis minutos, mais o tempo que leva para restaurar todo o seu WAL segmentos no modo inteligente.

    2. Faça um failover rápido em vez de um failover inteligente.

      Se você está desesperado para fazer o failover rapidamente e pode suportar a perda de qualquer segmento WAL não aplicado, você pode fazer um failover rápido em vez do failover inteligente que está acionando, conforme mencionado na documentação do pg_standby aqui .

      Os méritos do failover inteligente versus failover rápido dependem de quão rápido você deseja que seu servidor de réplica funcione e quanta tolerância você tem para transações perdidas.

      Failover rápido ignora segmentos WAL não aplicados e, como tal, as transações são perdidas. O failover inteligente reproduz todos os segmentos WAL possíveis antes de ativar a réplica no modo autônomo. Isso pode levar muito tempo, dependendo de quantos segmentos WAL você precisa reproduzir.

    Por fim, como você está no 9.1, pode usar a replicação de streaming junto com um restore_commandem seu recovery.confpara manter o servidor ainda mais atualizado do que o envio de log padrão, fazendo streaming de registros WAL individuais à medida que são produzidos.

    Além disso, se a réplica não conseguir acompanhar a carga de streaming (devido a problemas de rede ou qualquer outra coisa), ela pode usar um restore_commandpara pegar segmentos WAL do arquivo que você já configurou.

    Você não pode usar pg_standbypara o restore_command embora.

    Em teoria, como há pouco ou nenhum atraso na restauração de registros WAL se tudo estiver indo bem, em vez de restaurar segmentos WAL completos, sua réplica deve aparecer no modo autônomo muito mais rápido.

    Um exemplo de replicação de streaming mais arquivamento em ação pode ser encontrado aqui:

    http://evol-monkey.blogspot.com/2014/09/offsite-replication-problems-and-how-to.html

    Também é útil monitorar seu atraso de replicação para garantir que tudo esteja tão atualizado quanto seus requisitos. Exemplos disso estão aqui:

    http://www.keithf4.com/monitoring_streaming_slave_lag/

    Espero que ajude. =)

    • 1

relate perguntas