Introducción

Hace dos semanas, la MariaDB Foundation anunció oficialmente que ProxySQL se unió como patrocinador Silver, marcando un hito en la colaboración entre proyectos clave del ecosistema MySQL/MariaDB. Para equipos de DevOps e infraestructura que gestionan bases de datos en producción, este movimiento no es un mero anuncio corporativo: implica mejoras tangibles en herramientas, compatibilidad y soporte a largo plazo para entornos que combinan MySQL, MariaDB y sus derivados.

ProxySQL, conocido por su proxy de alto rendimiento para MySQL, ya soportaba MariaDB en entornos productivos, pero este patrocinio formaliza un compromiso con la salud del ecosistema completo. René Cannaò, CEO de ProxySQL, destacó en la entrevista oficial que este paso busca «apoyar un ecosistema de bases de datos abiertas que ha sido fundamental para ProxySQL desde sus inicios», especialmente en entornos donde disponibilidad, routing, seguridad y observabilidad son críticos.

Qué ocurrió

El 12 de marzo de 2024, la MariaDB Foundation publicó un comunicado oficial confirmando el patrocinio Silver de ProxySQL. El anuncio destacó tres ejes clave:

  1. Compromiso con la compatibilidad: ProxySQL ya operaba con MariaDB Server en producción, pero el patrocinio refuerza su promesa de mantener soporte estable para la pila completa de bases de datos MySQL-compatibles.
  2. Inversión en herramientas periféricas: ProxySQL no solo mantiene su proxy, sino que colabora activamente en proyectos como dbdeployer (herramienta para despliegues rápidos de instancias MySQL/MariaDB) y Orchestrator (gestión de topologías de replicación y failover). Ambos son críticos para equipos que automatizan despliegues y gestionan alta disponibilidad.
  3. Fomento de la colaboración comunitaria: El objetivo declarado es mejorar la comunicación entre ProxySQL, MariaDB Foundation y usuarios finales, facilitando feedback técnico sobre casos de uso reales, compatibilidad y patrones operativos.

En la entrevista a Cannaò, se mencionó que este patrocinio «no es solo un apoyo financiero, sino una participación activa en el ecosistema». Esto implica que ProxySQL no solo aportará fondos, sino que colaborará directamente con desarrolladores de MariaDB en temas como:

  • Validación de compatibilidad con nuevas versiones de MariaDB Server (por ejemplo, MariaDB 11.4, lanzada en febrero de 2024).
  • Integración con herramientas de observabilidad y automatización (como Prometheus o FluxCD, mencionadas en el comunicado de la MariaDB Foundation).
  • Soporte para arquitecturas híbridas donde conviven MySQL, MariaDB y Percona Server.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps

  • Mejora en herramientas de despliegue: dbdeployer, un proyecto bajo el paraguas de ProxySQL, permite crear entornos de prueba con MariaDB Server en segundos. Esto es clave para CI/CD de bases de datos. Por ejemplo, un equipo puede desplegar 10 instancias de MariaDB 11.3 con replicación semiautomática en menos de 5 minutos usando:
  dbdeployer deploy single 11.3 --gtid --slaveof 11.3:3306
  
  • Integración con orquestación: Orchestrator, otro proyecto respaldado por ProxySQL, es usado por empresas como GitHub para gestionar más de 10,000 nodos MySQL/MariaDB en producción. Su soporte oficial para MariaDB simplifica la gestión de topologías complejas (clústeres con nodos en diferentes regiones).

Para equipos de Cloud

  • Compatibilidad en entornos híbridos: ProxySQL actúa como capa de abstracción entre aplicaciones y bases de datos, permitiendo migraciones graduales entre MySQL y MariaDB sin cambiar el código de la aplicación. Esto es útil en entornos cloud donde se usan servicios gestionados (como Amazon RDS para MySQL) junto a instancias auto-gestionadas de MariaDB.
  • Soporte para multi-tenancy: ProxySQL permite routing basado en reglas SQL, ideal para arquitecturas cloud que requieren aislar cargas de trabajo por cliente o entorno. Por ejemplo, en un entorno con 50 bases de datos diferentes, se pueden redirigir consultas específicas a un clúster de MariaDB optimizado para analytics.

