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/