Início / dba / Perguntas / 297361
Accepted
Aldar
Asked: 2021-07-30 08:27:21 +0800 CST

PostgreSQL 11: encerrando o processo walreceiver devido ao comando do administrador

  • 772

um dos meus servidores PostgreSQL 11 estava lançando um erro estranho e se recusou a iniciar corretamente a replicação de streaming após um backup de base:

FATAL: encerrando o processo walreceiver devido ao comando do administrador

Tentei habilitar o maior detalhamento do log (Debug5), mas isso não forneceu mais informações sobre o motivo pelo qual ele continuava morrendo:

2021-07-29 15:33:30.862 UTC [39315] DEBUG:  postgres: PostmasterMain: initial environment dump:
2021-07-29 15:33:30.862 UTC [39315] DEBUG:  -----------------------------------------
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      PG_OOM_ADJUST_FILE=/proc/self/oom_score_adj
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      PG_GRANDPARENT_PID=39310
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      PGLOCALEDIR=/usr/share/locale
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      PGSYSCONFDIR=/etc/postgresql-common
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      LANG=en_US.UTF-8
2021-07-29 15:33:30.862 UTC [39315] DEBUG:      PWD=/
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      PGDATA=/var/lib/postgresql/11/replica
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_COLLATE=en_US.UTF-8
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_CTYPE=en_US.UTF-8
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_MESSAGES=en_US.UTF-8
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_MONETARY=C
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_NUMERIC=C
2021-07-29 15:33:30.863 UTC [39315] DEBUG:      LC_TIME=C
2021-07-29 15:33:30.863 UTC [39315] DEBUG:  -----------------------------------------
2021-07-29 15:33:30.867 UTC [39315] DEBUG:  registering background worker "logical replication launcher"
2021-07-29 15:33:30.868 UTC [39315] LOG:  listening on IPv6 address "::1", port 5433
2021-07-29 15:33:30.868 UTC [39315] LOG:  listening on IPv4 address "127.0.0.1", port 5433
2021-07-29 15:33:30.868 UTC [39315] LOG:  listening on IPv4 address "*snip*", port 5433
2021-07-29 15:33:30.868 UTC [39315] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5433"
2021-07-29 15:33:30.869 UTC [39315] DEBUG:  invoking IpcMemoryCreate(size=156459008)
2021-07-29 15:33:30.869 UTC [39315] DEBUG:  mmap(157286400) with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory
2021-07-29 15:33:30.885 UTC [39315] DEBUG:  SlruScanDirectory invoking callback on pg_notify/0000
2021-07-29 15:33:30.885 UTC [39315] DEBUG:  removing file "pg_notify/0000"
2021-07-29 15:33:30.885 UTC [39315] DEBUG:  dynamic shared memory system will support 588 segments
2021-07-29 15:33:30.885 UTC [39315] DEBUG:  created dynamic shared memory control segment 1597797971 (14128 bytes)
2021-07-29 15:33:30.887 UTC [39315] DEBUG:  max_safe_fds = 982, usable_fds = 1000, already_open = 8
2021-07-29 15:33:30.889 UTC [39316] LOG:  database system was shut down in recovery at 2021-07-29 15:31:23 UTC
2021-07-29 15:33:30.890 UTC [39316] DEBUG:  standby_mode = 'on'
2021-07-29 15:33:30.890 UTC [39316] DEBUG:  primary_conninfo = '*snip*'
2021-07-29 15:33:30.890 UTC [39316] DEBUG:  recovery_target_timeline = latest
2021-07-29 15:33:30.890 UTC [39316] LOG:  entering standby mode
2021-07-29 15:33:30.890 UTC [39316] LOG:  invalid resource manager ID 172 at 235/450000D0
2021-07-29 15:33:30.890 UTC [39316] DEBUG:  switched WAL source from archive to stream after failure
2021-07-29 15:33:30.891 UTC [39317] DEBUG:  find_in_dynamic_libpath: trying "/usr/lib/postgresql/11/lib/libpqwalreceiver"
2021-07-29 15:33:30.905 UTC [39317] DEBUG:  find_in_dynamic_libpath: trying "/usr/lib/postgresql/11/lib/libpqwalreceiver.so"
2021-07-29 15:33:30.918 UTC [39317] LOG:  started streaming WAL from primary at 235/45000000 on timeline 1
2021-07-29 15:33:30.920 UTC [39317] DEBUG:  sendtime 2021-07-29 15:33:30.917704+00 receipttime 2021-07-29 15:33:30.920718+00 replication apply delay (N/A) transfer latency 3 ms
2021-07-29 15:33:30.920 UTC [39317] DEBUG:  sending write 235/45020000 flush 0/0 apply 0/0
2021-07-29 15:33:30.921 UTC [39317] DEBUG:  sending write 235/45020000 flush 235/45020000 apply 0/0
2021-07-29 15:33:30.921 UTC [39316] LOG:  invalid resource manager ID 172 at 235/450000D0
2021-07-29 15:33:30.921 UTC [39317] FATAL:  terminating walreceiver process due to administrator command
2021-07-29 15:33:30.921 UTC [39317] DEBUG:  shmem_exit(1): 1 before_shmem_exit callbacks to make
2021-07-29 15:33:30.921 UTC [39317] DEBUG:  shmem_exit(1): 5 on_shmem_exit callbacks to make
2021-07-29 15:33:30.921 UTC [39317] DEBUG:  proc_exit(1): 2 callbacks to make
2021-07-29 15:33:30.921 UTC [39317] DEBUG:  exit(1)
2021-07-29 15:33:30.921 UTC [39316] DEBUG:  switched WAL source from stream to archive after failure

