Utilizar MariaDB MaxScale como proxy de base de datos

Configurar MaxScale como capa proxy

MariaDB MaxScale Es una capa de proxy independiente entre la aplicación y los servidores MariaDB. Para garantizar un funcionamiento fiable, la configuración, las funciones disponibles y las limitaciones conocidas deben coincidir en todo momento con la versión realmente instalada. La serie MaxScale 25.10 aparece en la documentación oficial con sus propias notas de lanzamiento.

La aplicación se conecta a un listener de MaxScale en lugar de hacerlo directamente con un servidor de base de datos. Un servicio agrupa la lógica de acceso, un enrutador determina el backend y los filtros pueden procesar adicionalmente las consultas antes de reenviarlas. Los datos permanecen en los backends de MariaDB; MaxScale no se convierte en sí mismo en una base de datos.

Esta separación resulta especialmente útil cuando no se quiere que una aplicación sepa por sí misma qué servidor desempeña cada función en cada momento. Para conocer los conceptos básicos sobre el modelo de datos, SQL y el funcionamiento de la base de datos, consulta el artículo MariaDB como base de datos de código abierto Un complemento adecuado. El proxy complementa la arquitectura del servidor, pero no sustituye ni los derechos de acceso a la base de datos ni un plan de replicación y gestión de fallos.

En Enrutamiento de conexiones Al establecer una sesión, MaxScale selecciona un destino; este backend se encarga de gestionar dicha sesión. En el enrutamiento de sentencias, el enrutador puede asignar las sentencias SQL de forma diferente en función de su contenido. Por lo tanto, la variante más adecuada depende de las transacciones, del estado de la sesión y de la capacidad de la aplicación para separar de forma clara las rutas de lectura y de escritura.

A Proxy de base de datos No se trata de una garantía general de rendimiento. Puede centralizar el enrutamiento, desacoplar los cambios de rol de las aplicaciones o distribuir las solicitudes de lectura adecuadas. No obstante, los nodos de red adicionales, el análisis SQL y la topología concreta del backend influyen en su comportamiento. Por lo tanto, la capacidad de carga y el rendimiento deben comprobarse con la propia versión, configuración y carga.

Supervisar correctamente la topología primaria-réplica

Una arquitectura típica consta de un servidor primario de escritura y una o varias réplicas de lectura. MaxScale es el único punto de acceso a la base de datos de la aplicación, por ejemplo, detrás de un nombre DNS fijo. Por lo tanto, la aplicación no se conecta directamente con hosts individuales; la selección de un backend accesible y adecuado se lleva a cabo dentro de la capa de proxy.

En el caso de una topología «primario-réplica», el monitor determina mariadbmon el estado de los backends e identifica sus roles como «primario» o «réplica». Los enrutadores pueden utilizar esta información para seleccionar el destino. Por lo tanto, el monitor debe poder ver la topología real de la replicación; las asignaciones erróneas, los datos no replicados o los roles poco claros no son problemas de enrutamiento, sino riesgos operativos.

Hay que distinguir entre la identificación de un rol y su modificación. Con la configuración y los permisos adecuados, mariadbmon puede gestionar la conmutación por error, las conmutaciones planificadas y la reincorporación. Una conmutación es un cambio de rol preparado de forma deliberada con fines de mantenimiento u operación; una conmutación de emergencia responde a un fallo. Ambos procesos requieren una topología clara, supervisión, alertas y un proceso documentado de gestión de incidencias o de restablecimiento.

Para tareas exclusivamente de supervisión, la cuenta de monitorización debería funcionar según el principio Menor privilegio solo se conceden los derechos necesarios. La documentación actual lo denomina REPLICA MONITOR. Se requieren derechos adicionales en función de las funciones activadas, como FILE para comprobar el espacio de almacenamiento, o otros derechos específicos para escaneos de topología y manipulaciones de clústeres. Los derechos plenos generales no son un sustituto válido para ello.

Antes de proceder a la automatización, el equipo debe determinar quién autoriza un cambio de rol, cómo se comprueba el estado de las réplicas y cómo se informa a las aplicaciones de las incidencias. MaxScale puede adaptar los destinos de enrutamiento en función de los roles detectados. Sin embargo, es el concepto de alta disponibilidad, con sus límites en cuanto a datos, tiempo y responsabilidades, el que determina si una conmutación es técnicamente admisible.

