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 sustituto.
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.