Nota: Requisitos de versión
Los niveles de servicio han sido introducidos en la versión 1.2.0-alpha de mysqlnd_ms. mysqlnd_ms_set_qos() requiere PHP 5.4.0 o posterior.
El complemento se puede usar con diferentes tipos de clústeres de bases de datos MySQL. Los diferentes clústeres pueden proporcionar diferentes niveles de servicios a las aplicaciones. Los niveles de servicios pueden ser agrupados por los niveles de consistencia de datos que se puedan alcanzar. El complemento está al tanto de la:
Dependiendo de cómo se use un clúster, puede ser posbile alcanzar niveles de servicios más altos que el predeterminado. Por ejemplo, una lectura desde un esclavo de replicación MySQL asíncrono es consistencia final. Así, uno podría decir que el nivel de consistencia predeterminado de un clúster de replicación MySQL es consistencia final. Sin embargo, si el maestro solamente es utilizado por un cliente para lectura y escritura durante una sesión, entonces se da la consistencia de sesión (lectura de sus escrituras). PECL mysqlnd 1.2.0 abstrae al usuario los detalles de la elección de un nodo apropiado para cualquiera de los niveles de servicios de arriba mencionados.
Los niveles de servicios se pueden establecer a través del filtro 'qualify-of-service' en el fichero de configuración del complemento y en tiempo de ejecución utilizando la función mysqlnd_ms_set_qos().
El complemento define los diferentes niveles de servicios como sigue:
La consistencia final es el servicio predeterminado proporcionado por un clúster asíncrono, como la clásica replicación MySQL. Una operación de lectura ejecutada en un nodo arbitrario puede o no devolver datos antiguos. El punto de vista de las aplicaciones de los datos es consistente final.
La consistencia de sesión se da si un cliente siempre puede leer sus propias escrituras. Un clúster de replicación MySQL asíncrona puede proporcionar consistencia de sesión si los clientes siempre usan el maestro después del la primera escritura, o nunca consultan un esclavo que aún no ha replicado la operación de escritura de los clientes.
La interpretación del complemento de la consistencia fuerte es que todos los cliente siempre ven las escrituras consignadas de todos los demás clientes. Esto es lo predeterminado cuando se usa el Clúster MySQL o cualquier otro clúster que ofrezca distribución de datos asíncrona.
Parámetros de los niveles de servicios
Los niveles de servicos de consistencia final y consistencia de sesión aceptan parámetros.
La consistencia final es el servicio proporcionado por la replicación MySQL clásica. De forma predeterminada, todos los nodos tienen derecho a peticiones de lectura. El parámetro opcional age puede ser proporcionado para filtrar nodos que se demoren más que un cierto número de segundos con respecto al maestro. El complemento utiliza SHOW SLAVE STATUS para medir la demora. Vea el manual de referencia de MySQL para aprender sobre la precición y fiabilidad del comando SHOW SLAVE STATUS.
La consistencia de sesión (lectura de sus escritura) acepta el parámetro opcional GTID para considerar la lectura no sólo desde el maestro, sino también desde los esclavos que ya han replicado una escritura en particular descrita por su identificador de transacciones. De esta forma, cuando se utiliza la replicación MySQL asíncrona, las peticiones de lectura pueden uar el equilibrado de carga sobre los esclavos mientras todavía se asegura la consistencia de sesión.
Lo último requiere el uso de la inyección de IDs de transacciones globales en el lado del cliente.
Ventajas de este nuevo enfoque
El nuevo enfoque sustituye el uso de sugerencias SQL y de la opción de configuración master_on_write en varios sentidos. Si una aplicicón se ejecuta en lo más alto de un clúster de replicación MySQL asíncrono, no puede acceptar datos antiguos para ciertas lecturas, es más sencillo indicarle al complemento que elija los nodos apropiados que prefijar todas las sentencias de lectura en cuestión con sugerencias SQL para forzar el uso del maestro. Además, el comlemento puede ser capaz de utilizar esclavos seleccionados para la lectura.
La opción de configuración master_on_write hace que el complemento use el maestro después de la primera escritura (consistencia de sesión, lectura de sus escrituras). En algunos casos, la consistencia de sesión puede no ser necesaria para el resto de la sesión, sólo para unas pocas operaciones de lectura. Así, master_on_write puede resultar en más carga de lectura en el maestro de la necesaria. En estos casos, es mejor solicitar un nivel de servicios superior al predeterminado solamente para aquellas lecturas que realmente lo necesiten. Una vez que las lecturas se han realizado, la apliacion puede vovler al nivel de servicios predetereminado. El cambio entre niveles de servicio solo es posible con el uso de mysqlnd_ms_set_qos().
Consideraciones de rendimiento
Un clúster de replicación MySQL no puede indicarle a los clientes qué esclavos son capaces de proporcionar cuales niveles de servicios. Por lo tanto, en algunos casos, los clientes necesitan consultar a los esclavos para comprobar sus estados. PECL mysqlnd_ms ejecuta de forma transparente el SQL necesario en segundo plano. Sin embargo, es una operación cara y lenta. Las sentencias SQL se ejecutan si se combina la consistencia final con una edad (demora del esclavo) límite y si la consistencia de sesión se combina con un ID de transacciones global.
Si la consistencia final se combina con una edad (demora del esclavo) máxima, el complemento seleccionará candidatos para la ejecución de sentencias y equilibrará la carga para cada sentencia como sigue. Si la sentencia es una escritura, todos los maestros son considerados como candidato. Los esclavos no se comprueban y no son considerados como candidatos. Si la sentencia es una lectura, el complemento ejecuta de forma transparente SHOW SLAVE STATUS en cada conexión esclava. Iterará sobre todas las conexiones, enviará la sentencia y luego iniciará la comprobación de los resultados. Normalmente, esto es ligeramente más rápido qe iterar sobre todas las conexiones en las que se envía una consulta para cada conexión y que el complemento espere sus resultados. Un esclavo es considerado un candidato si SHOW SLAVE STATUS notifica que Slave_IO_Running=Yes, Slave_SQL_Running=Yes y Seconds_Behind_Master es menor o igual que la edad máxima permitida. En caso de que ocurra un error SQL, el complemento emite una advertencia, aunque no establece un error en la conexión. Éste no se establece para que el complemento se pueda usar como atenuante.
Si la consistencia de sesión se combina con un ID de transacciones global, el complemento ejecutará la sentencia establecida con la entrada fetch_last_gtid de la sección global_transaction_id_injection del fichero de configuración del complemento. Los demás detalles son idénticos a los descritos arriba.
En la versión 1.2.0 no se realizan optimizaciones adicionales para ejecutar consultas en segundo plano. Futuras versiones pueden contener optimizaciones, dependiendo de la demanda de los usuarios.
Si no se establece ningún parámetro ni ninguna opción, no es necesaria ninguna sentencia SQL. En este caso, el complemento considera que todos los nodos son del tipo mostrado abajo.
Estrangulamiento
El filtro de calidad de servicio se puede combinar con IDs de transacciones globales para estrangular clientes. El estrangulamiento reduce la carga de escritura en el maestro desacelerando los clientes. Si se solicita la consistencia de sesión y se usa el identificador de transacciones global para comprobar el estado de un esclavo, esta comprobación se puede hacer de dos maneras. Por omisión, un esclavo se comprueba y se salta inmediatamente si no concuerda con el criterio de la consistencia de sesión. De forma alternativa, el complemento puede esperar a que un esclavo se ponga al día con el maestro hasta que la consistencia de sesión sea posible. Para habilitar el estrangulamiento se debe establecer la opción de configuración wait_for_gtid_timeout.