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 <jaime.so...@gmail.com> > *Enviado:* jueves, 11 de noviembre de 2021 06:07 > *Para:* Rodrigo Emmanuel Cordero <rodrigo.cord...@hotmail.es> > *Cc:* pgsql-es-ay...@postgresql.org <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 <jaime.so...@gmail.com> > *Enviado:* miércoles, 10 de noviembre de 2021 08:21 > *Para:* Rodrigo Emmanuel Cordero <rodrigo.cord...@hotmail.es> > *Cc:* Jaime Casanova <jcasa...@systemguards.com.ec>; > pgsql-es-ay...@postgresql.org <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 <jcasa...@systemguards.com.ec> > *Sent:* Tuesday, November 9, 2021 7:40:35 PM > *To:* Rodrigo Emmanuel Cordero <rodrigo.cord...@hotmail.es> > *Cc:* pgsql-es-ay...@postgresql.org <pgsql-es-ay...@postgresql.org> > *Subject:* Re: Consulta sobre nodos master y replicas > > On Tue, Nov 09, 2021 at 06:52:42PM +0000, 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 > >