Instalación de Bases de Datos¶
Casi todo problema grave de base de datos en producción nace en la instalación: almacenamiento equivocado, memoria mal distribuida, réplicas en el mismo host físico, ninguna prueba de fallo antes del primer cliente. Corregirlo después cuesta una ventana de mantenimiento; acertar antes cuesta una conversación.
Esta página describe cómo InteSys instala una base nueva — desde el dimensionamiento hasta la entrega documentada.
Ninguna etapa se omite, ni siquiera en un clúster pequeño — lo que cambia es el tamaño, no el procedimiento.
1. Dimensionamiento¶
Dimensionar no es elegir un plan; es responder cinco preguntas.
| Pregunta | Por qué decide la máquina |
|---|---|
| ¿Cuántos datos hay hoy y cuál es la proyección a 24 meses? | Define el disco y, sobre todo, cuánto del conjunto activo cabe en RAM |
| ¿Cuál es la proporción entre lectura y escritura? | La carga de lectura escala con réplicas; la escritura escala con hardware y esquema |
| ¿Cuál es el pico de conexiones simultáneas? | Determina el pool y evita que la base muera de too many connections |
| ¿Cuál es la transacción más grande y la consulta analítica más pesada? | Define la memoria de trabajo y el riesgo de que una consulta tumbe el servidor |
| ¿Qué RPO y RTO acepta el negocio? | Define el modo de replicación y la política de copias |
Regla práctica de memoria — el conjunto de datos caliente debe caber en la caché de la base (buffer pool en MySQL, shared buffers más caché del sistema operativo en PostgreSQL). Cuando no cabe, cada consulta se convierte en I/O y ningún ajuste de parámetros lo salva.
El almacenamiento es donde más se falla
Las bases de datos son sensibles a la latencia de I/O, no al throughput bruto del disco. Un volumen con buen MB/s y mala latencia rinde peor que un disco más pequeño y más rápido. Toda instalación de InteSys mide la latencia de escritura y las IOPS del volumen antes de levantar la base.
2. Topología¶
La decisión previa a cualquier instalación: Kubernetes o máquinas virtuales.
| Criterio | Kubernetes | Máquinas virtuales |
|---|---|---|
| Aprovisionamiento de un clúster nuevo | Minutos, declarativo | Automatizado, pero más lento |
| Reconstrucción de réplica | Automática, por el operador | Automatizada con scripts |
| Ajuste fino de kernel, planificador de I/O y huge pages | Limitado por el nodo | Total |
| Familiaridad del equipo del cliente | Exige cultura Kubernetes | Operación tradicional |
| Elíjalo cuando | La aplicación ya corre en Kubernetes | La base es el componente más crítico y aislado |
Los detalles de cada arreglo están en las guías de alta disponibilidad: MySQL, PostgreSQL, ClickHouse.
Número de nodos — la instalación estándar tiene tres nodos de base (o tres votantes, cuando el consenso es externo). Dos nodos no forman quórum y convierten cualquier partición de red en una decisión manual.
3. Aprovisionamiento¶
Nada se instala a mano.
- Infraestructura como Código — Terraform para los recursos, Ansible o un operador Kubernetes para la base. El clúster es reproducible desde el repositorio.
- Anti-affinity obligatoria — un nodo de base por host físico. Tres réplicas en el mismo hipervisor no son alta disponibilidad, son el mismo punto único de fallo copiado tres veces.
- Volúmenes dedicados — datos, log de transacciones y sistema operativo en volúmenes separados, con el log de transacciones en almacenamiento de baja latencia.
- Versión fijada — versión mayor y menor declaradas explícitamente; la actualización es un evento planificado, nunca un efecto colateral de un
restart.
# Fragmento ilustrativo de manifiesto — la topología se declara, no se teclea en el servidor
spec:
instances: 3
postgresql:
parameters:
shared_buffers: "8GB"
max_connections: "200"
storage:
size: 500Gi
storageClass: fast-nvme
backup:
retentionPolicy: "30d"
4. Hardening¶
Una base recién instalada es un objetivo. El estándar de entrega incluye:
- TLS obligatorio — conexiones de aplicación y de replicación cifradas; certificado gestionado y rotado.
- Sin exposición pública — la base escucha en red privada. El acceso administrativo pasa por bastion o VPN, nunca por un puerto abierto a internet.
- Cuentas mínimas — usuario de aplicación con privilegios de datos, sin
SUPER/SUPERUSER; cuentas administrativas separadas y nominales. - Contraseñas fuera del código — credenciales en un Kubernetes Secret o una bóveda, inyectadas por variable de entorno.
- Network policy / firewall — solo los orígenes previstos alcanzan el puerto de la base.
- Auditoría de conexión — registro de quién conectó, desde dónde y cuándo.
- Cifrado en reposo — volúmenes cifrados, incluidos los usados por snapshot.
5. Validación antes del go-live¶
Un clúster solo se entrega después de probar que funciona bajo estrés y bajo fallo.
- Prueba de carga — carga sintética con el perfil real de la aplicación, midiendo latencia p95 y p99, no el promedio.
- Prueba de fallo — tumbamos el primario en un entorno controlado y medimos el RTO real. Si el número no coincide con lo acordado, la topología cambia antes de producción.
- Prueba de restauración — la primera copia se restaura en un servidor limpio y se verifica. Una copia nunca restaurada no cuenta.
- Verificación de alertas — cada alerta se dispara artificialmente una vez, para confirmar que llega a quien está de guardia.
Qué se entrega junto¶
| Entregable | Contenido |
|---|---|
| Documento de topología | Nodos, roles, endpoints, versiones y parámetros relevantes |
| Runbook | Failover, reconstrucción de réplica, restauración, escalado |
| Paneles y alertas | Métricas de replicación, conexiones, latencia y espacio en disco |
| Política de copias | Frecuencia, retención, destino y resultado de la última prueba de restauración |
| Credenciales | Entregadas por canal seguro, con cuentas nominales para el equipo del cliente |
Instalación y migración van juntas
Si la base ya existe en otro lugar, la instalación es la primera mitad del trabajo y la migración es la segunda. El clúster nuevo se valida antes de copiar cualquier dato de producción.
Páginas Relacionadas¶
- Migración — Traer la base existente al clúster nuevo
- Replicación — Modos y topologías configurados en la instalación
- Copias de Seguridad y Restauración — La política definida el día uno
- Alta Disponibilidad MySQL · PostgreSQL · ClickHouse
- Centros de Datos InteSys — Dónde se aprovisiona el clúster