Distributed Topology
Este es el último blog de esta serie que hemos querido acometer para explicar las diferentes configuraciones que introdujimos en el primer blog “CloudNativePG – Replica Cluster – I”. En este blog realizaremos una configuración sencilla de un cluster en la configuración denominada: Distributed Topology.
Con esta configuración, CloudNativePG puede controlar de forma declarativa la degradación de un clúster principal (demotion) y la posterior promoción (promotion) de un clúster de réplica mediante un token de promoción. De esta manera sencilla podemos conseguir hacer una “promoción” controlada entre dos cluster diferentes.
Ejemplo práctico
1. Creamos el cluster principal
Este cluster se replicará vía streaming-replication con otro cluster secundario (lo habitual sería hacerlo vía barmanObjectStore, pero no queremos añadir complejidad al ejemplo).
2. Creamos el cluster con Distributed Topology
Ahora verificamos que la replicación entre los dos cluster está activa y funcionando.
En este momento, podríamos realizar un “switchover” controlado entre los dos cluster. Para ello realizamos los siguientes pasos:
3. Verificamos que el cluster DR (secundario) está en modo lectura
4. Realizamos el demotion del cluster principal
Esto degrada el cluster principal a un cluster réplica (read-only) y el cluster-DR se promueve a cluster primario:
- cluster-dt-principal ==> se convierte en réplica cluster
- cluster-dt-dr ==> se convierte en el nuevo cluster primario
5. Editamos el archivo cluster-dt-principal.yaml
Modificamos el campo replica=<clustername> con el cluster que se convertirá en el nuevo primario.
6. Aplicamos los cambios al cluster-dt-principal
En este momento, el cluster principal se queda en modo READ-ONLY y genera el demotionToken (JSON codificado en base64).
7. Verificamos que el cluster-dt-principal ahora está en modo read-only
8. Obtenemos la información del demotionToken del cluster antiguo
9. Realizamos el promote del cluster-dt-dr como nuevo Primary Cluster
Verificamos que el cluster-dt-dr sigue en modo read-only.
Modificamos el cluster-dt-dr para que se convierta en el nuevo cluster primario y cambiamos la etiqueta primary con el nombre del nuevo primario (en este caso el DR) y añadimos el promotionToken.
10. Configuramos el cluster aplicando los cambios en el manifiesto
Una vez aplicados los cambios, verificamos que se ha realizado el switchover entre ambos datacenters. Comprobaremos que ahora en el cluster DR se permite escribir datos.
Verificamos que el cluster-dt-principal ahora es réplica-cluster del cluster-dt-replica y que está en modo lectura.
Conclusiones
Como se puede comprobar, este tipo de arquitectura puede ser de mucha utilidad en entornos que queramos tener alta disponibilidad (HA) en múltiples datacenters (separados geográficamente, por ejemplo) y disponer de cierta manera un control de cuándo realizar un cambio de datacenter de una forma segura.