Comprender el enrutamiento SQL y los límites de consistencia

El router lectura-escritura-división Dirige las instrucciones SQL de escritura al servidor primario y distribuye las consultas de lectura adecuadas entre las réplicas. De este modo, un clúster de servidores primarios y réplicas puede aprovechar su capacidad de lectura de forma más específica, sin que la aplicación tenga que asignar cada consulta a un servidor por sí misma. La información sobre los roles del monitor constituye la base para dicha selección.

En la configuración predeterminada, esta distribución no garantiza que una lectura vea el nuevo estado inmediatamente después de cada escritura. causal_reads está configurado de forma predeterminada en none. Si, por ejemplo, una aplicación escribe el estado de un pedido y, a continuación, lo lee mediante una consulta independiente, es posible que una réplica siga mostrando el estado anterior. Una ruta de lectura primaria elegida deliberadamente o un contexto de transacción compartido son estrategias posibles, pero no las únicas.

Para Lee lo que escribes Cuando se activa la opción «Causal Reads», «readwritesplit» puede tener en cuenta las escrituras anteriores a pesar del retraso en las réplicas. El modo local garantiza la visibilidad de esa misma conexión. global mantiene el estado del GTID almacenado por el servicio en todas sus conexiones; en este caso, solo se garantiza un orden global «happens-before» de las lecturas si todas las transacciones se encuentran dentro de un único dominio GTID. universal tiene en cuenta el estado de las transacciones del clúster observable en el servidor primario. Sin embargo, los ámbitos de aplicación más amplios aumentan el esfuerzo de sincronización y, por lo tanto, potencialmente la latencia.

Las lecturas causales utilizan información GTID y, en los modos no rápidos, esperan a que se produzca la replicación. Si la sincronización dura más de causal_reads_timeout – por defecto, 10 segundos –, readwritesplit intenta ejecutar la consulta en el servidor primario. En una transacción de solo lectura, en cambio, puede devolverse un tiempo de espera como error, ya que la consulta no puede trasladarse al servidor primario.

Los modos rápidos fast, fast_global y fast_universal No esperan a una réplica y, si es necesario, utilizan el primario; allí no se aplica el tiempo de espera. Por eso, son especialmente adecuadas para cargas de trabajo predominantemente de lectura con pocas operaciones de escritura. A partir de la versión 24.02 de MaxScale, este configura automáticamente el seguimiento necesario para las nuevas conexiones al backend; las versiones anteriores requieren para ello last_gtid en session_track_system_variables en todos los backends.

Dentro de una transacción abierta de lectura y escritura, readwritesplit redirige los accesos de lectura al servidor primario. Esto evita que las instrucciones de una misma transacción se ejecuten en backends con distintos estados de replicación. Esta regla conservadora no exime de la obligación de establecer límites de transacción de forma técnicamente correcta y de tratar el retraso en la replicación como un límite arquitectónico propio.

También en el caso de los procedimientos almacenados, las llamadas a UDF y las sentencias múltiples, la decisión es deliberadamente más cautelosa: en los casos documentados, este tipo de consultas se redirigen al servidor principal. El motivo es que su efecto o su contexto no deben tratarse como si se tratara de una simple consulta de lectura. Por lo tanto, el enrutamiento SQL no consiste simplemente en buscar la palabra SELECT, sino que sigue unas reglas para garantizar la seguridad en la gestión de sesiones y la semántica.

Un valor límite establecido por expertos para Réplica-Lag Puede excluir réplicas de determinadas operaciones de lectura, pero no sustituye a ningún requisito de consistencia. El retraso aceptable depende, por ejemplo, de si se puede tolerar una entrada obsoleta en el catálogo o si es imprescindible que se vea un estado de pago que acaba de confirmarse. Esta decisión debe formar parte de la lógica de la aplicación y del contrato de servicio, no de una configuración predeterminada general del proxy.

Configurar «Readwritesplit» de forma segura

