Bases de Datos Distribuidas en WordPress Multisitio: Escalabilidad 2025-2026

Cuando un WordPress Multisitio comienza a crecer, el cuello de botella más común no es el servidor web ni el procesamiento de PHP, sino la base de datos. Una sola instancia de MySQL o MariaDB puede colapsar bajo el peso de cientos o miles de sitios, especialmente si todos comparten el mismo clúster de tablas. La solución para 2025 no es simplemente “comprar un servidor más grande”, sino adoptar una arquitectura de bases de datos distribuidas que garantice escalabilidad horizontal, alta disponibilidad y tolerancia a fallos.

En este artículo exploraremos cómo implementar un sistema de bases de datos distribuidas en un entorno de WordPress Multisitio, cubriendo desde la teoría de la replicación hasta configuraciones prácticas con herramientas como MariaDB Galera, ProxySQL y sharding personalizado. Todo enfocado en el contexto de 2025, donde la nube híbrida y las bases de datos como servicio (DBaaS) son la norma.

¿Por qué una base de datos distribuida para WordPress Multisitio?

WordPress Multisitio, por defecto, utiliza una única base de datos con tablas compartidas (wp_users, wp_blogs, wp_site) y tablas específicas por sitio (wp_2_posts, wp_3_options). Cuando tienes 500 sitios, las consultas a wp_blogs se vuelven lentas. Cuando tienes 5,000, la base de datos puede simplemente dejar de responder.

Los problemas típicos incluyen:

Contención de bloqueos: Las operaciones de escritura en tablas compartidas bloquean lecturas en todos los sitios.
Latencia de replicación: Si usas un esclavo para lecturas, el retraso puede causar inconsistencias en los datos del usuario.
Punto único de fallo: Un fallo en la base de datos principal derriba toda la red de sitios.

Una base de datos distribuida resuelve esto mediante:

Replicación síncrona o asíncrona entre nodos.
Balanceo de carga de consultas de lectura/escritura.
Sharding (fragmentación) de datos por sitio o por funcionalidad.

Arquitectura recomendada: Galera Cluster + ProxySQL

La combinación más probada para WordPress Multisitio en 2025 es MariaDB Galera Cluster como capa de almacenamiento distribuido, con ProxySQL como gateway de enrutamiento inteligente.

Componentes clave

Nodos Galera: Cada nodo es una instancia completa de MariaDB con replicación síncrona. Todos los nodos pueden aceptar lecturas y escrituras.
ProxySQL: Actúa como proxy de base de datos, enrutando consultas según reglas. Separa las lecturas de las escrituras y distribuye la carga.
WordPress Multisitio: Con modificaciones mínimas en wp-config.php para apuntar a ProxySQL en lugar de directamente a MySQL.

[INFO] Galera Cluster utiliza replicación basada en certificación, lo que significa que no hay conflictos de escritura si se evitan las transacciones largas. Es ideal para entornos de alta concurrencia como un Multisitio con mucho tráfico.

Configuración paso a paso

1. Instalación de MariaDB Galera en tres nodos

Cada nodo debe tener una configuración similar. Ejemplo para el nodo 1 (/etc/mysql/mariadb.conf.d/galera.cnf):

[mysqld]
bind-address = 0.0.0.0
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_address = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12"
wsrep_cluster_name = "wp_multisite_cluster"
wsrep_node_name = "node1"
wsrep_node_address = "192.168.1.10"
wsrep_sst_method = rsync
binlog_format = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2

2. ProxySQL como capa de enrutamiento

ProxySQL se instala en un servidor separado (o en el mismo nodo web) y se configura con un archivo de reglas.

# Configuración básica de ProxySQL
mysql -u admin -p -h 127.0.0.1 -P 6032

INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, '192.168.1.10', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, '192.168.1.11', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, '192.168.1.12', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.1.10', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.1.11', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '192.168.1.12', 3306);

INSERT INTO mysql_replication_hostgroups (writer_hostgroup, reader_hostgroup) VALUES (0, 1);

[TIP] Para WordPress Multisitio, es crucial enrutar todas las escrituras al hostgroup 0 (escritores) y las lecturas al hostgroup 1 (lectores). Pero ten cuidado: las consultas a tablas compartidas como wp_options deben ir siempre al escritor para evitar inconsistencias.

3. Modificar wp-config.php para usar ProxySQL

define('DB_HOST', '192.168.1.20:6033'); // IP de ProxySQL
define('DB_USER', 'wp_user');
define('DB_PASSWORD', 'secure_password');
define('DB_NAME', 'wordpress_multisite');

// Forzar el uso de un socket persistente
define('WP_USE_EXT_MYSQL', false);

Estrategias de sharding para Multisitio

La replicación por sí sola no soluciona el problema de la contención en tablas compartidas. Para ello necesitamos sharding, es decir, dividir los datos horizontalmente.

