MariaDB en VPS: SQL libre, rápido y bajo control

MariaDB es un fork comunitario de MySQL, 100 % de código abierto, reconocido por su rendimiento, su fiabilidad y su compatibilidad total con las aplicaciones MySQL existentes. Alojado en un VPS, le libera de las restricciones del alojamiento compartido: sin límite de conexiones impuesto, sin cuotas arbitrarias sobre el tamaño de las bases de datos, y con la posibilidad de ajustar con precisión los parámetros del motor InnoDB según su carga real. Usted mantiene el control de sus copias de seguridad, sus usuarios y la seguridad de red, sin depender de un proveedor externo para cada operación de mantenimiento.

Hoy están disponibles dos versiones LTS: MariaDB 11.4 LTS (lanzada en mayo de 2024, soporte garantizado hasta 2028+) y MariaDB 10.11 LTS (soporte hasta febrero de 2028). Ambas son estables para producción; la 11.4 incorpora el abandono definitivo del cliente mysql en favor de mariadb, mejor paralelismo de hilos y mejoras en InnoDB.

Antes de comenzar, compruebe que dispone de los siguientes elementos:

- Un VPS ServOrbit: 2 GB de RAM mínimo (uso ligero o pruebas), 4 GB recomendados en producción. MariaDB en sí consume poco, pero el pool de búferes InnoDB (innodb_buffer_pool_size) debe representar el 60-70 % de la RAM disponible para ser eficaz — en 2 GB quedan menos de 1,2 GB útiles después del sistema operativo.
- Acceso SSH root o sudo a su VPS.
- Una versión reciente de MariaDB: MariaDB 11.4 LTS (mayo de 2024, soporte hasta 2028+) o MariaDB 10.11 LTS (soporte hasta febrero de 2028). Evite 10.6 e inferiores en producción: se acercan al fin de soporte.
- Un firewall activo (UFW o equivalente): el puerto 3306 no debe estar nunca expuesto directamente a Internet.

Una base de datos sin copias de seguridad automatizadas es una bomba de relojería. El siguiente script crea una copia de seguridad comprimida cada noche con retención de 7 días.

Cree el script de copia de seguridad en /usr/local/bin/backup-mariadb.sh:

#!/bin/bash
BACKUP_DIR="/var/backups/mariadb"
DATE=$(date +%Y%m%d_%H%M%S)
DB_USER="root"
DB_PASS="your_root_password"
RETENTION=7

mkdir -p "$BACKUP_DIR"

DATABASES=$(mariadb -u"$DB_USER" -p"$DB_PASS" -e "SHOW DATABASES;" 2>/dev/null | \
  grep -vE "^(Database|information_schema|performance_schema|mysql|sys)$")

for DB in $DATABASES; do
  mariadb-dump \
    -u"$DB_USER" -p"$DB_PASS" \
    --single-transaction \
    --quick \
    --routines \
    --triggers \
    "$DB" | gzip > "$BACKUP_DIR/${DB}_${DATE}.sql.gz"
done

find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION -delete

Haga el script ejecutable y añada una tarea cron para ejecutarlo cada noche a las 02:00:

chmod +x /usr/local/bin/backup-mariadb.sh
crontab -e

Añada la siguiente línea:

0 2 * * * /usr/local/bin/backup-mariadb.sh >> /var/log/backup-mariadb.log 2>&1

Para restaurar una base de datos desde una copia de seguridad:

zcat /var/backups/mariadb/my_app_20261007_020000.sql.gz | mariadb -u root -p my_app

La configuración predeterminada de MariaDB es muy conservadora (solo unas decenas de MB para innodb_buffer_pool_size). En un VPS de producción, ajuste los parámetros InnoDB para aprovechar la memoria disponible.

Cree el archivo /etc/mysql/conf.d/performance.cnf:

[mysqld]
# InnoDB buffer pool: 60-70% of total RAM
# On 4 GB RAM → 2.5 GB
innodb_buffer_pool_size = 2560M

innodb_log_file_size = 640M

innodb_log_files_in_group = 2

# Query cache disabled on MariaDB 10.3+
query_cache_size = 0
query_cache_type = 0

max_connections = 150

slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log

Ajuste innodb_buffer_pool_size según la RAM de su VPS: en 2 GB, use 1228M; en 8 GB, use 5632M.

Reinicie MariaDB para aplicar la configuración:

systemctl restart mariadb

Verifique que los parámetros se han aplicado correctamente:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'query_cache_size';

Por defecto, MariaDB solo escucha en 127.0.0.1 — esta es la configuración segura por defecto. Para el acceso desde una aplicación en otro servidor, existen dos enfoques.

Opción 1 — Túnel SSH (recomendada, sin abrir el puerto 3306)

Desde su máquina local o servidor de aplicaciones:

ssh -L 3306:127.0.0.1:3306 -N root@<mariadb-vps-ip>

Su aplicación se conecta entonces a 127.0.0.1:3306 localmente — el túnel SSH cifra el tráfico. Añada -f para poner el túnel en segundo plano.

Opción 2 — Conexión entre VPS con allowlisting de IP

Si su aplicación se ejecuta en otro VPS ServOrbit, abra el puerto únicamente para la IP de ese servidor:

# En /etc/mysql/conf.d/network.cnf
[mysqld]
bind-address = 0.0.0.0

ufw allow from <app-ip> to any port 3306

Cree el usuario MariaDB limitado a la IP del servidor de aplicaciones:

CREATE USER 'app'@'<app-ip>' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON my_app.* TO 'app'@'<app-ip>';
FLUSH PRIVILEGES;

Estos son los cuatro errores más frecuentes al operar MariaDB en un VPS, y cómo resolverlos.

1. Can't connect to local MariaDB server through socket

El servicio MariaDB no está en ejecución o el socket no se encuentra.

systemctl status mariadb
systemctl start mariadb

Si el servicio se niega a iniciar, lea los registros:

journalctl -xe -u mariadb --no-pager | tail -40

2. Too many connections

El número de conexiones simultáneas ha alcanzado el límite. Aumente max_connections en /etc/mysql/conf.d/performance.cnf y recargue:

systemctl reload mariadb

3. Table '<name>' is marked as crashed

Una tabla MyISAM está dañada. Repárela:

mysqlcheck -u root -p --repair my_app table_name

4. Access denied for user 'root'@'localhost'

Contraseña root olvidada. Restablézcala en modo sin autenticación:

systemctl stop mariadb
mysqld_safe --skip-grant-tables &
mariadb -u root

Luego en el shell de MariaDB:

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';
FLUSH PRIVILEGES;
EXIT;

Reinicie MariaDB normalmente: systemctl restart mariadb.