Una configuración de separación de lectura/escritura consta de definiciones de objetos independientes para los backends, el monitor, el servicio y el listener. El siguiente fragmento muestra la estructura de un archivo, no una plantilla lista para su uso inmediato en producción. Los valores entre corchetes no son, en ningún caso, contraseñas, sino referencias a cuentas y secretos que deben proporcionarse a través de la gestión de secretos del entorno operativo. El monitor y el servicio necesitan, cada uno, sus propios datos de acceso para sus respectivas tareas.

[db-primary]
type=server
address=db-primary.example.invalid
port=3306

[db-replica-1]
type=server
address=db-replica-1.example.invalid
port=3306

[db-replica-2]
type=server
address=db-replica-2.example.invalid
port=3306

[cluster-monitor]
type=monitor
module=mariadbmon
servers=db-primary,db-replica-1,db-replica-2
user=<monitor-account-from-secret-management>
password=<monitor-secret-reference>

[RW-Service]
type=service
router=readwritesplit
servers=db-primary,db-replica-1,db-replica-2
user=<service-account-from-secret-management>
password=<service-secret-reference>

[RW-Listener]
type=listener
service=RW-Service
protocol=MariaDBClient
port=3306

Los objetos de servidor se refieren únicamente a los backends de MariaDB accesibles; el monitor determina qué instancia es primaria y cuál es réplica en función de la topología. La cuenta del monitor se utiliza para las consultas de estado y de roles. La cuenta de servicio independiente sirve para obtener de los backends la información sobre usuarios y derechos necesaria para la autenticación y autorización de los clientes. Ambas cuentas solo necesitan los derechos documentados para su respectiva tarea. Reconocer los roles La carga de datos y la información de los usuarios son tareas independientes.

Los marcadores de posición del ejemplo deben resolverse durante la implementación mediante una vía de implementación protegida; no están pensados como valores de configuración literales. Las contraseñas en texto claro, las rutas reales de los certificados o los paquetes de derechos no verificados no deben figurar en archivos o repositorios de libre acceso. MaxScale gestiona internamente las cuentas de usuario y los permisos relevantes para las conexiones de protocolo de MariaDB a partir de las tablas del sistema. Si se modifican las cuentas o los permisos, la información obsoleta puede afectar al inicio de sesión o a la autorización.

Por lo tanto, antes de la puesta en marcha, es necesario comprobar por separado el puerto del listener, las rutas de red, la sincronización de usuarios y la asignación real de los routers. Las intervenciones automáticas del monitor tampoco forman parte implícitamente de esta configuración mínima: las funciones de conmutación por error, conmutación o reincorporación requieren una configuración adicional y un plan operativo probado. Una configuración aparentemente breve no sustituye ni a la gestión de claves secretas ni a la comprobación de la topología del backend.

Comparar modelos de routers según su uso

La elección del enrutador depende del comportamiento de la aplicación, no únicamente del número de réplicas disponibles. Las conexiones directas simplifican la configuración, pero dejan en manos de la aplicación el cambio de destino y el conocimiento de los roles. Dos puntos finales separados con readconnroute son adecuadas cuando la aplicación gestiona de forma deliberada sus propias conexiones de lectura y escritura. Routing de instrucciones El uso de «readwritesplit» resulta útil cuando se desea que una sesión se dirija, en función de la consulta SQL, al servidor principal o a las réplicas.

readconnroute evalúa un servidor de destino al establecer la conexión y no analiza cada instrucción SQL posterior. Si el backend seleccionado falla, la sesión finaliza; el enrutador no la reconecta automáticamente a otro servidor. Esto suele ser comprensible en el caso de conexiones de lectura claramente separadas y de corta duración, pero puede resultar inadecuado para flujos de trabajo de aplicaciones con estado.

Se debe tener especial cuidado con un servicio concebido como punto final de lectura con router_options=slave. La opción da prioridad a los servidores con función de réplica; sin embargo, si todas las réplicas han fallado y el servidor primario está disponible, readconnroute puede recurrir al servidor primario. Además, la opción no genera protección contra la escritura. La aplicación debe enviar únicamente consultas SQL de lectura, o bien debe aplicarse un filtro ReadOnly adicional para impedir los accesos de escritura. Por lo tanto, el destino de enrutamiento y la preferencia de rol no constituyen ni una limitación de permisos ni un sustituto de los derechos restrictivos de la base de datos.