A única preocupação foram as mensagens de nível LOG como

LOG: ID do gerenciador de recursos inválido 172 em 235/450000D0

Descobriu-se, no entanto, que estas são apenas a maneira do Postgres de dizer "Chegou ao fim das estruturas WAL válidas" e as mensagens de nível de LOG podem ser ignoradas com segurança.

Eu tentei remover os logs WAL existentes (de datadir/pg_wal/), pensando que talvez uma corrupção de arquivo estivesse em jogo, o servidor ainda não iniciaria a replicação. A única solução foi fazer um backup de base completamente novo.

Minha pergunta - é terminating xyz process due to administrator commanduma mensagem padrão que o Postgres fornece quando um de seus processos morre de maneira não padrão?

Haveria mais opções de depuração em casos como este? Nem mesmo o mais alto detalhamento de log forneceu muita informação útil.

postgresql postgresql-11

1 respostas

  1. Best Answer

    Qual é a versão completa do PostgreSQL no mestre e na réplica?

    Parece que provavelmente foi corrupção, e fazer um novo backup básico é tudo o que você pode fazer (e investigar seu hardware, para ver se consegue descobrir por que houve corrupção).

    Suponho que você removeu o WAL da réplica, não do mestre. Portanto, ele buscaria novamente os mesmos arquivos WAL e os descobriria ainda corrompidos. Não precisava ser assim, mas presumivelmente era ou você não estaria fazendo a pergunta. Se a corrupção tiver sido falhas de rede que aconteceram com os arquivos em trânsito, a nova cópia pode ser boa, mas aparentemente a corrupção existe nos arquivos WAL originais no mestre e, portanto, ainda está corrompida, não importa quantas vezes você a leia. Além disso, se a corrupção ocorreu apenas no disco quando o arquivo WAL original foi gravado no disco, o arquivo pode não estar corrompido. Se o comando archive copiando o arquivo WAL para o archive retirasse os dados do cache do sistema de arquivos na RAM, a cópia não seria corrompida. Então, ou a corrupção aconteceu na própria RAM, ou o comando archive teve que ler os dados (agora corrompidos) de volta do disco para copiá-los para o arquivo. Ou aconteceu ainda mais cedo, como um bug de software.

    Não há informações adicionais a serem obtidas. O sistema não consegue descobrir o que está vendo, então tudo o que pode fazer é vomitar a bagunça para que possamos especular. Mas sim, ele comandou o receptor wal para sair, não há sentido em mantê-lo funcionando, pois não pode reproduzir além do ponto da corrupção. Então, ele está voltando para o arquivo WAL, para ver se por acaso o arquivo não está corrompido.

    • 1

relate perguntas