Para equipos de Seguridad

  • Protección contra consultas problemáticas: ProxySQL incluye un módulo de firewall SQL que analiza consultas en tiempo real. En entornos con MariaDB, esto permite bloquear patrones como SELECT * FROM users WHERE 1=1 o DROP TABLE users antes de que lleguen al servidor. ProxySQL 2.6.0 (lanzado en enero de 2024) añadió soporte para reglas basadas en MariaDB Audit Plugin, mejorando la trazabilidad.
  • Encriptación en tránsito: ProxySQL soporta TLS 1.3 desde la versión 2.5.0 (octubre 2023), y su integración con MariaDB Server permite forzar conexiones seguras incluso en versiones antiguas de MariaDB (hasta 10.4.x). Esto es crítico para entornos que no pueden actualizar MySQL/MariaDB por compatibilidad con aplicaciones legacy.

Detalles técnicos

Versiones afectadas y soporte

  • MariaDB Server: ProxySQL garantiza compatibilidad con MariaDB 10.2 a 11.4 (lanzamientos recientes). Sin embargo, para características avanzadas como GTID (Global Transaction ID) o replicación paralela, se recomienda usar MariaDB 10.5+.
  • ProxySQL: Las versiones 2.5.x y 2.6.x son las primeras en incluir mejoras específicas para MariaDB, como:
– Soporte para el plugin MariaDB Audit Plugin (versión 1.2.0 o superior) para logging de consultas.

– Integración con el motor de rewrite de consultas para optimizar sentencias comunes en MariaDB (ej: convertir JOIN en subconsultas optimizadas).

Componentes clave

  1. dbdeployer:
– Herramienta para despliegues rápidos de instancias MySQL/MariaDB.

– Versión actual: 1.62.0 (marzo 2024).

– Permite replicar topologías complejas con un solo comando:

     dbdeployer deploy replication 11.3 --nodes 3 --gtid
     
  1. Orchestrator:
– Sistema para gestionar failovers y topologías de replicación.

– Usado por empresas como GitHub y Booking.com (ambos casos documentados en su repositorio oficial).

– Soporte oficial para MariaDB desde la versión 3.2.6 (febrero 2024).

Vector de compatibilidad

El principal desafío para equipos que usan MariaDB con ProxySQL es la divergencia en el dialecto SQL. Por ejemplo:

  • MariaDB 10.5+ soporta WINDOW FUNCTIONS (SQL:2016), mientras que MySQL 8.0 aún no lo implementa por completo.
  • ProxySQL debe traducir consultas entre dialectos para garantizar consistencia. En la versión 2.6.0, se añadió soporte para SEQUENCE (MariaDB 10.5+) y JSON_TABLE (MariaDB 10.6+).

Parcheo y actualizaciones

  • MariaDB: La Fundación recomienda actualizar a MariaDB 11.3+ (lanzado en diciembre 2023) para corregir vulnerabilidades como:
CVE-2024-2096 (MariaDB 10.4 a 10.11): Vulnerabilidad de inyección SQL en el parser de consultas.

CVE-2023-5157 (MariaDB 10.2 a 11.2): Fuga de memoria en el motor InnoDB.

  • ProxySQL: Actualizar a 2.6.1 (enero 2024) para corregir:
