Herramienta de optimización del rendimiento: análisis del nuevo esquema del sistema de funciones de MySQL 5.7

Herramienta de optimización del rendimiento: análisis del nuevo esquema del sistema de funciones de MySQL 5.7

Introducción: Muchos equipos están evaluando el momento adecuado para cambiar a MySQL 5.7. Este artículo es un intercambio de Li Chun en el grupo de arquitectura de alta disponibilidad, presentando la nueva herramienta de análisis de rendimiento de MySQL 5.7.

Li Chun, el actual responsable de MySQL en Woqu Technology, un experto en bases de datos MySQL, ha estado involucrado en el desarrollo, operación y mantenimiento de MySQL durante 8 años. Durante el papel de Alibaba como líder de la base de datos MySQL, fue el principal responsable de la optimización y la implementación de la arquitectura de la aplicación, y se dio cuenta de la migración sin problemas de los 300 millones de productos de Alibaba de miniordenadores Oracle a 64 MySQL. Concéntrese en investigar los campos relacionados con la replicación de MySQL, alta disponibilidad, distribución y automatización de operación y mantenimiento. Tiene una amplia experiencia en la administración, ajuste, posicionamiento rápido y resolución de problemas de clústeres MySQL distribuidos a gran escala. Administre más de 1400 servidores MySQL y casi 3000 instancias. Documentos estandarizados completos y herramientas de operación y mantenimiento automatizadas, como el sistema de instalación automática MySQL, los documentos y manuales de operación estandarizados de Alibaba MySQL, el sistema de inspección regulatoria automática MySQL y el sistema de recopilación de información automática MySQL.

Derivado del esquema sys

Introducción al esquema de rendimiento

Oracle ya ha tenido una serie de herramientas para diagnosticar el rendimiento de la base de datos como v $. MySQL DBA solo puede envidiarlo y odiarlo, pero el esquema sys introducido en 5.7 alivia este problema, permitiéndonos ver la pérdida de rendimiento de MySQL y diagnosticar a través del esquema sys. Varios problemas con MySQL.

Cuando se trata de diagnosticar problemas de rendimiento de MySQL, debo mencionar el performance_schema introducido en MySQL 5.5. Cuando se introdujo por primera vez, el performance_schema de MySQL consume mucho rendimiento. Con la actualización de la versión y la optimización del código, el performance_schema de 5.7 consume más y más consumo extra en el servidor MySQL. Podemos abrir performance_shema de forma segura para recopilar la pérdida de rendimiento de la base de datos MySQL. Tarique Saleem ha probado el consumo adicional de CPU e IO por esquema sys, que se encuentra básicamente entre el 1% -3%. Los interesados ​​pueden consultar su blog:

（CPU enlazada, modo de solo lectura de Sysbench）

http://mysqlserverteam.com/performance-schema-great-power-comes-without-great-cost/

performance_schema no solo es famoso por su consumo de rendimiento, sino también por su complejidad y dificultad de uso. Ya hay 87 tablas en el esquema de rendimiento en 5.7, y cada tabla es una lista de información estadística diversa; además, sus tablas y algunas tablas en el esquema de información tampoco están claras, lo que hace que todos se sientan muy incómodos con ellas.

esquema sys VS esquema de rendimiento VS esquema de información

Ahora MySQL ha agregado un esquema sys en 5.7. ¿Cuál es la relación entre este y el esquema de rendimiento y el esquema de información?

• El posicionamiento del esquema de información es básicamente información de metadatos de MySQL, como: TABLES registra qué tablas tiene MySQL y COLUMNS registra qué columnas tiene cada tabla.
• performance_schema registra el consumo de rendimiento de bajo nivel en tiempo real de MySQL, por ejemplo: events_waits_current registra los eventos que están esperando actualmente para cada hilo de MySQL.

Aunque la diferencia de posicionamiento entre ellos no es tan obvia: por ejemplo, innodb_locks de Information_schema registra la información de bloqueo actual de innodb, que no es la información de metadatos de MySQL. El esquema sys fue introducido por primera vez en MySQL por Mark Leith para la conveniencia de leer y diagnosticar el rendimiento de MySQL. Por lo tanto, el posicionamiento del esquema sys debería ser el más claro: contiene una serie de objetos que pueden ayudar a los administradores de bases de datos y desarrolladores a comprender los datos recopilados por el esquema de rendimiento y el esquema de información.

¿Qué contiene el esquema sys?

El esquema sys contiene algunos objetos, que se utilizan principalmente para el ajuste y el análisis de fallas. incluir:

