Tolerancia a fallos

De forma predeterminada, el manejo de la toleracia a fallos de conexiones se le deja al usuario. La aplicación es responsable de comprobar los valores devueltos de las funciones de bases de datos a las que llama y reaccionar a posibles errores. Si, por ejemplo, el complemento reconoce una consulta como de solo lectura para ser enviada a los servidores esclavos, y el servidor esclavo seleccionado por el complemento no está disponible, el complemento emitirá un error después de no ejecutar la sentencia.

Predeterminado: tolerancia a fallos manual

Es responsabilidad de la aplicación manejar el error y, si fuera necesario, reemitir la consulta para desencadenar la selección de otro servidor esclavo para la ejecución de la sentencia. El complemento no intentará la tolerancia a fallos automáticamente, ya que no puede estar seguro de que una tolerancia a fallos automática cambie el estado de la conexión. Por ejemplo, la aplicación podría haber emitido una consulta que depende de variables SQL del usuario, las cuales están vinculadas a una conexión específica. Tal conexión podría devolver resultados incorrectos si el complemento intercambia la conexión implícitamente como parte de la tolerancia a fallos automática. Para asegurase de obtener resultados correctos, la aplicación debe ocuparse de la tolerancia a fallos, y reconstruir el estado de conexión requerido. Por lo tanto, de forma predeterminada, el complemento no realiza la tolerancia a fallos automática.

Un usuario que no cambie el estado de la conexión después de abrir una conexión puede activar la tolerancia a fallos automática. Observe que la lógica de la tolerancia a fallos automática está limitada a intentos de conexión. La tolerancia a fallos automática no se utiliza para conexiones ya establecidas. No hay manera de ordenar al complemento que intente la toleranca a fallos con una conexión que ya ha sido establecida con MySQL anteriormente.

Tolerancia a fallos automática

La política de la tolerancia a fallos se configura en el fichero de configuración del complemento, usando la directiva de configuración failover.

La tolerancia a fallos automática y silenciosa se puede habilitar a través de la directiva de configuración failover. La tolerancia a fallos automática se puede configurar para intentarla en exactamente un maestro después del fallo de un esclavo, o, alternativamente, iterando sobre los esclavos y maestros antes de devolver un error al usuario. El número de intentos de conexión se puede limitar, y los equipos anfitriones fallidos se pueden excluir de los intentos de equilibrado de carga futuros. La limitación del número de reintentos y el recuerdo de los equipos anfitriones fallidos son considerados características experimentales, aunque son razonablemente estables. La sintaxis y la semántica puede cambiar en versiones futuras.

Observe que desde la versión 1.5.0 la tolerancia a fallos automática está deshabilitada durante una transacción si está habilitada la adhesión de transacciones y se han detectado los límites de la transacción. El complento no intercambiará conexiones durante una transacción. Tampoco realizará la tolerancia a fallos automática ni silenciosa. En su lugar se lanzará un error. Es entoces responsabilidad del usuario el manejo del fallo de una transacción. Por favor, consulte la documetación de trx_stickiness para saber cómo hacer esto.

Se proporciona un ejemplo básico de tolerancia a fallos manual en la sección manejo de errores.

Servidores de emergencia

Al usar el equilibrado de carga ponderado, introducido en PECL/mysqlnd 1.4.0, es posible configurar servidores de emergencia que son utilizados escasamente durante operaciones normales. A un servidor de emergencia que se usa principalmente como objetivo en el peor de los casos de tolerancia a fallos de emergencia se le puede asignar un peso o prioridad muy bajos en relación a los demás servidores. Siempre y cuando todos los servidores estén activos y la ejecución de la mayoría del trabajo sea asignada a los servidores que tienen valores de peso altos. Pocas peticiones serán redirigidas a un sistema de emergencia que tenga un valor de peso muy bajo.

Cuando ocurre un fallo en los servidores con una prioridad alta, aún se puede realizar la tolerancia a fallos en el sistema de emergencia, al cual se le ha dado una prioridad baja de equilibrado de carga asignándole un peso bajo. La tolerancia a fallos puede ser manual o automática. Si se realiza automáticamente se puede combinar con la opción remember_failed.

En este punto, no es posible ordenar al equilibrador de carga que no dirija ninguna petición al sistema de emergencia. Esto podría no ser una limitación dado que el mayor peso que se puede asignar a un servidor es 65535. Dados dos esclavos, uno de los cuales actuaría como de emergencia y al que se le ha asignado un peso de 1, el sistema de emergencia tendrá que manejar mucho menos del 1 por ciento del total del trabajo.

Tolerancia a fallos y copia primaria

Observe que si se utiliza un clúster de copia primario, tal como la Replicación MySQL, es difícil realizar la tolerancia a fallos de conexión en caso de que falle un maestro. En cualquier momento, sólo hay un maestro en el clúster para un conjunto de datos dado. El maestro es un único punto de fallo. Si el maestro falla, los clientes no tienen un objetivo donde realizar la tolerancia a fallos en peticiones de escritura. En caso de que un maestro apague la base de datos, el administrador debe ocuparse de la situación y actualizar la configuración del cliente, si fuera necesario.