From: | Martín Marqués <martin(dot)marques(at)gmail(dot)com> |
---|---|
To: | mauricio pullabuestan <jmauriciopb(at)yahoo(dot)es> |
Cc: | Postgres ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: no se pudo recibir datos del cliente: Conexión reinicializada por la máquina remota |
Date: | 2023-12-15 22:13:51 |
Message-ID: | CABeG9Ls5FJ13UkLKoWxHFSC8yTFT4svf=PAXbAG=A42nHRujOQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Buenas,
> Este es parte del log del de dias posteriores
> cp: no se puede efectuar `stat' sobre «/var/lib/postgresql/9.6/main/archive/000000010000198E00000046»: No existe el archivo o el directorio
> 2023-12-11 03:16:21 -05 LOG: iniciando el flujo de WAL desde el primario en 198E/46000000 en el timeline 1
> 2023-12-11 03:16:21 -05 FATAL: no se pudo recibir datos desde el flujo de WAL: ERROR: el segmento de WAL solicitado 000000010000198E00000046 ya ha sido eliminado
El error de `cp` seguramente es un `restore_command` que no puede
copiar un WAL porque ya no esta.
>
> Los archivos wal, se eliminan del servidor primario por medio de una tarea Cron que se ejecuta a 1:00 eliminado los wals del día anterior.
Puedes explicar esto mejor. Que WALs son eliminados? Los que están en
PGDATA/pg_wal o los que se encuentra en un archivo (o sea que fueron
copiados a otro directorio con archive_command)?
Lo que yo veo es que toda esta arquitectura es muy frágil, y tiene
muchos puntos en los que "cosas" pueden fallar.
¿Pensaron en poner un servidor de backups con barman y usar ese para
replicar WALs?
--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
From | Date | Subject | |
---|---|---|---|
Next Message | Juan | 2023-12-16 00:20:20 | Re: no se pudo recibir datos del cliente: Conexión reinicializada por la máquina remota |
Previous Message | mauricio pullabuestan | 2023-12-15 21:09:09 | Re: no se pudo recibir datos del cliente: Conexión reinicializada por la máquina remota |