Saltar a contenido

Administración de Bases de Datos

Instalar es el día uno. Administrar son todos los demás — y es donde la base deja de ser confiable en silencio: un privilegio concedido "temporalmente" hace dos años, una réplica parada hace tres semanas, un disco al 92%, una versión con CVE conocida, un ALTER TABLE que bloqueó la tabla más grande del sistema en hora pico.

Administración, aquí, es el conjunto de rutinas que impiden cada uno de esos escenarios.

Ciclo de operación diaria: observar, actuar por runbook y registrar todo cambio

Toda acción parte de una señal observada y vuelve como registro. Nada se resuelve solo en la terminal.

Rutinas continuas

Rutina Frecuencia Qué evita
Verificación de replicación y lag Continua, con alerta Réplica parada descubierta en el momento del failover
Verificación de copias y restauración Diaria / mensual Copia corrupta descubierta en el desastre
Revisión de espacio y crecimiento Semanal Disco lleno, que bloquea la escritura y tumba la base
Revisión de consultas lentas Semanal Degradación gradual hasta el incidente
Revisión de usuarios y privilegios Trimestral Acceso acumulado de quien ya no está
Aplicación de parches de seguridad Por ventana planificada Exposición a una vulnerabilidad conocida
Simulacro de failover Semestral Un plan de DR que solo existe en papel

Usuarios y privilegios

El modelo estándar separa tres tipos de cuenta:

  • Cuenta de aplicación — privilegios solo sobre los datos que necesita (SELECT, INSERT, UPDATE, DELETE en su esquema). Sin SUPER, sin SUPERUSER, sin DROP DATABASE.
  • Cuenta administrativa nominal — una por persona, nunca compartida. Es lo que hace útil la auditoría: root no dice quién lo hizo.
  • Cuenta de servicio — copias, monitoreo y replicación, cada una con lo mínimo necesario y contraseña rotada.
-- PostgreSQL: rol de aplicación sin privilegio administrativo
CREATE ROLE app_pedidos LOGIN PASSWORD :'clave';
GRANT CONNECT ON DATABASE pedidos TO app_pedidos;
GRANT USAGE ON SCHEMA public TO app_pedidos;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_pedidos;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_pedidos;

Un privilegio concedido en el incidente necesita fecha de salida

La concesión de emergencia es legítima; lo que no es legítimo es que sobreviva al incidente. Toda concesión temporal entra en el registro de cambios con plazo de revocación.

Cambio de esquema sin parar la aplicación

ALTER TABLE sobre una tabla grande es la causa más común de indisponibilidad autoinfligida. Según la versión y la operación, reescribe la tabla entera sosteniendo un lock — y la aplicación se detiene.

El procedimiento estándar:

  1. Clasificar la operación — algunas son instantáneas (agregar columna con valor por defecto en versiones recientes), otras reescriben la tabla.
  2. Usar herramienta online cuando reescribe — gh-ost o pt-online-schema-change en MySQL; en PostgreSQL, el patrón de crear columna nueva, rellenar por lotes y cambiar.
  3. Índices sin bloqueo — CREATE INDEX CONCURRENTLY en PostgreSQL; creación online en MySQL.
  4. Rellenar por lotes — nunca un UPDATE único sobre millones de filas: lotes pequeños, con pausas, para no reventar el log de transacciones ni el lag de replicación.
  5. Compatibilidad en ambos sentidos — el esquema nuevo debe funcionar con el código viejo y con el nuevo, para que el deploy y la migración de esquema puedan revertirse por separado.

Actualización de versión

Tipo Riesgo Procedimiento
Parche Bajo Réplicas primero, luego failover planificado y primario
Versión menor Medio Igual que el parche, con prueba de regresión de consultas críticas antes
Versión mayor Alto Entorno de prueba con copia real, comparación de plan de ejecución y, cuando es posible, migración por replicación lógica con rollback

El orden siempre es réplica antes que primario: si la versión nueva tiene un problema, aparece en un nodo que no atiende escritura.

Gestión de capacidad

Tres curvas se siguen todo el tiempo, con alerta antes del límite, no en el límite:

  • Espacio en disco — incluye datos, índices, log de transacciones y archivo de log retenido. La alerta se dispara con holgura para actuar en horario comercial.
  • Memoria y tasa de acierto de caché — una caída en la tasa de acierto suele ser la primera señal de que el conjunto activo ya no cabe en RAM.
  • Conexiones — pico de conexiones contra el límite configurado; sin pool, una ráfaga de tráfico se convierte en too many connections.

La retención también es capacidad

Las tablas de log e histórico crecen para siempre si nadie define una política. Particionar por fecha y descartar la partición antigua es más barato que un DELETE masivo — y no deja hinchazón.

Guardia y runbooks

Cada alerta tiene un runbook escrito, con síntoma, verificación, acción y criterio de escalado. Lo que siempre está documentado:

  • promoción manual de réplica y fencing del primario antiguo;
  • reconstrucción de una réplica que quedó demasiado atrás;
  • restauración completa y restauración puntual (point-in-time);
  • respuesta a disco lleno, sin borrar lo que todavía hace falta para recuperar;
  • cierre de sesión bloqueada y diagnóstico de bloqueo en cadena.

Improvisar en una base de datos cuesta datos. La guardia ejecuta un procedimiento; si el caso no tiene procedimiento, escala.

Registro de cambios

Todo cambio relevante — parámetro, versión, esquema, privilegio, topología — se registra con qué cambió, por qué, quién lo aprobó, cuánto tardó y cuál era el rollback. Ese registro es lo que permite conectar una degradación de rendimiento del martes con el cambio de parámetro del lunes.

Páginas Relacionadas