Re: Dudas sobre archive_command y Streaming Replication

Buenos días,

El mar, 5 oct 2021 a las 20:24, Jaime Casanova (<
jcasanov(at)systemguards(dot)com(dot)ec>) escribió:

> On Tue, Oct 05, 2021 at 03:02:45PM +0200, Ekaterina Amez wrote:
> >
>
> Saludos,
>
> > El resumen podría ser que para establecer una réplica física no hace
> falta
> > definir los parámetros archive_mode y archive_command si ya has tenido en
> > cuenta la cantidad de WAL que se mantiene en la carpeta pg_xlog/pg_wal:
>
> Ese parece un buen resumen, sólo un detalle yo diría que para establecer
> una réplica física "vía streaming replication" no necesitas esos
> parámetros.
>
> Es completamente posible establecer una réplica física vía wal-shipping,
> que actualmente no creo que sea muy común en algunos casos especiales
> puede ser útil. Y en esos casos eso parámetros pueden resultar
> necesarios.
>
> Pero el uso más frecuente para esos parámetros es para backups
> incrementales.
>
> > bien porque es una instancia con poco tráfico, o bien porque se ha
> > configurado wal_keep_segments, o bien porque se utilizan slots de
> > replicación (esto último todavía no sé muy bien cómo se configura).
> >
>
> si usas una réplica física vía streaming usar slots de replicación es la
> única forma de asegurar que no se va a perder un WAL que la réplica
> necesite. Tu puedes creer que ya tienes asegurado el tema por que fuiste
> generosa al calcular el número de WALS/hora pero considera escenarios
> como que la réplica se caiga y deje de replicar por más tiempo del
> esperado, una falla de red o de energía. Con la falla global de
> servicios de ayer debería haber quedado claro que ninguna seguridad es
> paranoia...
>
>
Ya he estado mirando un poco los slots de replicación pero los hemos
descartado por el riesgo, aunque sea mínimo con una monitorización y
control adecuados, de bloquear el servidor primario en caso de problemas
con el secundario. Podemos asumir la pérdida y recreación de las instancias
secundarias en caso de tener problemas.

PD: por favor, no hagan top-posting (escribir encima del mensaje
> original), dificulta leer la historia del mensaje
> --
>
Jaime Casanova
> Director de Servicios Profesionales
> SystemGuards - Consultores de PostgreSQL
>