Hola Horacio.,
Te comento que finalmente encontramos la solución , y se
debió al parámetro de Postgresql "logical_decoding_work_mem", si bien
suena lógico modificarlo, solo después de un arduo trabajo de empezar a
acotar llegamos que estaba muy bajo y lo aumentamos a 16GB y funcionaron
los consumidores de la replicación sin problemas, te agradezco tu apoyo y
si bien la solución estaba en pg, tus recomendación en el ámbito de
networking ayudaron a mejorar y poner en la mesa varios temas que debemos
abordar.
Atte.,
El mié, 19 abr 2023 a las 0:05, Horacio Miranda (<hmira...@gmail.com>)
escribió:
>
>
> On 19/04/2023, at 2:07 AM, Fernando Monjes <ing.bo...@gmail.com> wrote:
>
> Hola Horacio , gracias por la respuesta y disposición de ayudar , estamos
> revisando con personal de redes lo que mencionas.,
> de igual forma forma me interesa chequear que mi configuración de
> replicación lógica este correcta, vi en este hilo
> PostgreSQL: Re: Retraso de replicación debido al retraso restart_lsn
> <https://www.postgresql.org/message-id/CACG9ogw%2BNaq08%2BosrYxc-6Skbp3QMeQ6aZ2%3DmFcy5HJ1Hr2U0g%40mail.gmail.com>
> que
> "el número máximo de cambios guardados en la memoria por transacción es
> de 4 MB" esto me llama la atención es modificable, se puede aumentar ?
>
> Depende de como estén replicando, pégale una mirada a esto.
>
>
> https://www.migops.com/blog/setting-up-streaming-replication-in-postgresql-13-and-streaming-replication-internals/
>
> Esto debiera decirte como vas con la replicación.
>
> psql -x -c "select * from pg_stat_replication"
>
>
>
>
>
> y dejando el tema de red aun lado, cual seria un tunning de BD correcto
> para soportar este escenario, que al recibir un aumento de carga la
> replicación queda atrasada y no transmite los datos (replicación lógica
> nativa), estoy con Postgresql versión 13.8
>
>
> Quieres que la replicación tenga un delay ? o tu pregunta esta relacionada
> a que esta atrazada y te interesa que este menos trasada ( casí syncronica
> ?)
>
>
>
> Gracias
>
>
>
> El mar, 11 abr 2023 a las 18:34, Horacio Miranda (<hmira...@gmail.com>)
> escribió:
>
>>
>> En Amazon en tu security group activa el ICMP type 3 : type 4 asegúrate
>> que el pmtud funciona. Desde tu máquina onPrem hace un tracepath
>>
>> Si te entiendo bien el problema lo tienes cuando hay muchos datos y algo
>> pasa que deja de funcionar. Si es lo que sospecho en AWS estas con MTU 9000
>> o en tu datacenter y como PMTUD no esta activado por que los ICMP los
>> bloquean los de seguridad hay fragmentación esta fragmentación no es buena
>> en internet sobre todo si paquetes salen con flag DF que es no fragmentar y
>> los servidores terminan configurando un mss mínimo maximo de 536 bytes. Si
>> esto es complicado hay un par de vídeos buenos que explican este tema. En
>> palabras simples hace que tracepath pmtud salga y vas a estar bien
>>
>> Regards,
>> Horacio Miranda
>>
>>
>>
>> > On 12/04/2023, at 9:57 AM, Fernando Monjes <ing.bo...@gmail.com> wrote:
>> >
>> >
>> > Hola Amigos
>> >
>> > Tengo un problema, estoy con una instancia amazon aws donde tengo
>> postgres v13.8 y onpremise un postgres 14.7, tengo configurado una réplica
>> lógica nativa de 4 tablas usando slot plugin pgoutput, usando publicador en
>> aws y subscriptor en onpremise postgres , la bd en aws tiene total de 30
>> tablas , el problema que ocurre es que en un estado de mucha carga a las
>> restantes tablas en aws, la réplica de las 4 tablas del publicador deja de
>> funcionar y no sigue transmitiendo datos, esto hace que crezca el slot,
>> siendo esto otro problema, pero el punto es por que deja de transmitir
>> datos. no se si alguien ha tenido un problema similar
>> >
>> > --
>> > Gracias cualquier aporte
>> >
>> > Fernando Monjes B.
>> > Consultor DBA
>> > Cel: +56 9 7852 1024
>>
>
>
> --
> Atentamente,
>
>
> Fernando Monjes B.
> Consultor DBA
> Ingeniero en Informática
> Cel: 09 -78521024
>
>
>
--
Atentamente,
Fernando Monjes B.
Consultor DBA
Ingeniero en Informática
Cel: 09 -78521024