– Un bug en el balanceo de carga con conexiones persistentes (issue #3521).

– Soporte mejorado para TLS 1.3 con MariaDB 11.x.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar componentes críticos

  • MariaDB Server:
  # Para Debian/Ubuntu
  sudo apt update && sudo apt install -y mariadb-server=1:11.3.2+maria~ubu2204
  sudo mariadb-upgrade
  

Verificar versión: mariadb --version debe mostrar 11.3.2 o superior.

Habilitar GTID: Editar /etc/mysql/mariadb.conf.d/50-server.cnf y agregar:

    [mysqld]
    gtid_domain_id=1
    enforce_gtid_consistency=ON
    

Reiniciar: sudo systemctl restart mariadb.

  • ProxySQL:
  # Para Debian/Ubuntu
  sudo apt update && sudo apt install -y proxysql=2.6.1-1ubuntu22.04
  sudo systemctl restart proxysql
  

Verificar versión: proxysql --version debe mostrar 2.6.1.

Configurar firewall SQL: Editar /etc/proxysql.cnf y agregar reglas como:

    mysql-firewall:
      - rule_id: 100
        active: true
        username: "app_user"
        client_address: "%"
        schemaname: "app_db"
        flagIN: true
        flagOUT: false
        match_pattern: "SELECT .* FROM users WHERE id = ?"
    

2. Validar compatibilidad con dbdeployer y Orchestrator

  • Desplegar una instancia de prueba con MariaDB 11.3:
  dbdeployer deploy single 11.3 --gtid --slaveof 11.3:3306
  

– Verificar replicación con: dbdeployer replication status 11.3.

  • Orchestrator:
  docker run -d --name orchestrator -p 3000:3000 ghcr.io/openark/orchestrator:3.2.6
  

– Conectar a un clúster de MariaDB 11.3 y validar failover automático.

3. Auditar configuraciones de seguridad

  • Forzar TLS en ProxySQL:
  # /etc/proxysql.cnf
  mysql-interfaces:
    - interface: 0.0.0.0:6033
      tls: true
      tls_cert: /etc/proxysql/certs/server-cert.pem
      tls_key: /etc/proxysql/certs/server-key.pem
  

Verificar: openssl s_client -connect localhost:6033 -showcerts.

  • Habilitar logging de consultas sospechosas:
  -- En MariaDB Server
  INSTALL PLUGIN server_audit SONAME 'server_audit';
  SET GLOBAL server_audit_logging = ON;
  SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';
  

4. Planificar migraciones graduales

Si tu entorno usa MySQL y planeas adoptar MariaDB:

  1. Prueba con ProxySQL como capa intermedia:
   -- En ProxySQL
   INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb11-node1',3306);
   LOAD MYSQL SERVERS TO RUNTIME;
   SAVE MYSQL SERVERS TO DISK;
   
  1. Redirigir tráfico de lectura:
   INSERT INTO mysql_query_rules (rule_id,active,match_pattern,apply) VALUES
   (1,1,'^SELECT.*FOR UPDATE','read_only=0'),
   (2,1,'^SELECT','read_only=1');
   LOAD MYSQL QUERY RULES TO RUNTIME;
   

Conclusión

La incorporación de ProxySQL como patrocinador Silver de la MariaDB Foundation no es un mero gesto corporativo, sino un paso concreto hacia un ecosistema MySQL/MariaDB más integrado y robusto. Para equipos de infraestructura, esto se traduce en:

  • Herramientas operativas mejoradas: dbdeployer y Orchestrator ahora reciben soporte oficial para MariaDB, facilitando despliegues y gestión de alta disponibilidad.
  • Seguridad reforzada: ProxySQL 2.6.x incorpora mejoras en firewall SQL y soporte para MariaDB Audit Plugin, clave para entornos críticos.
  • Flexibilidad arquitectónica: La compatibilidad entre ProxySQL, MariaDB y MySQL permite migrar cargas de trabajo sin cambiar el código de las aplicaciones.

El desafío ahora es capitalizar esta alianza: actualizar componentes, validar compatibilidades y adoptar prácticas como GTID y TLS 1.3 en entornos productivos. Como bien señala René Cannaò, «el open source más fuerte es aquel donde los proyectos colaboran en lugar de fragmentarse». Esta alianza es un ejemplo de eso.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *