Re: Consulta sobre nodos master y replicas
Buenas, El jue, 11 nov 2021 a las 11:56, Rodrigo Emmanuel Cordero (< rodrigo.cord...@hotmail.es>) escribió: > Buen día Jaime, muchísimas gracias. > En el día de ayer luego de que me comentaras lo del health, y verificando > la documentación que me pasaste pude identificar cual es el problema. > Cuando solo tenes un nodo activo, el mismo queda como master (leader) > > > > Del lado del haproxy hay un httpchk que identifica según el endpoint si el > mismo está disponible para "master" o bien como "replica" > > > > Lo que hace el haproxy es balancear entre un master y una replica como > contingencia en caso que uno no quede disponible y además para balancear la > lectura a la base de datos, lo cierto es que cuando tenes un cluster de dos > nodos uno es de lectura y escritura y el otro es solo de lectura. > En la configuración actual tienes 3 servidores de base de datos ( 172.16.109.231,172.16.109.232 y 172.16.109.233) escuchando en el puerto 6432. > Si cambias este check en el binding de réplica por "master" va a retornar > 200 y por ende va a dejar disponible el puerto 5001 para su conexión. > Esto no le veo sentido alguno, me refiero a que cada puerto tiene una finalidad específica. 5000 te redirige al master que quede vivo y 5001 a las réplicas que aún sobrevivan. Y de ahí, tu aplicación usará lo el 5000 si sólo configura 1 datasource o si está preparada para balancear lecturas, entonces podrás usar un segundo datasource al puerto 5001, bueno como posible opción. De esta manera tanto el puerto 5000 y 5001 quedan activos. > Para que quede un solo nodo activo con los dos puertos escuchando, el > option httpchk del listener de replicas tiene que ser cambiado por master. > Yo usaría para el listen replicas el healthcheck /replica . > > > > Siendo esta la solución, entiendo que es recomendable tener un clúster de > 3 o más nodos, simplemente por esto. Porque de tener un clúster de dos > nodos hay más posibilidades que se dispare una alarma de conectividad con > el puerto de lectura en el caso que uno no quede disponible. > En tu caso si sólo tienes 2 instancias de base de datos, convendría que borrases la línea del servidor que no existe. Aunque generalmente Patroni si lo montas con replicación síncrona, entonces uses 3 servidores de base de datos, todo depende de los requisitos de HA, carga y balanceo de carga ... > > Muchísimas gracias nuevamente Jaime, pronto les estaré consultando por > otro tema que tenemos en el clúster ya que necesito identificar de donde > proviene y como resolver un lag que estamos teniendo. > > Saludos, > > > Rodrigo Cordero > > -- > *De:* Jaime Soler > *Enviado:* jueves, 11 de noviembre de 2021 06:07 > *Para:* Rodrigo Emmanuel Cordero > *Cc:* pgsql-es-ay...@postgresql.org > *Asunto:* Re: Consulta sobre nodos master y replicas > > Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre > ambos es, a la hora de asignarte un servidor por defecto, es el número de > chequeos correctos que tienen que devolver el api-rest , > Para el puerto 5000, volverá a considerar un servidor como disponible > después de 4 healthcheck ok's: default-server inter 3s fastinter 1s fall > 3 rise 4 on-marked-down shutdown-sessions > Y 2 healthcheck's ok en el caso del puerto 5001: default-server inter 3s > fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions > La cuestión que creo que debéis de darle una vuelta es saber, cómo > queréis ustedes manejar las conexiones desde el aplicativo, sí siempre van > al master o permite la aplicación balanceo de carga y usen conexiones a > replicas, o replicas con o sin sincronismo... > > Un saludo > > El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero (< > rodrigo.cord...@hotmail.es>) escribió: > > Hola Jaime, muchas gracias por contestar. > Es cierto, utilizamos patroni con el healthcheck, el comportamiento al > pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo. > El problema que estamos teniendo puntualmente es que, cuando solo nos queda > un solo nodo activo el único puerto al que podemos conectarnos es al 5000, > que apunta de igual manera a cada nodo al igual que el puerto 5001. Este > comportamiento es normal o deberíamos poder conectarnos a ambos puertos del > haproxy si solo queda un nodo de postgres activo? > > Muchas gracias, > > Rodrigo Cordero > -- > *De:* Jaime Soler > *Enviado:* miércoles, 10 de noviembre de 2021 08:21 > *Para:* Rodrigo Emmanuel Cordero > *Cc:* Jaime Casanova ; > pgsql-es-ay...@postgresql.org > *Asunto:* Re: Consulta sobre nodos master y replicas > > Creo que lo que estás usando es Patroni, que ofrece la pos
RE: Consulta sobre nodos master y replicas
Buen día Jaime, muchísimas gracias. En el día de ayer luego de que me comentaras lo del health, y verificando la documentación que me pasaste pude identificar cual es el problema. Cuando solo tenes un nodo activo, el mismo queda como master (leader) [cid:8249e855-c12d-44b5-b165-805525bf57c5] Del lado del haproxy hay un httpchk que identifica según el endpoint si el mismo está disponible para "master" o bien como "replica" [cid:2d875205-f17e-476d-9aa2-a0a9baed2407] Lo que hace el haproxy es balancear entre un master y una replica como contingencia en caso que uno no quede disponible y además para balancear la lectura a la base de datos, lo cierto es que cuando tenes un cluster de dos nodos uno es de lectura y escritura y el otro es solo de lectura. Si cambias este check en el binding de réplica por "master" va a retornar 200 y por ende va a dejar disponible el puerto 5001 para su conexión. De esta manera tanto el puerto 5000 y 5001 quedan activos. Para que quede un solo nodo activo con los dos puertos escuchando, el option httpchk del listener de replicas tiene que ser cambiado por master. [cid:f36f76f4-db05-4659-bbf9-ecf96649b5ab] Siendo esta la solución, entiendo que es recomendable tener un clúster de 3 o más nodos, simplemente por esto. Porque de tener un clúster de dos nodos hay más posibilidades que se dispare una alarma de conectividad con el puerto de lectura en el caso que uno no quede disponible. Muchísimas gracias nuevamente Jaime, pronto les estaré consultando por otro tema que tenemos en el clúster ya que necesito identificar de donde proviene y como resolver un lag que estamos teniendo. Saludos, Rodrigo Cordero De: Jaime Soler Enviado: jueves, 11 de noviembre de 2021 06:07 Para: Rodrigo Emmanuel Cordero Cc: pgsql-es-ay...@postgresql.org Asunto: Re: Consulta sobre nodos master y replicas Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre ambos es, a la hora de asignarte un servidor por defecto, es el número de chequeos correctos que tienen que devolver el api-rest , Para el puerto 5000, volverá a considerar un servidor como disponible después de 4 healthcheck ok's: default-server inter 3s fastinter 1s fall 3 rise 4 on-marked-down shutdown-sessions Y 2 healthcheck's ok en el caso del puerto 5001: default-server inter 3s fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions La cuestión que creo que debéis de darle una vuelta es saber, cómo queréis ustedes manejar las conexiones desde el aplicativo, sí siempre van al master o permite la aplicación balanceo de carga y usen conexiones a replicas, o replicas con o sin sincronismo... Un saludo El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero (mailto:rodrigo.cord...@hotmail.es>>) escribió: Hola Jaime, muchas gracias por contestar. Es cierto, utilizamos patroni con el healthcheck, el comportamiento al pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo. El problema que estamos teniendo puntualmente es que, cuando solo nos queda un solo nodo activo el único puerto al que podemos conectarnos es al 5000, que apunta de igual manera a cada nodo al igual que el puerto 5001. Este comportamiento es normal o deberíamos poder conectarnos a ambos puertos del haproxy si solo queda un nodo de postgres activo? Muchas gracias, Rodrigo Cordero De: Jaime Soler mailto:jaime.so...@gmail.com>> Enviado: miércoles, 10 de noviembre de 2021 08:21 Para: Rodrigo Emmanuel Cordero mailto:rodrigo.cord...@hotmail.es>> Cc: Jaime Casanova mailto:jcasa...@systemguards.com.ec>>; pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org> mailto:pgsql-es-ay...@postgresql.org>> Asunto: Re: Consulta sobre nodos master y replicas Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener haproxy como balanceador, usando como healthcheck la api rest que expone patroni en el puerto 8008. El api rest, te da acceso a los nodos standby síncronos sobre el método /sync (https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) o los standby asínconos mediante el método /async (https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a cualquiera de los nodos de base de datos que esten vivos. Creo que conviene que revises los endpoints de healcheck que ofrece patroni https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints y adecuar la configuración del haproxy, en función a lo que necesites. Un saludo. El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (mailto:rodrigo.cord...@hotmail.es>>) escribió: Un gusto Jaime, muchas gracias por contestar. Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de configuracion de
Re: Consulta sobre nodos master y replicas
Ambos puertos, 5000 y 5001 se deberían de poder usar. La diferencia entre ambos es, a la hora de asignarte un servidor por defecto, es el número de chequeos correctos que tienen que devolver el api-rest , Para el puerto 5000, volverá a considerar un servidor como disponible después de 4 healthcheck ok's: default-server inter 3s fastinter 1s fall 3 rise 4 on-marked-down shutdown-sessions Y 2 healthcheck's ok en el caso del puerto 5001: default-server inter 3s fastinter 1s fall 3 rise 2 on-marked-down shutdown-sessions La cuestión que creo que debéis de darle una vuelta es saber, cómo queréis ustedes manejar las conexiones desde el aplicativo, sí siempre van al master o permite la aplicación balanceo de carga y usen conexiones a replicas, o replicas con o sin sincronismo... Un saludo El mié, 10 nov 2021 a las 18:42, Rodrigo Emmanuel Cordero (< rodrigo.cord...@hotmail.es>) escribió: > Hola Jaime, muchas gracias por contestar. > Es cierto, utilizamos patroni con el healthcheck, el comportamiento al > pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo. > El problema que estamos teniendo puntualmente es que, cuando solo nos queda > un solo nodo activo el único puerto al que podemos conectarnos es al 5000, > que apunta de igual manera a cada nodo al igual que el puerto 5001. Este > comportamiento es normal o deberíamos poder conectarnos a ambos puertos del > haproxy si solo queda un nodo de postgres activo? > > Muchas gracias, > > Rodrigo Cordero > -- > *De:* Jaime Soler > *Enviado:* miércoles, 10 de noviembre de 2021 08:21 > *Para:* Rodrigo Emmanuel Cordero > *Cc:* Jaime Casanova ; > pgsql-es-ay...@postgresql.org > *Asunto:* Re: Consulta sobre nodos master y replicas > > Creo que lo que estás usando es Patroni, que ofrece la posibilidad de > tener haproxy como balanceador, usando como healthcheck la api rest que > expone patroni en el puerto 8008. > El api rest, te da acceso a los nodos standby síncronos sobre el método > /sync ( > https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 > ) o los standby asínconos mediante el método /async ( > https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 > ) > En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a > cualquiera de los nodos de base de datos que esten vivos. > Creo que conviene que revises los endpoints de healcheck que ofrece > patroni > https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints > y adecuar la configuración del haproxy, en función a lo que necesites. > > Un saludo. > > El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (< > rodrigo.cord...@hotmail.es>) escribió: > > Un gusto Jaime, muchas gracias por contestar. > Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de > configuracion del mismo para que puedas decirme si la configuracion es > correcta. > > Muchas gracias, > > Rodrigo Cordero > > Get Outlook para Android <https://aka.ms/AAb9ysg> > ------ > *From:* Jaime Casanova > *Sent:* Tuesday, November 9, 2021 7:40:35 PM > *To:* Rodrigo Emmanuel Cordero > *Cc:* pgsql-es-ay...@postgresql.org > *Subject:* Re: Consulta sobre nodos master y replicas > > On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote: > > Hola, antes que nada un gusto en saludarlos. > > Estoy teniendo una duda respecto al comportamiento del cluster con tres > nodos de postgres (1 Master / 2 Replicas). > > Cuando el nodo master se apaga, automáticamente uno de los nodos > "replicas" toma el control del master, esto esta bien. > > en realidad, postgres no hace esto de forma automática. probablemente > tienes una aplicación que hace esto. > > > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, > el único puerto al cual es posible conectarse es el 5000, y el 5001 pierde > conexión. > > ¿Este comportamiento es normal? > > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 > activos o esto ocurre solo cuando hay mas de un nodo activo? > > > > y aqui se confirma el hecho de que tienes una aplicación haciendo esto. > esos puertos no los usa postgres para nada. > > Sabes que estas usando para el failover? mi sospechas son haproxy o > pg_auto_failover > > -- > Jaime Casanova > Director de Servicios Profesionales > SystemGuards - Consultores de PostgreSQL > >
RE: Consulta sobre nodos master y replicas
Hola Jaime, muchas gracias por contestar. Es cierto, utilizamos patroni con el healthcheck, el comportamiento al pasar de un nodo a otro es normal pero cuando quedan más de un nodo activo. El problema que estamos teniendo puntualmente es que, cuando solo nos queda un solo nodo activo el único puerto al que podemos conectarnos es al 5000, que apunta de igual manera a cada nodo al igual que el puerto 5001. Este comportamiento es normal o deberíamos poder conectarnos a ambos puertos del haproxy si solo queda un nodo de postgres activo? Muchas gracias, Rodrigo Cordero De: Jaime Soler Enviado: miércoles, 10 de noviembre de 2021 08:21 Para: Rodrigo Emmanuel Cordero Cc: Jaime Casanova ; pgsql-es-ay...@postgresql.org Asunto: Re: Consulta sobre nodos master y replicas Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener haproxy como balanceador, usando como healthcheck la api rest que expone patroni en el puerto 8008. El api rest, te da acceso a los nodos standby síncronos sobre el método /sync (https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) o los standby asínconos mediante el método /async (https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a cualquiera de los nodos de base de datos que esten vivos. Creo que conviene que revises los endpoints de healcheck que ofrece patroni https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints y adecuar la configuración del haproxy, en función a lo que necesites. Un saludo. El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (mailto:rodrigo.cord...@hotmail.es>>) escribió: Un gusto Jaime, muchas gracias por contestar. Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de configuracion del mismo para que puedas decirme si la configuracion es correcta. Muchas gracias, Rodrigo Cordero Get Outlook para Android<https://aka.ms/AAb9ysg> From: Jaime Casanova mailto:jcasa...@systemguards.com.ec>> Sent: Tuesday, November 9, 2021 7:40:35 PM To: Rodrigo Emmanuel Cordero mailto:rodrigo.cord...@hotmail.es>> Cc: pgsql-es-ay...@postgresql.org<mailto:pgsql-es-ay...@postgresql.org> mailto:pgsql-es-ay...@postgresql.org>> Subject: Re: Consulta sobre nodos master y replicas On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote: > Hola, antes que nada un gusto en saludarlos. > Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos > de postgres (1 Master / 2 Replicas). > Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" > toma el control del master, esto esta bien. en realidad, postgres no hace esto de forma automática. probablemente tienes una aplicación que hace esto. > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el > único puerto al cual es posible conectarse es el 5000, y el 5001 pierde > conexión. > ¿Este comportamiento es normal? > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos > o esto ocurre solo cuando hay mas de un nodo activo? > y aqui se confirma el hecho de que tienes una aplicación haciendo esto. esos puertos no los usa postgres para nada. Sabes que estas usando para el failover? mi sospechas son haproxy o pg_auto_failover -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL
Re: Consulta sobre nodos master y replicas
Creo que lo que estás usando es Patroni, que ofrece la posibilidad de tener haproxy como balanceador, usando como healthcheck la api rest que expone patroni en el puerto 8008. El api rest, te da acceso a los nodos standby síncronos sobre el método /sync ( https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) o los standby asínconos mediante el método /async ( https://github.com/zalando/patroni/blob/2f31e88bdc3f933f0c3fffdc6ea67a99a7c378cc/patroni/api.py#L151 ) En tu caso el puerto 5000 y el 5001 va a balancear las peticiones a cualquiera de los nodos de base de datos que esten vivos. Creo que conviene que revises los endpoints de healcheck que ofrece patroni https://patroni.readthedocs.io/en/latest/rest_api.html#health-check-endpoints y adecuar la configuración del haproxy, en función a lo que necesites. Un saludo. El mié, 10 nov 2021 a las 2:22, Rodrigo Emmanuel Cordero (< rodrigo.cord...@hotmail.es>) escribió: > Un gusto Jaime, muchas gracias por contestar. > Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de > configuracion del mismo para que puedas decirme si la configuracion es > correcta. > > Muchas gracias, > > Rodrigo Cordero > > Get Outlook para Android <https://aka.ms/AAb9ysg> > -- > *From:* Jaime Casanova > *Sent:* Tuesday, November 9, 2021 7:40:35 PM > *To:* Rodrigo Emmanuel Cordero > *Cc:* pgsql-es-ay...@postgresql.org > *Subject:* Re: Consulta sobre nodos master y replicas > > On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote: > > Hola, antes que nada un gusto en saludarlos. > > Estoy teniendo una duda respecto al comportamiento del cluster con tres > nodos de postgres (1 Master / 2 Replicas). > > Cuando el nodo master se apaga, automáticamente uno de los nodos > "replicas" toma el control del master, esto esta bien. > > en realidad, postgres no hace esto de forma automática. probablemente > tienes una aplicación que hace esto. > > > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, > el único puerto al cual es posible conectarse es el 5000, y el 5001 pierde > conexión. > > ¿Este comportamiento es normal? > > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 > activos o esto ocurre solo cuando hay mas de un nodo activo? > > > > y aqui se confirma el hecho de que tienes una aplicación haciendo esto. > esos puertos no los usa postgres para nada. > > Sabes que estas usando para el failover? mi sospechas son haproxy o > pg_auto_failover > > -- > Jaime Casanova > Director de Servicios Profesionales > SystemGuards - Consultores de PostgreSQL >
Re: Consulta sobre nodos master y replicas
Un gusto Jaime, muchas gracias por contestar. Disculpas... Efectivamente, hay un haproxy y adjunto el archivo de configuracion del mismo para que puedas decirme si la configuracion es correcta. Muchas gracias, Rodrigo Cordero Get Outlook para Android<https://aka.ms/AAb9ysg> From: Jaime Casanova Sent: Tuesday, November 9, 2021 7:40:35 PM To: Rodrigo Emmanuel Cordero Cc: pgsql-es-ay...@postgresql.org Subject: Re: Consulta sobre nodos master y replicas On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote: > Hola, antes que nada un gusto en saludarlos. > Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos > de postgres (1 Master / 2 Replicas). > Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" > toma el control del master, esto esta bien. en realidad, postgres no hace esto de forma automática. probablemente tienes una aplicación que hace esto. > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el > único puerto al cual es posible conectarse es el 5000, y el 5001 pierde > conexión. > ¿Este comportamiento es normal? > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos > o esto ocurre solo cuando hay mas de un nodo activo? > y aqui se confirma el hecho de que tienes una aplicación haciendo esto. esos puertos no los usa postgres para nada. Sabes que estas usando para el failover? mi sospechas son haproxy o pg_auto_failover -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL haproxy.cfg Description: haproxy.cfg
Re: Consulta sobre nodos master y replicas
On Tue, Nov 09, 2021 at 06:52:42PM +, Rodrigo Emmanuel Cordero wrote: > Hola, antes que nada un gusto en saludarlos. > Estoy teniendo una duda respecto al comportamiento del cluster con tres nodos > de postgres (1 Master / 2 Replicas). > Cuando el nodo master se apaga, automáticamente uno de los nodos "replicas" > toma el control del master, esto esta bien. en realidad, postgres no hace esto de forma automática. probablemente tienes una aplicación que hace esto. > Ahora la duda que tengo actualmente es cuando solo queda un solo nodo, el > único puerto al cual es posible conectarse es el 5000, y el 5001 pierde > conexión. > ¿Este comportamiento es normal? > ¿Teniendo un solo nodo activo, pueden quedar los puertos 5000 y 5001 activos > o esto ocurre solo cuando hay mas de un nodo activo? > y aqui se confirma el hecho de que tienes una aplicación haciendo esto. esos puertos no los usa postgres para nada. Sabes que estas usando para el failover? mi sospechas son haproxy o pg_auto_failover -- Jaime Casanova Director de Servicios Profesionales SystemGuards - Consultores de PostgreSQL