Por el contrario, «readwritesplit» reduce las decisiones de destino en el código de la aplicación, pero exige un análisis preciso de la semántica. Las lecturas adecuadas pueden distribuirse entre las réplicas, mientras que las operaciones de escritura se dirigen al servidor primario. En los procesos con requisitos estrictos de actualidad, sigue siendo decisivo si una consulta puede esperar a que se realice una escritura en los datos replicados o si debe utilizar deliberadamente el servidor primario.

Planificar sesiones, el Lag y la transición

Una sesión de base de datos comprende más que una sola consulta. SET, USE, CHANGE USER y las operaciones con sentencias preparadas cambian su contexto. readwritesplit replica los comandos de sesión relevantes en los posibles servidores de destino, para que posteriormente se puedan ejecutar las sentencias redirigidas con el estado de sesión adecuado. Esto diferencia al enrutador del simple equilibrio de carga TCP, aunque no elimina todas las limitaciones de los casos especiales.

En el caso de las sentencias preparadas para tablas temporales, este límite es especialmente importante. Si una sentencia de este tipo se prepara en el servidor principal, las réplicas no siempre podrán ejecutarla. Por lo tanto, la aplicación debería probar los objetos temporales, las sentencias preparadas y los flujos de transacciones con el modelo de enrutamiento previsto. Estado de la sesión No es una condición secundaria, sino que determina si una distribución SQL es adecuada desde el punto de vista funcional y técnico.

En el caso de una aplicación con un uso intensivo de lectura, el equipo puede definir un valor límite de retraso establecido por los expertos como criterio de exclusión para las réplicas. Solo max_replication_lag Sin embargo, esto no garantiza que una escritura previa en una réplica ya sea visible. Para las lecturas posteriores críticas, dependiendo del proceso, se pueden considerar una ruta primaria deliberada, un contexto de escritura compartido o lecturas causales activadas.

En el caso de las lecturas causales, hay que elegir deliberadamente el ámbito de aplicación. local mantiene la causalidad dentro de una relación. global Utiliza un valor de GTID almacenado a nivel de servicio, pero solo garantiza el orden global «happens-before» de las lecturas si todas las transacciones se encuentran en un único dominio GTID. universal Tiene en cuenta el estado de las transacciones del clúster observable en el servidor primario. Los modos que no son rápidos se sincronizan mediante GTID; si una réplica no se pone al día dentro del tiempo de espera configurado, la consulta se repite siempre en el servidor primario, siempre que el modo de transacción lo permita.

Esta función debe clasificarse en función de la versión. A partir de MaxScale 24.02, MaxScale añade last_gtid para las nuevas conexiones de backend; en versiones anteriores había que session_track_system_variables deben configurarse adecuadamente en los servidores MariaDB. Los modos rápidos evitan las esperas, pero, en el caso de réplicas que aún no se han puesto al día, pueden redirigir las lecturas al servidor primario y, por lo tanto, no son adecuados de forma generalizada para cargas con un uso intensivo de escritura.

Una conmutación planificada y una conmutación automática por fallo también deben tratarse por separado. En la conmutación planificada, el cambio de roles se prepara de forma controlada; en la conmutación automática por fallo, el sistema reacciona ante una situación de error. mariadbmon puede supervisar los roles y los estados del backend y, siempre que se haya configurado adecuadamente, puede dar soporte a estos procesos. Para ello, siguen siendo requisitos imprescindibles la sincronización de datos replicados, una topología clara, un sistema de alertas y un proceso de gestión de incidencias.

En MaxScale 25.10 se puede discover-replicas Detectar los servidores que replican directamente en el primario actual y añadirlos a Monitor y MaxScale. Esta función no es compatible con la sincronización de la configuración. Por lo tanto, antes de utilizarla, el equipo debe determinar si los cambios en la topología se detectarán automáticamente o se controlarán mediante una configuración sincronizada; no es posible aplicar ambas opciones a la vez en este contexto.

TLS, proteger los derechos y los filtros

