Re: BUG #17177: Secondary fails to start after upgrade from 13.3

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: BUG #17177: Secondary fails to start after upgrade from 13.3
Дата
Msg-id 20210903.203411.1305461729557740222.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на BUG #17177: Secondary fails to start after upgrade from 13.3  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #17177: Secondary fails to start after upgrade from 13.3  (Andriy Bartash <Andriy.Bartash@everbridge.com>)
Список pgsql-bugs
At Fri, 03 Sep 2021 00:31:49 +0000, PG Bug reporting form <noreply@postgresql.org> wrote in 
> ted timeline ID 2 in log segment
> 00000002000053E8000000E7, offset 4956160
> 2021-09-02 17:47:03.136 UTC [18068] (user=) (db=) (rhost=) (app=) [vxid:
> txid:0] [] LOG:  unexpected timeline ID 2 in log segment
> 00000002000053E8000000E7, offset 5890048
> 2021-09-02 17:47:03.137 UTC [18171] (user=) (db=) (rhost=) (app=) [vxid:
> txid:0] [] FATAL:  terminating walreceiver process due to administrator
> command
> Cluster is not starting.
> Tried to replace 00000002000053E8000000E7 from primary manually but it
> didn't help.
> Once downgraded postgres to 13.3, cluster started successfully in standby
> mode.
> -----------------------------------------------------
> pg_controldata output:
> -----------------------------------------------------
> pg_controldata -D /pgsql/cluster/data/
> pg_control version number:            1300
> Catalog version number:               202007201
> Database system identifier:           6942522466342357095
> Database cluster state:               in archive recovery
> pg_control last modified:             Fri 03 Sep 2021 12:28:17 AM UTC
> Latest checkpoint location:           53FC/37E028B8
> Latest checkpoint's REDO WAL file:    00000002000053FB000000FA
> Latest checkpoint's TimeLineID:       2
> Latest checkpoint's PrevTimeLineID:   2

(The file at failure is before the REDO location, but it seems because
the controldata is taken after the successful startup.)

If 0826564292156762d32c183c6708c94564fcad1c is the cause, one
possibility is that:

- You removed all WAL files before starting the standby but left
  history files alone.

- The standby has a history file for more than tli = 2 and that file
  does not contain tli = 2.

With the two above conditions, no error printed before the commit but
the same error message is printed after the commit.

Is the above conditions match your environment? If so, that would be
fixed by removing the extra history (that is, history files for TLI >
2) files.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-bugs по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17179: EOF detected
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17178: probes.h: No such file or directory when running 'make install'