Control de flujo Percona XtraDB Cluster

Control de flujo Percona XtraDB Cluster

Charla de operación y mantenimiento para principiantes de Scofield

¿Qué es el control de flujo?


Percona XtraDB Cluster tiene un mecanismo de autorregulación llamado control de flujo. Este mecanismo ayuda a evitar situaciones en las que el miembro más débil o más lento del clúster está significativamente por detrás de los demás miembros del clúster.
Cuando los miembros del clúster escriben datos lentamente (mientras continúan recibiendo conjuntos de escritura del canal del grupo del clúster), el tamaño de la cola de entrada / recepción aumentará. Si esta cola excede el umbral establecido (gcs.fc_limit), el nodo enviará un mensaje FLOW_CONTROL, solicitando a otros miembros que ralenticen o suspendan el procesamiento.

gcs.fc_limit


Esta configuración controla cuando el control de flujo está habilitado. En resumen, si wsrep_local_recv_queue excede este tamaño en un nodo dado, se enviará un mensaje de control de flujo suspendido.
fc_limit tiene como valor predeterminado 16 transacciones. Esto significa efectivamente que esto puede colocar un nodo determinado detrás de la transacción de confirmación del clúster.

gcs.fc_master_slave


Si fc_master_slave está deshabilitado (por defecto), fc_limit se modificará dinámicamente. En realidad, este modo ajusta dinámicamente fc_limit según el número de nodos del clúster. Cuantos más nodos haya en el clúster, mayor será el fc_limit calculado. La teoría detrás de esto es que cuanto mayor sea la escala obtenida por el clúster (y posiblemente cuanto más ocupadas sean las operaciones de escritura de más nodos), más lejos estará el espacio de aplicación de cada nodo.

Si solo escribe en un solo nodo en PXC, se recomienda que desactive esta función configurando fc_master_slave = YES. Independientemente de si el tamaño de fc_limit se ajusta dinámicamente, esta configuración es en realidad solo un cambio. No tiene ninguna otra capacidad que pueda ayudar a un solo nodo en PXC a mejorar las capacidades de escritura.

gcs.fc_factor


Si fc_limit controla cuando el control de flujo está habilitado, entonces fc_factor se direcciona cuando se libera. El coeficiente es un número entre 0.0 y 1.0, que se multiplica por el fc_limit actual (si fc_master_slave = NO, ajústelo mediante el cálculo anterior). Esto da como resultado que la cola de recepción debe reducirse al número de transacciones por debajo del nivel de transacción antes de que el nodo envíe otro mensaje de control de flujo, lo que otorga al clúster el derecho a continuar la replicación.
fc_factor tiene un valor predeterminado de 0.5, lo que significa que la cola debe caer por debajo del 50% de fc_limit antes de reanudar la replicación. En este caso, un fc_limit mayor puede significar que debe esperar mucho tiempo antes de poder relajar el control de flujo nuevamente. Sin embargo, recientemente este valor se cambió al valor predeterminado de 1.0 para permitir que la replicación se reanude lo antes posible.

Para el usuario final, el control de flujo es transparente, pero para el administrador del clúster, es importante saber si el nodo está usando el control de flujo. Si es así, afectará la productividad de todo el clúster.

Encuentre si el nodo está en control de flujo


FLOW_CONTROL no es un estado persistente. Una vez que el tamaño de la cola excede el umbral establecido, el nodo ingresará FLOW_CONTROL. Una vez que el tamaño de la cola regrese por debajo de la marca de agua de gama baja, se liberará nuevamente.

Cómo mirar umbrales más altos y más bajos

A partir de Percona XtraDB Cluster 5.7.17-29.20, ahora puede ver los umbrales inferior y superior a través de MOSTRAR ESTADO:


mysql> show status like 'wsrep_flow_control_interval';
+-----------------------------+----------------+
| Variable_name               | Value          |
+-----------------------------+----------------+
| wsrep_flow_control_interval | [ 3547, 3547 ] |
+-----------------------------+----------------+
1 row in set (0.01 sec)

Como puede ver, la variable de estado wsrep_flow_control_interval emite un rango que representa niveles más bajos y más altos. El valor establecido (3547, 3547) significa que si el tamaño de la cola entrante es mayor que 3547, FLOW_CONTROL está habilitado. Si el tamaño es menor que 3547, suelte FLOW_CONTROL.

Sin embargo, esto todavía no puede mostrar si el nodo está usando FLOW_CONTROL en un momento dado.

Para resolver este problema, PXC también introdujo la variable de estado wsrep_flow_control_status en la versión. Esta variable de estado booleana le dice al usuario si el nodo está en FLOW_CONTROL. Una vez que el nodo está fuera de control de flujo, cuando el nodo adopta el control de flujo, la variable se cambiará a APAGADO, de lo contrario estará ENCENDIDO:


mysql> show status like '%flow%';
+-------------------------------------------------------+----------------+
| Variable_name                                         | Value          |
+-------------------------------------------------------+----------------+
| Innodb_scrub_background_page_split_failures_underflow | 0              |
| Ssl_session_cache_overflows                           | 370780         |
| Table_open_cache_overflows                            | 0              |
| wsrep_flow_control_paused_ns                          | 7056357841773  |
| wsrep_flow_control_paused                             | 0.000901       |
| wsrep_flow_control_sent                               | 0              |
| wsrep_flow_control_recv                               | 176            |
| wsrep_flow_control_interval                           | [ 3547, 3547 ] |
| wsrep_flow_control_interval_low                       | 3547           |
| wsrep_flow_control_interval_high                      | 3547           |
| wsrep_flow_control_status                             | OFF            |
+-------------------------------------------------------+----------------+

Finalmente, el contador wsrep_flow_control_sent / recv se puede usar para rastrear el estado de FLOW_CONTROL. Esto muestra el número total de inicios de control de flujo. Puede utilizar FLUSH STATUS para borrarlos.


mysql> show global status like 'wsrep_flow%';
+----------------------------------+----------------+
| Variable_name                    | Value          |
+----------------------------------+----------------+
| wsrep_flow_control_paused_ns     | 6893631531679  |
| wsrep_flow_control_paused        | 0.000413       |
| wsrep_flow_control_sent          | 5366           |
| wsrep_flow_control_recv          | 5369           |
| wsrep_flow_control_interval      | [ 3547, 3547 ] |
| wsrep_flow_control_interval_low  | 3547           |
| wsrep_flow_control_interval_high | 3547           |
| wsrep_flow_control_status        | OFF            |
+----------------------------------+----------------+

mysql> flush status

mysql> show global status like 'wsrep_flow%';
+----------------------------------+----------------+
| Variable_name                    | Value          |
+----------------------------------+----------------+
| wsrep_flow_control_paused_ns     | 6893631531679  |
| wsrep_flow_control_paused        | 0.000413       |
| wsrep_flow_control_sent          | 0           |
| wsrep_flow_control_recv          | 0           |
| wsrep_flow_control_interval      | [ 3547, 3547 ] |
| wsrep_flow_control_interval_low  | 3547           |
| wsrep_flow_control_interval_high | 3547           |
| wsrep_flow_control_status        | OFF            |
+----------------------------------+----------------+

PD: el artículo se sincronizará con dev.kubeops.net

Supongo que te gusta

Origin blog.51cto.com/15060545/2656505
Recomendado
Clasificación