En MaxScale, el TLS debe configurarse en dos tramos independientes: desde la aplicación hasta el listener y desde el proxy hasta los backends de MariaDB. Ambas conexiones requieren sus propios parámetros de cifrado y verificación de certificados; un tramo de cliente seguro no cifra automáticamente el tráfico posterior. Por lo tanto, la configuración debe reflejar los requisitos de seguridad y la cadena de confianza para ambos tramos.

TLS activado ssl=true el cifrado en la configuración correspondiente del listener o del servidor. Si un cliente espera un certificado de servidor, el listener necesita el certificado y la clave privada. Una cuenta con REQUIRE SSL No se puede iniciar sesión a través de un listener sin TLS. Los archivos de certificados y las claves deben encontrarse en un entorno operativo protegido, no en configuraciones de ejemplo o de repositorios de libre acceso.

También el Concepto de derechos En los backends sigue siendo fundamental: MaxScale gestiona las conexiones, pero no sustituye a las cuentas de base de datos específicas. Las cuentas de servicio solo disponen de los permisos que requiere su función. Para el inicio de sesión y la autorización, MaxScale se basa en las cuentas de usuario y los derechos de las tablas del sistema de MariaDB; por lo tanto, los cambios en estas cuentas deben estar disponibles de forma inmediata en la gestión interna de usuarios.

El filtro del cortafuegos puede comprobar el código SQL antes de reenviarlo, basándose en reglas aprendidas o definidas. Dispone de modos de inactividad, aprendizaje, supervisión y forzado; en el modo de forzado, los patrones de sentencias no permitidos se responden con un error o se interrumpe la conexión, según la configuración. La fase de aprendizaje debe abarcar flujos de aplicación representativos y permitidos, para que el filtro no bloquee consultas habituales.

El filtro es una capa de control adicional para los patrones SQL esperados, no una autorización sustitutiva. Siguen siendo necesarios derechos de acceso restrictivos a la base de datos, datos de acceso protegidos y código de aplicación verificado, ya que el filtro solo evalúa las consultas que recibe según sus reglas. Las afirmaciones sobre otros filtros deben comprobarse por separado consultando su documentación respectiva.

Comprobar de forma sistemática la configuración y los errores

En caso de errores de conexión o de enrutamiento, es mejor seguir un orden de comprobación fijo en lugar de realizar cambios a ciegas. Comprueba primero el estado del monitor: ¿se puede acceder a todos los backends y se reconocen correctamente los roles de primario y réplica? Solo entonces se pueden evaluar de forma sensata las decisiones del enrutador. Un nodo identificado erróneamente o al que no se puede acceder no es un problema exclusivamente del listener.

A continuación, hay que comprobar el listener y el TLS: el puerto, el protocolo, el certificado, la clave y los requisitos de las cuentas utilizadas deben coincidir. A continuación, comprueba si la gestión de cuentas de usuario tiene constancia de las cuentas y los derechos actuales del backend. Especialmente tras realizar cambios en los usuarios o en los permisos, los datos de cuenta obsoletos pueden impedir el inicio de sesión, aunque la cuenta esté correctamente configurada en MariaDB.

A continuación, debes asignar el servicio, el router y los servidores previstos. En el caso de la división de lectura/escritura, también hay que tener en cuenta el retraso de las réplicas, causal_reads y los límites de transacción de la aplicación a la lista de comprobación. Si no se activan las lecturas causales, una lectura realizada fuera del contexto de escritura requerido en una réplica puede proporcionar un estado anterior; un límite de retraso por sí solo no garantiza la visibilidad de una escritura anterior.

Además, coloca una sola Fuente de configuración fija. MaxScale puede conservar los cambios en tiempo de ejecución; al reiniciar, la configuración conservada puede anular los archivos estáticos. Si un equipo edita en parte los archivos y en parte maxctrl Si se utiliza esta configuración de tiempo de ejecución, es obligatorio documentar el historial de modificaciones, la revisión y la copia de seguridad de la misma.

Debes tratar las ventanas de mantenimiento para los cambios en el esquema como un ámbito operativo independiente: hay que comprobar de antemano las dependencias, el comportamiento de bloqueo y la replicación, y no atribuirlo al proxy. Para planificar cambios controlados en tablas grandes de MariaDB, el artículo sobre Cambios de esquema sin tiempo de inactividad contexto complementario. A partir de ahí, MaxScale puede volver a controlar las conexiones y el enrutamiento en función de los roles del backend, pero no ejecuta ninguna estrategia DDL de la base de datos.

