Categoría: Bases de datos
MySQL y MariaDB gestionados en vuestra cuenta: réplicas, copias y actualizaciones probadas
La base de datos de vuestra tienda, vuestro ERP o vuestra aplicación con réplica, copias que sabemos restaurar y un camino claro para salir de versiones sin soporte.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
En resumen
MySQL y MariaDB son bases de datos relacionales de código abierto muy extendidas en webs, tiendas y aplicaciones de gestión. Administrarlas es responder de que estén disponibles, rápidas y recuperables. Montamos réplicas con GTID o clústeres Galera cuando encajan, copias físicas con recuperación a un momento concreto que restauramos en pruebas, métricas, revisión de consultas lentas y actualizaciones ensayadas.
¿Qué nos encargamos de mantener?
MySQL y MariaDB suelen estar debajo de algo que factura: una tienda online, un ERP, un CRM o la aplicación de la empresa. Muchas llevan años en el mismo servidor, con la configuración por defecto y una copia nocturna que nadie ha restaurado nunca. Nos encargamos de que eso cambie sin parar vuestro negocio.
InnoDB y configuración
Memoria del buffer pool, registro de transacciones, conexiones y modo SQL.
Réplicas
Réplica con GTID, asíncrona o semisíncrona, o Galera en MariaDB.
Proxy
ProxySQL o MaxScale para repartir lecturas y conmutar de principal.
Copias y binlogs
Copias físicas y binlogs archivados para recuperar a un momento concreto.
Métricas
mysqld_exporter en Prometheus: retraso de réplica, consultas, bloqueos y disco.
Accesos
Usuarios por aplicación, contraseñas fuera del código y TLS.
¿Qué tipo de réplica montamos?
Siempre con GTID, que identifica cada transacción y permite apuntar una réplica a otro principal sin buscar posiciones de binlog a mano. La elección importante es cuánto podéis perder si el principal cae.
| Situación | Lo que montamos | Qué implica |
|---|---|---|
| Se tolera perder unos segundos y un rato de corte | Réplica asíncrona con GTID | Sencilla y sin coste en escritura; la conmutación la decidimos nosotros o un orquestador |
| No se puede perder una transacción confirmada | Réplica semisíncrona | El principal espera a que una réplica reciba cada transacción; añade algo de latencia |
| Varios nodos que escriben y conmutación inmediata (MariaDB) | Galera Cluster con tres nodos | Sin pérdida de datos, pero sensible a la red y a las transacciones grandes |
| Proveedor con base de datos gestionada | RDS, Cloud SQL, Azure Database u otra | El proveedor conmuta; nosotros ajustamos, vigilamos y probamos restauraciones |
Delante ponemos ProxySQL con MySQL o MaxScale con MariaDB: las aplicaciones se conectan siempre al mismo sitio, las lecturas pesadas pueden ir a la réplica y un cambio de principal no obliga a editar la configuración de nadie. Y una réplica no sustituye a la copia: un DROP TABLE llega a todos los nodos casi a la vez.
¿Qué problemas encontramos más a menudo?
- Versión sin soporte: MySQL 5.7 o 8.0, o una MariaDB fuera de su ciclo LTS, sin parches de seguridad.
- Réplica rota sin aviso: se paró por un error de duplicado hace semanas y nadie lo vio.
- Binlogs llenando el disco: sin caducidad configurada, o retenidos por una réplica abandonada.
- Tablas sin clave primaria: ralentizan la réplica basada en filas y dan problemas en Galera.
- Consultas sin índice: un listado que va bien con mil filas y tumba el servidor con un millón.
- Todo con root: la aplicación, las copias y las personas entran con el mismo usuario, a veces desde internet.
¿Cómo hacemos y probamos las copias?
Con Percona XtraBackup en MySQL o mariabackup en MariaDB hacemos copias físicas en caliente, sin bloquear la base de datos, y copiamos los binlogs de forma continua a un almacenamiento de objetos en otra cuenta o en otro proveedor, cifrados. Restaurar es aplicar la copia y reproducir los binlogs hasta el minuto que elijáis. Al menos una vez al mes lo hacemos de verdad en un servidor de prueba, comprobamos que arranca, que la réplica se puede reconstruir desde ahí y lanzamos consultas de control. El tiempo que tarda es vuestro tiempo real de recuperación, y queda escrito en el informe.
¿Cómo actualizamos de versión?
En MySQL solo se avanza de una serie a la siguiente: de 5.7 a 8.0 y de 8.0 a 8.4 LTS. Antes revisamos palabras reservadas nuevas, cambios en el modo SQL, el juego de caracteres y la autenticación, porque 8.4 deja desactivado por defecto el antiguo mysql_native_password y algunas aplicaciones viejas dejan de conectar. En MariaDB pasamos de una LTS a la siguiente, por ejemplo de 10.6 a 10.11 y luego a 11.4. El método más seguro es levantar una réplica con la versión nueva, dejar que se sincronice, probar las aplicaciones contra ella y cambiar el principal en un corte corto. Si sale mal, la versión anterior sigue ahí.
¿Cómo encontramos las consultas lentas?
Activamos el registro de consultas lentas con un umbral razonable, lo agregamos con pt-query-digest o con Performance Schema y os pasamos las pocas consultas que se llevan la mayor parte del tiempo, con el índice o el cambio que proponemos para cada una. Casi siempre se gana más ahí que ampliando el servidor.
¿Cuándo os recomendamos la base de datos de vuestro proveedor?
Cuando existe para vuestro motor, la carga es normal y no necesitáis plugins ni parámetros que el servicio no permite. RDS, Cloud SQL, Azure Database for MySQL o las bases de datos gestionadas de DigitalOcean y OVHcloud resuelven bien los parches y la conmutación. Montamos y operamos MySQL o MariaDB nosotros mismos cuando el proveedor no la ofrece, como Hetzner, cuando necesitáis Galera o funciones propias de MariaDB, o cuando el coste del gestionado crece más que la base de datos. En los dos casos la vigilancia automática es continua; la respuesta humana es en horario laboral, como en el SRE como servicio. Las métricas terminan en la monitorización con Grafana y Prometheus.
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidores cloud o dedicados con MySQL o MariaDB, réplica o Galera en red privada y binlogs archivados en Object Storage de Hetzner. | Hetzner no ofrece base de datos gestionada: la réplica, el balanceo y las copias las montamos nosotros. |
| AWS | RDS for MySQL, RDS for MariaDB o Aurora MySQL cuando encajan; si no, EC2 con réplica GTID y copias a S3. | Revisamos grupos de parámetros, réplicas de lectura, la retención de copias y que la restauración funciona. |
| Google Cloud | Cloud SQL para MySQL con alta disponibilidad regional, o Compute Engine con réplica y copias a Cloud Storage. | Cloud SQL no ofrece MariaDB: si dependéis de funciones propias de MariaDB, va en máquinas virtuales. |
| Azure | Azure Database for MySQL (servidor flexible), o máquinas virtuales con MySQL o MariaDB. | Azure retiró su servicio gestionado de MariaDB; quien lo usaba tiene que pasar a MySQL flexible o a máquinas propias. |
| DigitalOcean | MySQL gestionado de DigitalOcean con nodos en espera, o Droplets con MySQL o MariaDB. | Sencillo para cargas pequeñas y medianas; revisamos los límites de conexiones del plan. |
| OVH | Base de datos gestionada de OVHcloud para MySQL, o instancias de Public Cloud con réplica o Galera. | |
| Servidor propio | MySQL o MariaDB en vuestros servidores o máquinas virtuales, con la réplica en otra máquina física y copias a un almacenamiento S3 externo. | Galera necesita tres nodos y una red estable entre ellos; con dos, una caída deja el clúster sin quórum. |
Qué incluye
- Réplica asíncrona o semisíncrona con GTID, o un clúster Galera en MariaDB cuando la carga lo pide.
- ProxySQL o MaxScale delante, para repartir lecturas y cambiar de principal sin tocar las aplicaciones.
- Copias físicas con Percona XtraBackup o mariabackup y archivado de binlogs fuera del servidor, cifrados.
- Restauración de prueba periódica a un momento concreto, con el tiempo medido en el informe.
- Métricas con mysqld_exporter y alertas de retraso de réplica, disco, conexiones y bloqueos.
- Revisión del registro de consultas lentas, índices y memoria de InnoDB.
- Actualizaciones de 5.7 a 8.0 y 8.4 LTS, o entre versiones LTS de MariaDB, ensayadas antes en una copia.
- Un usuario por aplicación con permisos mínimos, TLS y acceso solo desde la red privada.
Preguntas frecuentes
¿Seguimos en MySQL 5.7 u 8.0, es urgente actualizar?
Sí. MySQL 5.7 dejó de recibir parches en 2023 y la serie 8.0 llegó a su fin de vida en abril de 2026. El destino razonable es 8.4 LTS, pasando por 8.0 si venís de 5.7, porque no se puede saltar directamente. Lo ensayamos antes con una copia de vuestros datos y vuestras aplicaciones.
¿MySQL o MariaDB?
Si ya tenéis una funcionando, casi nunca compensa cambiar. Hoy son productos distintos: la replicación, el formato de GTID y algunas funciones no coinciden, así que una migración entre ellos se trata como un proyecto, no como una actualización. Para algo nuevo, lo decidimos según lo que soporten vuestra aplicación y vuestro proveedor.
¿Necesitamos un clúster Galera?
Pocas veces. Galera da escritura en varios nodos y conmutación sin pérdida de datos, pero exige tres nodos, red de baja latencia y tablas con clave primaria, y las transacciones grandes lo ralentizan. Para la mayoría de cargas basta un principal con réplica y ProxySQL o MaxScale delante.
¿Nos vale con mysqldump?
Para bases de datos pequeñas, como complemento. Una copia lógica tarda mucho en restaurar cuando la base crece y solo recupera al momento en que se hizo. Con una copia física y los binlogs archivados se recupera al minuto anterior a un borrado por error, en mucho menos tiempo.
¿Gestionáis también PostgreSQL o MongoDB?
Sí, con el mismo enfoque de réplica, copias probadas y actualizaciones planificadas. Tenéis los detalles en las páginas de PostgreSQL y MongoDB.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
- MySQL 8.4 Reference Manual: Replication
- MySQL 8.4 Reference Manual: Point-in-Time (Incremental) Recovery
- MariaDB Documentation: mariadb-backup Overview
Revisado el