Clústeres de bases de datos
Algunas bases de datos se ejecutan mejor como un clúster: varios nodos que replican datos y sobreviven al fallo de un nodo. Pier puede desplegar estos clústeres a través de varios servidores en la malla WireGuard, de modo que los nodos residan en hosts diferentes pero aún se alcancen entre sí a través de la superposición privada.
Qué motores admiten clústeres
Sección titulada «Qué motores admiten clústeres»Los clústeres son opcionales por motor, declarados en la plantilla del catálogo. Siete motores los admiten:
| Motor | Topología | Nodos mín. | Nodos máx. |
|---|---|---|---|
| PostgreSQL | Replicación en streaming (1 primario + réplicas de lectura) | 2 | 5 |
| MySQL | Replicación en streaming (1 primario + réplicas de lectura) | 2 | 5 |
| MariaDB | Replicación en streaming (1 primario + réplicas de lectura) | 2 | 5 |
| MongoDB | Conjunto de réplicas con elección automática de primario | 3 | 5 |
| Redis | HA con Sentinel (1 maestro + réplicas + sentinels) | 3 | 5 |
| Cassandra | Anillo gossip con descubrimiento basado en seeds | 2 | 5 |
| ScyllaDB | Anillo gossip (compatible con Cassandra) | 2 | 5 |
El número de nodos por defecto para cada motor en clúster es 3. MongoDB y Redis requieren al menos tres nodos para que funcionen sus elecciones basadas en quórum. Los motores sin una sección de clúster — por ejemplo PostGIS, TimescaleDB, Valkey y ClickHouse — se despliegan como una única instancia independiente.
Servidor único frente a entre servidores
Sección titulada «Servidor único frente a entre servidores»Eliges un clúster al crear el recurso seleccionando el modo de clúster y asignando cada nodo a un servidor:
- Si todos los nodos quedan en un solo servidor, Pier construye un stack de Compose de host único para el clúster.
- Si los nodos se reparten entre varios servidores, Pier despliega un clúster distribuido. Cada servidor de destino debe estar en una malla WireGuard activa, o la solicitud se rechaza — los nodos se alcanzan entre sí por IP de malla y puerto de host publicado.
Cassandra y ScyllaDB tienen una restricción adicional cuando están distribuidos: un nodo por servidor, porque su puerto gossip es fijo y dos nodos en el mismo host colisionarían.
Escalado
Sección titulada «Escalado»Cambia el número total de nodos con POST /api/v1/resources/{id}/scale, pasando el nuevo node_count. Pier lo valida contra los límites mínimo y máximo del motor, regenera el clúster y preserva la ubicación de los nodos existentes. Eliminar un nodo usa la propia ruta de desmantelamiento del motor donde exista — nodetool decommission para Cassandra y ScyllaDB, rs.remove() en el primario para MongoDB.
El balanceo de carga (
/load-balance) es para réplicas de servicios sin estado, no para clústeres de bases de datos. Las bases de datos en clúster se escalan mediante/scale; el endpoint de balanceo de carga rechaza los servicios en modo clúster.
Cableado automático de conexiones
Sección titulada «Cableado automático de conexiones»Inspecciona los nodos de un clúster y sus detalles de conexión con GET /api/v1/resources/{id}/nodes. Para los clústeres distribuidos, Pier ensambla automáticamente la forma de conexión correcta para el motor:
- MongoDB — un URI de conjunto de réplicas que lista la dirección de malla de cada nodo, terminando en
?replicaSet=rs0. - Redis — una configuración de Sentinel: la lista de direcciones de los sentinels más el nombre del conjunto maestro a través del cual se conecta tu cliente.
Otros motores devuelven su lista de nodos sin un URI sintetizado; apuntas tu aplicación al primario (o a los puntos de contacto) según corresponda para ese motor.
Próximos pasos
Sección titulada «Próximos pasos»- Malla WireGuard — la superposición de la que dependen los clústeres distribuidos.
- Servidores y agentes — añade los servidores en los que se ejecutan los nodos de tu clúster.
- Proyectos y servicios — cómo encajan las bases de datos en un proyecto.