• Resuma los datos en el esquema de rendimiento y el esquema de información en una "vista" más fácil de entender.
• Proporcionar el esquema de rendimiento y la configuración del esquema de información o generar informes de análisis operaciones similares "procedimientos almacenados"
• El esquema del sistema en sí no recopila ni almacena ninguna información, solo proporciona una "interfaz" más conveniente para que el programa o el usuario diagnostique el rendimiento del sistema y solucione problemas. En otras palabras, consultar el esquema de rendimiento y la configuración del esquema de información y proporcionar un servicio de formato "función de almacenamiento".
• Evite que los usuarios escriban varias consultas complejas en el esquema de información y el esquema de rendimiento para obtener quién bloqueó cuál, cuánta memoria consume cada hilo (ver memory_by_thread_by_current_bytes), cuántas veces se ejecuta cada SQL y cuál es el tiempo de ejecución aproximado (Ver declaraciones_con_tiempos_de_servicio_en_95th_percentile) etc., estos esquemas de sistema están escritos para usted directamente, solo necesita consultar directamente.
• Algunos procedimientos almacenados listos para usar están escritos para su conveniencia: use directamente el procedimiento almacenado diagnostics () para crear un informe para diagnosticar el estado actual del servidor; use el procedimiento almacenado ps_trace_thread () para crear datos de rendimiento gráficos (tipo .dot) del hilo correspondiente.
• Algunas funciones de almacenamiento listas para usar están escritas para su conveniencia: use directamente la función de almacenamiento ps_thread_account () para obtener el usuario que inició este hilo, y use ps_thread_trx_info () para obtener la transacción actual o el historial de declaraciones ejecutadas de un hilo (devuelto en formato JSON).

Por supuesto, también puede agregar sus propias "vistas", "procedimientos almacenados" y "funciones almacenadas" para diagnosticar el rendimiento de MySQL bajo el esquema sys.

ejemplo de esquema sys

¿Cómo utilizar el esquema sys para localizar problemas y diagnosticar el rendimiento de la base de datos? Aquí hay un ejemplo simple de bloqueo de fila innodb para ilustrarlo.

Simular bloqueo de fila

Tomemos un escenario real, el esquema sys puede ayudarnos a analizar qué sesión de la base de datos actual está bloqueada y proporcionar una declaración para "limpiar" el bloqueo. Simulamos la situación en la que una fila de una tabla está bloqueada, asumiendo que la declaración de creación de la tabla es la siguiente:

CREATE TABLE test2(
idint (11) NOT NULL,
namevarchar (16) DEFAULT NULL,
ageint (11) DEFAULT NULL,
sexint (11) DEFAULT NULL,
PRIMARY KEY ( id)
) ENGINE = InnoDB DEFAULT CHARSET = latin1

Hay un dato de la siguiente manera:

mysql> seleccionar * de test2;
+ ---- + --------- + ------ + ------ +
| id | nombre | edad | sexo |
+ ---- + --------- + ------ + ------ +
| 2 | pickup1 | 1 | 1 |
+ ---- + --------- + ------ + ------ +

Operamos con estos datos al mismo tiempo en la sesión 1 y la sesión 2, de modo que la misma fila de registros debe estar bloqueada entre sí, y luego usamos la sesión 3 para verificar innodb_lock_waits en el esquema sys para determinar quién está bloqueando a quién. ¿Como desbloquear? Los pasos son los siguientes:

Verifique la tabla de bloqueo innodb a través de sys.innodb_lock_waits

Registros correspondientes vistos en la sesión 3:

mysql> SELECT * FROM sys.innodb_lock_waits \ G
1. fila
wait_started: 2016-05-04 01:04:38
wait_age: 00:00:02
wait_age_secs: 2
locked_table: test. test2
índice_bloqueado: PRIMARY
tipo_bloqueado: RECORD
esperando_trx_id: 5382
esperando_trx_iniciado: 2016-05-04 00:24:21
esperando_trx_edad: 00:40:19
esperando_trx_rows_bloqueado: 4
esperando_trx_rows_modificado: 0
esperando_pid: 3
esperando_query: actualizar test2 set name = 'pickup3' donde id = 2
waiting_lock_id: 5382: 31: 3: 3
waiting_lock_mode: X
blocking_trx_id: 5381
blocking_pid: 2
blocking_query: NULL
blocking_lock_id: 5381: 31: 3: 3
blocking_lock_mode: X
blocking_trx_started: 05/04/2016 00:23:49
blocking_trx_age: 00:40:51
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_kill_blocking_query: matar CONSULTA 2
sql_kill_blocking_connection: Mata 2