Sharding por sitio (la más simple)

Cada sitio dentro del Multisitio tiene su propio conjunto de tablas (wp_2_posts, wp_3_posts). Podemos mover sitios completos a bases de datos separadas dentro del mismo clúster.

Implementación con un plugin personalizado:

add_filter('site_url', function($url, $path, $scheme) {
    // Determinar el blog_id actual
    $blog_id = get_current_blog_id();
    // Seleccionar la base de datos según el blog_id
    if ($blog_id > 100) {
        // Forzar conexión a la base de datos 'wp_shard_2'
        // Esto requiere modificar la clase wpdb
    }
    return $url;
}, 10, 3);

[WARNING] El sharding en WordPress Multisitio no es trivial. Las tablas compartidas (wp_users, wp_blogs) deben permanecer en una base de datos central. Cualquier consulta JOIN entre tablas de diferentes shards fallará. Por eso, muchos optan por un enfoque de “bases de datos por sitio” solo para sitios muy grandes (más de 10,000 entradas).

Sharding funcional con tablas externas

Otra opción es mover tablas específicas (como wp_2_actionscheduler_claims) a bases de datos separadas usando Federated Tables de MySQL o un motor como Spider. Esto es avanzado y requiere mantenimiento constante.

Monitoreo y ajuste fino en 2025

Una base de datos distribuida no es “configurar y olvidar”. Necesitas monitorear constantemente:

Latencia de replicación: En Galera, usa SHOW STATUS LIKE 'wsrep_local_recv_queue_avg'.
Carga de consultas: ProxySQL ofrece estadísticas detalladas por hostgroup.
Cuellos de botella de escritura: Las tabls compartidas como wp_blogs pueden convertirse en un punto caliente.

Herramientas recomendadas para 2025

Prometheus + Grafana: Para métricas de Galera y ProxySQL.
Percona Monitoring and Management (PMM): Visibilidad completa del stack.
MySQLTuner: Script para optimizar parámetros como innodb_buffer_pool_size y max_connections.

Escenario real: 10,000 sitios en un Multisitio

Imaginemos un proveedor de hosting que gestiona 10,000 sitios WordPress en una sola red Multisitio. Con una base de datos única, las consultas a wp_blogs tardan 2 segundos. Con un clúster Galera de 5 nodos y ProxySQL, logramos:

Lecturas distribuidas: 80% de las consultas van a nodos lectores.
Escrituras síncronas: Sin pérdida de datos incluso si falla un nodo.
Sharding por rango de blog_id: Los primeros 5,000 sitios en un shard, los siguientes 5,000 en otro.

Configuración de ProxySQL para sharding:

-- Regla para enrutar consultas de sitios específicos a diferentes hostgroups
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) 
VALUES (1, 1, '^SELECT.*FROM wp_([5-9][0-9]{3}|[1-9][0-9]{4})_posts', 2, 1);
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup, apply) 
VALUES (2, 1, '^SELECT.*FROM wp_([1-4][0-9]{3}|[0-9]{1,3})_posts', 3, 1);

Consideraciones de seguridad y backup

Las bases de datos distribuidas introducen nuevos vectores de ataque. En 2025, la seguridad debe ser nativa:

Cifrado en tránsito: Usa TLS entre nodos Galera y entre ProxySQL y los nodos.
Autenticación fuerte: ProxySQL soporta autenticación con PAM o LDAP.
Backups consistentes: Con Galera, usa mysqldump con la opción --lock-all-tables o, mejor, haz backups desde un nodo donante usando wsrep_sst_method = mariabackup.

[INFO] Para backups en caliente sin detener el clúster, programa un nodo como “donante” y ejecuta mariabackup --backup mientras el nodo sigue sirviendo tráfico.

Conclusión: ¿Merece la pena en 2025?

Implementar bases de datos distribuidas para WordPress Multisitio no es un proyecto para principiantes. Requiere conocimiento profundo de administración de bases de datos, redes y WordPress interno. Sin embargo, para proyectos que manejan más de 500 sitios activos o más de 1 millón de visitas diarias, la inversión se amortiza rápidamente en términos de rendimiento y disponibilidad.

Alternativas más ligeras para 2025 incluyen:

Amazon RDS con réplicas de lectura: Sin administrar clústeres manualmente.
Google Cloud SQL con failover automático: Ideal si ya estás en GCP.
ProxySQL + MariaDB single master: Si no necesitas escrituras distribuidas.

Pero si buscas el máximo control y rendimiento, un clúster Galera con ProxySQL y sharding inteligente sigue siendo la referencia técnica para WordPress Multisitio a gran escala. La clave está en planificar la fragmentación desde el inicio, monitorizar constantemente y tener un plan de recuperación ante desastres que contemple la naturaleza distribuida de los datos.