Si ya estamos familiarizados con CNP y llevamos trabajando con \u00e9l alg\u00fan tiempo seguramente se habr\u00e1 encontrado con la necesidad de ampliar la capacidad de su arquitectura.<\/p>\n\n\n\n
Escenario de despliegue y r\u00e9plica entre datacenters<\/h2>\n\n\n\n
Supongamos que ya tienen desplegado un cluster de Postgresql gestionado por el operador CNP en un datacenter (A) y por necesidades de su infraestructura (seguridad, disponibilidad, etc…) quiere ampliar su capacidad y dotar de una r\u00e9plica en otro datacenter (B).<\/p>\n\n\n\n CNP usa el concepto de Replica Cluster que se puede usar principalmente para dos tipos de situaciones:<\/p>\n\n\n\n B\u00e1sicamente la diferencia entre las dos configuraciones es c\u00f3mo se realiza la conmutaci\u00f3n entre los cluster de CNP y c\u00f3mo es el procedimiento de recuperaci\u00f3n del entorno. Aunque el procedimiento de conmutaci\u00f3n entre cluster no es autom\u00e1tico, su implementaci\u00f3n es muy sencilla, con lo que este tipo de configuraciones nos puede dotar a nuestra infraestructura de una gran capacidad de recuperaci\u00f3n y, sobre todo, de seguridad ante posibles desastres.<\/p>\n\n\n\n El uso de CNP nos puede ayudar a gestionar nuestros cluster de postgresql en k8s y ampliar nuestra capacidad a nivel de seguridad, DR y alta disponibilidad mediante el uso o configuraci\u00f3n de la arquitectura \u00abStandalone Replica Cluster\u00bb o \u00abDistributed Topology\u00bb.<\/p>\n\n\n\n En el siguiente post, realizaremos una explicaci\u00f3n pr\u00e1ctica de c\u00f3mo implementar y configurar una configuraci\u00f3n \u00abStandalone Replica Cluster<\/a>\u00bb o \u00abDistributed Topology<\/a>\u00ab.<\/p>","protected":false},"excerpt":{"rendered":" Con la aparici\u00f3n de Kubernetes y los operadores, nos han simplificado muchas de nuestras tareas del d\u00eda a d\u00eda. Gesti\u00f3n de clusters de PostgreSQL en k8s con CloudNativePG En el caso de la gesti\u00f3n de clusters de postgresql en k8s, el operador CloudNativePG (CNP) es un gran aliado. Aconsejamos leer uno de nuestros post sobre […]<\/p>\n","protected":false},"author":3,"featured_media":14331,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[284],"tags":[310,244,312,177,311],"class_list":["post-14270","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-postgresql","tag-cloudnativepg","tag-cluster","tag-k8s","tag-postgresql","tag-replicacluster"],"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/hopla.tech\/wp-content\/uploads\/2025\/04\/1.png\")
Tipos de Replica Cluster en CloudNativePG<\/h2>\n\n\n\n
Standalone Replica Cluster (Read\u2011Only Workloads)<\/h3>\n\n\n\n
\n
Distributed Topology (Disaster Recovery (DR) y Alta disponibilidad (HA) )<\/h3>\n\n\n\n
\n
Procedimiento de conmutaci\u00f3n y recuperaci\u00f3n<\/h2>\n\n\n\n
Conclusiones<\/h2>\n\n\n\n