Aquí podemos ver que el hilo 3 (esperando_pid: 3) está esperando el bloqueo X (modo_bloqueo_bloqueo: X) del hilo 2 (bloqueo_pid: 2). Si necesita desbloquearlo, necesita matar el hilo 2 (sql_kill_blocking_connection: KILL 2).

innodb_lock_waits esencia

De hecho, innodb_lock_waits del esquema sys es solo una vista del esquema de información.

CREAR ALGORITMO = DEFINIR TEMPTABLE = mysql.sys@ localhostINVOCADOR DE SEGURIDAD SQL VER innodb_lock_waitsCOMO
SELECCIONAR
r. trx_wait_startedAS wait_started,
TIMEDIFF (NOW (),
r. trx_wait_started) AS wait_age,
TIMESTAMPDIFF (
SEGUNDO,
r. trx_wait_started,
NOW ()) AS wait_age_secs,
rl. lock_tableAS locked_table,
rl. lock_indexAS locked_index,
rl. lock_typeAS locked_type,
r. trx_idAS waiting_trx_id,
r. trx_startedAS waiting_trx_started,
TIMEDIFF (NOW (),
r. trx_started) AS waiting_trx_age,
r. trx_rows_lockedAS waiting_trx_rows_locked,
r. trx_rows_modifiedAS waiting_trx_rows_modified,
r. trx_mysql_thread_idAS waiting_pid,
sys. format_statement( r.trx_query) AS waiting_query,
rl. lock_idAS waiting_lock_id,
rl. lock_modeAS waiting_lock_mode,
b. trx_idAS blocking_trx_id,
b. trx_mysql_thread_idAS blocking_pid,
sys. format_statement( b. trx_query) AS blocking_query,
bl. lock_idAS blocking_lock_id,
bl. lock_modeAS blocking_lock_mode,
b. trx_startedAS blocking_trx_started,
TIMEDIFF (NOW (),
b. trx_started) AS blocking_trx_age,
b. trx_rows_lockedAS blocking_trx_rows_locked,
b. trx_rows_modifiedAS blocking_trx_rows_modified,
CONCAT (
'Kill QUERY',
b. trx_mysql_thread_id
) AS sql_kill_blocking_query,
CONCAT ( 'matar',
b. trx_mysql_thread_id) AS sql_kill_blocking_connection
DE
(
(
(
(
information_schema. innodb_lock_waits w
UNIRSE
information_schema.innodb_trx bEN (( b. trx_id= w. blocking_trx_id))
)
ÚNETE
information_schema. innodb_trx rEN (
( r. trx_id= w. requesting_trx_id)
)
)
ÚNETE
information_schema. innodb_locks blEN (
(
bl. lock_id= w. blocking_lock_id
)
)
)
ÚNETE
information_schema. innodb_locks rlON (
(
rl. lock_id= w. requested_lock_id
)
)
)
ORDEN POR
r.trx_wait_started

innodb_lock_waits 和 x \ $ innodb_lock_waits 区别

Los estudiantes interesados ​​pueden notar que hay innodb_lock_waits y x \ $ innodb_lock_waits en el esquema sys. De hecho, la mayoría de estas vistas del esquema sys aparecen en pares, y el nombre de una de ellas es exactamente igual que la otra excepto por el prefijo x \ $. Por ejemplo, la vista host_summmary_by_file_io analiza y resume la situación de E / S del archivo resumida por el host, y muestra el retraso de picosegundos (picosegundos) a un valor más legible (con unidades):

mysql> SELECT * FROM host_summary_by_file_io;
+ ------------ + ------- + ------------ +
| anfitrión | ios | io_latency |
+ ------------ + ------- + ------------ +
| localhost | 67570 | 5,38 s |
| fondo | 3468 | 4,18 s |
+ ------------ + ------- + ------------ +

La vista x \ $ host_summary_by_file_io analiza y resume los mismos datos, pero muestra el valor de retraso de picosegundos (picosegundos) sin formato.

mysql> SELECCIONAR * DE x $ host_summary_by_file_io;
+ ------------ + ------- + --------------- +
| anfitrión | ios | io_latency |
+ ------------ + ------- + --------------- +
| localhost | 67574 | 5380678125144 |
| fondo | 3474 | 4758696829416 |
+ ------------ + ------- + --------------- +

La vista sin el prefijo x \ $ es para proporcionar un formato de salida más amigable y legible por humanos. La vista con el prefijo x \ $ muestra el formato original de los datos, lo cual es conveniente para que otras herramientas realicen su propio procesamiento basado en los datos. Se necesita más información para comprender la diferencia entre las vistas que no son x \ $ y x \ $.

Preguntas y respuestas

Pregunta: ¿El esquema sys solo crea vistas y procedimientos almacenados además de performance_schema e information_schema?
Li Chun: Sí, el esquema sys es principalmente para el esquema de rendimiento, y algunas tablas de esquema de información también se organizarán y mostrarán en el esquema sys.

Pregunta: ¿Ejecuta KILL 2 para matar 2 hilos? block_lock_mode: ¿Qué significa X?
Li Chun: La X en modo_bloqueo_bloqueo se refiere a bloqueos X, bloqueos exclusivos y bloqueos exclusivos. Correspondientes a él son bloqueos S, bloqueos compartidos. Matar 2 mata el hilo 2 para que el bloqueo se pueda liberar y el hilo bloqueado se pueda ejecutar normalmente.

Pregunta: Puede abrir performance_schema de forma segura, ¿por qué no usar performance_schema para crear un esquema sys?
Li Chun: el esquema de rendimiento es el espacio de almacenamiento donde MySQL recopila el rendimiento de la base de datos. El esquema sys en realidad es simplemente unir e integrar varias tablas en el esquema de rendimiento. El posicionamiento de los dos es diferente, si se colocan directamente en el esquema de ejecución, es difícil distinguir cuáles son las tablas base y cuáles son las vistas, lo que resultará más confuso.

Pregunta: ¿Alguna de estas herramientas pt-query-digest ha comenzado a utilizar el esquema sys?
Li Chun: No. pt-query-digest se utiliza principalmente para analizar los resultados de la búsqueda lenta y tcpdump. Existe cierta superposición con el posicionamiento del esquema sys. El esquema sys se analizará con más detalle, más núcleo y más bajo nivel, pt- query-digest extrae principalmente SQL de búsquedas lentas y tcpdump para formatear y mostrar.

Pregunta: ¿Qué herramientas de operación y mantenimiento usa Ali con tantas instancias de bases de datos? ¿Cómo se resuelven las transacciones distribuidas?
Li Chun: Hay muchas herramientas de operación y mantenimiento en Ali, como dbfree, idb, etc., que se utilizan para la gestión del grupo de recursos de la base de datos, la desensibilización de la base de datos, el desarrollo y la sincronización de la base de datos de prueba, la corrección de la base de datos, el cambio de estructura de la tabla, etc. Las transacciones distribuidas se protegen principalmente mediante modificaciones comerciales. Por ejemplo, comprar entradas para una película no significa que tenga que elegir un asiento y el pago debe realizarse en una sola transacción. La obtención de entradas, la selección de asientos y el pago son sus propias subtransacciones. Acoplamiento del sistema Notificación mutua relativamente débil para resolver el problema.

Pregunta: ¿Oracle tiene v $ y MySQL tiene x $? ¿Dos $ cumplen funciones similares?
Li Chun: Se puede decir que x $ de MySQL está modelado a partir de v $ de Oracle, pero todavía hay cierta distancia de la poderosa función de diagnóstico de la base de datos de Oracle.

Pregunta: ¿Puede presentar brevemente la implementación de la desensibilización de la base de datos?
Li Chun: Los desarrolladores y evaluadores no pueden acceder a la base de datos en línea, necesitan acceder a ella a través de un idb especial, y cada campo del sistema idb tiene una definición de nivel secreto, y solo se puede acceder a aquellos que cumplen con la autoridad; esta página del sistema controla si los usuarios pueden acceder a un determinado Tabla, puede acceder al número de filas de la tabla de datos, solo el supervisor está de acuerdo, el usuario puede acceder a los datos de una tabla y los datos cifrados se muestran con *.

Lectura relacionada

(Haga clic en el título para leer directamente)

• MySQL 5.7 nuevas funciones y perspectivas futuras
• ¿Por qué Uber anunció el cambio de Postgres a MySQL?

El editor de este artículo Wang Jie, los artículos técnicos originales son bienvenidos a enviar a través del menú "Contáctenos" de la cuenta oficial. Las contribuciones incluyen artículos de arquitectura técnica, nuevas tecnologías y nuevas prácticas. Los artículos aprobados se publicarán en cuentas públicas de arquitectura de alta disponibilidad, Weibo, Toutiao y otros medios. Las contribuciones deben acordar que el artículo relevante se publique primero en la arquitectura de alta disponibilidad. Indique que es de la cuenta oficial de WeChat del marco de alta disponibilidad "ArchNotes" e incluya el siguiente código QR.

Arquitectura de alta disponibilidad

Cambiando la forma en que se construye Internet