Advertencia: los cambios en los roles, los certificados, los derechos de usuario y el enrutamiento deben probarse primero en un entorno similar. Para la intervención en el entorno de producción, es necesario contar con un procedimiento de restablecimiento, la supervisión de los errores de la aplicación y unas responsabilidades bien definidas. De este modo, se puede distinguir si una avería se debe a la configuración del proxy, al backend o al comportamiento del cliente.

Utilizar MaxScale de forma adecuada o prescindir de él

En el caso de un único servidor MariaDB sin requisitos de enrutamiento, conmutación o filtros SQL, las conexiones directas suelen ser la opción más sencilla. Sin embargo, en ese caso, la aplicación deberá gestionar por sí misma cualquier cambio de destino posterior. MaxScale resulta útil cuando el punto final adicional cumple una función concreta, como gestionar cambios de rol, filtrar accesos o distribuir lecturas de forma controlada entre las réplicas.

Si la aplicación puede elegir deliberadamente sus propias rutas de lectura y escritura, los puntos finales separados con readconnroute a menudo comprensible. Este enrutador selecciona un servidor backend al establecer la conexión, pero no analiza cada instrucción SQL ni traslada una sesión interrumpida a otro servidor. En router_options=slave Se da prioridad a las réplicas; si todas las réplicas han fallado y el primario sigue estando disponible, el enrutador puede utilizar el primario. Además, esta opción no convierte el punto final en de solo lectura. Para ello, se requiere un filtro «ReadOnly» adecuado, derechos restrictivos en el backend o un SQL de aplicación estrictamente controlado.

Para las cargas de trabajo de réplica primaria cuyo ORM y modelo de transacciones sean compatibles, se utiliza lectura-escritura-división La aplicación determina la selección de destino SQL para cada instrucción. En la configuración predeterminada causal_reads=none Sin embargo, el retraso en la replicación sigue siendo visible. Tras las escrituras críticas, la aplicación puede utilizar una ruta de lectura primaria o un contexto de transacción compartido adecuado; como alternativa, las lecturas causales pueden configurarse de forma específica para el ámbito de visibilidad necesario.

Las lecturas causales distinguen entre la visibilidad dentro de la misma sesión, un contador GTID global gestionado por el servicio y el estado del clúster observable en el nodo primario. local se aplica a la misma conexión. En el caso de global El orden global «happens-before» de las lecturas solo está garantizado si todas las transacciones pertenecen a un único dominio GTID; por lo tanto, este modo no debe interpretarse de manera general como una garantía de consistencia ilimitada en todo el servicio. universal Comprueba el estado observable en el servidor principal antes de las lecturas. Los modos de sincronización pueden generar un tiempo de espera adicional; las variantes rápidas no esperan, pero pueden desplazar la carga hacia el servidor principal en mayor medida durante las escrituras.

Los casos límite deben someterse a pruebas específicas con el controlador real y el modelo de datos antes de su implementación. Las tablas temporales y las sentencias preparadas para ellas pueden no estar disponibles en las réplicas si la preparación se realiza en el servidor primario. Asimismo, los procedimientos almacenados, las llamadas a funciones definidas por el usuario (UDF), las sentencias múltiples y el estado de la sesión influyen en que el enrutador dirija las consultas de forma conservadora hacia el servidor primario.

La función «Transaction Replay» no garantiza que las transacciones se realicen sin pérdidas. Si se interrumpe una conexión durante COMMIT ... puede dejarse sin resolver si la confirmación ya se ha realizado con éxito. Las configuraciones de reproducción arriesgadas pueden ejecutar dos veces las operaciones de escritura; los resultados que dependen del servidor, como NOW() o @@server_id Además, pueden provocar desviaciones en las sumas de comprobación. Por lo tanto, evalúa su uso en función de los requisitos de consistencia, los flujos de errores y la repetibilidad de las operaciones de escritura, y no basándote en promesas generales de rendimiento.