Réplica síncrona en Postgres y conmutación automática II

Hola a tod@s, hoy queríamos retomar el tema de la réplica síncrona en PostgreSQL 10 y enseñaros como se puede realizar una conmutación de servidores.

La conmutación consiste en cambiar los roles entre el servidor primario y el de standby. En la entrada anterior dejamos configurada la conmutación automática en caso de fallo, pero si queremos realizarla de forma manual y controlada lo podemos hacer con los pasos que os explicamos hoy.

En la entrada anterior teníamos la siguiente configuración:

Réplica síncrona

El estado es:

  •                 pos1. Servidor primario
  •                 pos2. Servidor de standby recibiendo datos de pos1 (upstream).
  •                 pos-wit. Servidor de witness.

Realizar conmutación en réplica síncrona

Para realizar la conmutación nos conectamos al servidor que queremos que sea el nuevo primario, en este caso pos2 y ejecutamos:

repmgr --dry-run -h pos2 standby switchover --siblings-follow

Este comando revisará el estado de los nodos del cluster y nos informará si la conmutación de nodos es posible pero sin llegar a hacerla. Los parámetros que utilizamos son:

  • dry-run. Revisa los prerequisitos pero no se realiza la conmutación.
  • standby switchover. Convierte la base de datos standby en primaria y la primaria en standby de forma controlada.
  • siblings-follow. Si hay mas standbys conectadas al antiguo nodo primario hace que apunten al nuevo primario. También cambia la configuración del nodo de witness.

La salida del comando tiene que ser algo similar a esto:

[root@pos2 ~]# su - postgres -c 'repmgr --dry-run standby switchover --siblings-follow'
 NOTICE: checking switchover on node "pos2" (ID: 102) in --dry-run mode
 INFO: SSH connection to host "pos1" succeeded
 INFO: able to execute "repmgr" on remote host "pos1"
 INFO: all sibling nodes are reachable via SSH
 INFO: 3 walsenders required, 10 available
 INFO: demotion candidate is able to make replication connection to promotion candidate
 INFO: 7 pending archive files
 INFO: replication lag on this standby is 0 seconds
 INFO: would pause repmgrd on node "pos1" (ID 101)
 INFO: would pause repmgrd on node "pos2" (ID 102)
 INFO: would pause repmgrd on node "pos-wit" (ID 103)
 NOTICE: local node "pos2" (ID: 102) would be promoted to primary; current primary "pos1" (ID: 101) would be demoted to standby
 INFO: following shutdown command would be run on node "pos1":
   "sudo systemctl stop postgresql-10.service"
 INFO: parameter "shutdown_check_timeout" is set to 60 seconds
 INFO: prerequisites for executing STANDBY SWITCHOVER are met 

Cuando hemos comprobado que todo ha sido correcto podemos lanzar la conmutación real:

[root@pos2 ~]# su - postgres -c 'repmgr standby switchover --siblings-follow'
 NOTICE: executing switchover on node "pos2" (ID: 102)
 NOTICE: local node "pos2" (ID: 102) will be promoted to primary; current primary "pos1" (ID: 101) will be demoted to standby
 NOTICE: stopping current primary node "pos1" (ID: 101)
 NOTICE: issuing CHECKPOINT on node "pos1" (ID: 101)
 DETAIL: executing server command "sudo systemctl stop postgresql-10.service"
 INFO: checking for primary shutdown; 1 of 60 attempts ("shutdown_check_timeout")
 NOTICE: current primary has been cleanly shut down at location 0/7000028
 NOTICE: promoting standby to primary
 DETAIL: promoting server "pos2" (ID: 102) using "/usr/pgsql-10/bin/pg_ctl  -w -D '/opt/postgres' promote"
 waiting for server to promote..... done
 server promoted
 NOTICE: waiting up to 60 seconds (parameter "promote_check_timeout") for promotion to complete
 NOTICE: STANDBY PROMOTE successful
 DETAIL: server "pos2" (ID: 102) was successfully promoted to primary
 INFO: local node 101 can attach to rejoin target node 102
 DETAIL: local node's recovery point: 0/7000028; rejoin target node's fork point: 0/7000098
 NOTICE: setting node 101's upstream to node 102
 WARNING: unable to ping "host=pos1 dbname=repmgr user=repmgr"
 DETAIL: PQping() returned "PQPING_NO_RESPONSE"
 NOTICE: starting server using "sudo systemctl start postgresql-10.service"
 NOTICE: NODE REJOIN successful
 DETAIL: node 101 is now attached to node 102
 INFO: waiting for node "pos1" (ID: 101) to connect to new primary; 1 of max 60 attempts (parameter "node_rejoin_timeout")
 DETAIL: checking for record in node "pos2"'s "pg_stat_replication" table where "application_name" is "pos1"
 NOTICE: node  "pos2" (ID: 102) promoted to primary, node "pos1" (ID: 101) demoted to standby
 NOTICE: executing STANDBY FOLLOW on 2 of 2 siblings
 INFO:  node 103 received notification to follow node 102
 INFO: STANDBY FOLLOW successfully executed on all reachable sibling nodes
 NOTICE: switchover was successful
 DETAIL: node "pos2" is now primary and node "pos1" is attached as standby
 NOTICE: STANDBY SWITCHOVER has completed successfully 

Al revisar la configuración del cluster desde el nodo de witness podemos comprobar la nueva configuración:

Réplica síncrona PostgreSQL

La operativa nos puede ser muy útil si por ejemplo necesitamos realizar labores de mantenimiento en uno de los nodos, ya que nos permite seguir dando servicio desde otro de los nodos sin problema. Una vez que hemos finalizado, si queremos dejar la configuración inicial simplemente tenemos que lanzar los mismos comandos desde el nodo1:

[root@pos1 ~]# su - postgres -c 'repmgr --dry-run standby switchover --siblings-follow' 
[root@pos1 ~]# su - postgres -c 'repmgr standby switchover --siblings-follow' 

Esperamos que la entrada de hoy os sea de utilidad y podáis utilizarla para dotar de mayor disponibilidad vuestras bases de datos PostgreSQL.

Un saludo.

¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.

Sígue a GPS en LinkedIn

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *