Hola,

Elizabeth Fernandez escribió:

> El comando que he utilizado para la creacion de la replica es:
> pg_basebackup -h <master_ip> -p 5432 -D <data directorio>  -U <user> -Fp -P
> -v -R -Xs --checkpoint=fast -C -S <nombre_slot>
> Hasta ahora cuando lo he utilizado ha funcionado. Esta semana traté de
> crear la 2da replica, pero cuando finalizó el pg_basebackup y se ejecutó el
> start de la base de datos, el log indica que requiere hacer el streaming de
> un WAL del servidor primario y el mismo ya fue eliminado.

Hmm, el problem NO es que el WAL haya sido eliminado, porque el archivo
ya está en el pg_wal de la réplica.  El problema es que al leer ese WAL
que estaba en la réplica, ocurrió este error:

> 2024-08-15 06:42:40.087 EDT [127391] LOG:  incorrect resource manager data 
> checksum in record at 53A7/4570AA10

Por alguna razón, el nuevo servidor no está interpretando correctamente
el WAL.  ¿Son paquetes de la misma fuente, de la misma versión, en el
mismo sistema operativo?

(El mensaje de que el WAL ya fue eliminado, lo lanza porque una vez que
ocurre la primera falla, el standby no sabe qué más hacer aparte de
pedirle al primario que le envíe el WAL nuevamente; pero eso ya sabemos
que va a fallar, porque el primario no guarda todos esos días de WAL.
La opción -Xs de pg_basebackup se hace cargo de traer todo el WAL desde
el primario y ponerlo en el pg_wal de la réplica, antes de que el
primario lo borre.)

¿Tienes algún módulo o extensión que pudiera estar publicando WAL no
estándar?  Podrías intentar hacer pg_waldump de ese segmento en la
réplica, si es que todavía tienes el archivo.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/


Reply via email to