Optimización del motor de almacenamiento de MySQL:configuración de la optimización de InnoDB para un alto rendimiento

InnoDB es uno de los motores de almacenamiento más utilizados en MySQL. Este motor de almacenamiento se conoce como un motor de almacenamiento de alta confiabilidad y alto rendimiento y sus ventajas clave incluyen el soporte de bloqueo a nivel de fila, claves externas y el seguimiento del modelo ACID. InnoDB reemplaza a MyISAM como el motor de almacenamiento predeterminado desde MySQL 5.5, que se lanzó en 2010.

Este motor de almacenamiento puede tener un rendimiento y una potencia increíbles si se optimiza correctamente. Hoy analizaremos las cosas que podemos hacer para que funcione al máximo de su capacidad, pero antes de sumergirnos Sin embargo, en InnoDB, debemos entender qué es el modelo ACID mencionado anteriormente.

¿Qué es ACID y por qué es importante?

ACID es un conjunto de propiedades de transacciones de bases de datos. El acrónimo se traduce en cuatro palabras:Atomicidad, Consistencia, Aislamiento y Durabilidad. En resumen, estas propiedades aseguran que las transacciones de la base de datos se procesen de manera confiable y garantizan la validez de los datos a pesar de errores, cortes de energía o cualquier problema similar. Se dice que un sistema de administración de bases de datos que se adhiere a estos principios es un DBMS compatible con ACID. Así es como funciona todo en InnoDB:

• La atomicidad asegura que las declaraciones en una transacción operen como una unidad indivisible y que sus efectos se vean colectivamente o no se vean en absoluto;
• La consistencia es manejada por los mecanismos de registro de MySQL que registran todos los cambios en la base de datos;
• El aislamiento se refiere al bloqueo de nivel de fila de InnoDB;
• La durabilidad también se mantiene porque InnoDB mantiene un archivo de registro que rastrea todos los cambios en el sistema.

Comprender InnoDB

Ahora que hemos cubierto ACID, probablemente deberíamos ver cómo se ve InnoDB debajo del capó. Así es como se ve InnoDB desde adentro (imagen cortesía de Percona):

De la imagen de arriba podemos ver claramente que InnoDB tiene algunos parámetros cruciales para su desempeño y estos son los siguientes:

• El parámetro innodb_data_file_path describe el tablespace del sistema (el tablespace del sistema es el área de almacenamiento para el diccionario de datos InnoDB, los búferes de doble escritura y cambio y los registros de deshacer). El parámetro representa el archivo donde se almacenarán los datos derivados de las tablas de InnoDB;
• El parámetro innodb_buffer_pool_size es un búfer de memoria que InnoDB usa para almacenar en caché datos e índices de sus tablas;
• El parámetro innodb_log_file_size representa el tamaño de los archivos de registro de InnoDB;
• El parámetro innodb_log_buffer_size se usa para escribir en los archivos de registro en el disco;
• El parámetro innodb_flush_log_at_trx_commit controla el equilibrio entre el cumplimiento estricto de ACID y un mayor rendimiento;
• El parámetro innodb_lock_wait_timeout es el tiempo en segundos que una transacción InnoDB espera por un bloqueo de fila antes de darse por vencida;
• El parámetro innodb_flush_method define el método utilizado para vaciar datos en archivos de datos InnoDB y archivos de registro que pueden afectar el rendimiento de E/S.

InnoDB también almacena los datos de sus tablas en un archivo llamado ibdata1; sin embargo, los registros se almacenan en dos archivos separados llamados ib_logfile0 e ib_logfile1:todos esos tres archivos residen en /var/lib/mysql directorio.

Para hacer que InnoDB tenga el mayor rendimiento posible, debemos ajustar estos parámetros y optimizarlos tanto como podamos observando nuestros recursos de hardware disponibles.

Ajuste de InnoDB para un alto rendimiento

Para ajustar el rendimiento de InnoDB en su hardware, siga estos pasos:

• Para extender innodb_data_file_path automáticamente, especifique el atributo autoextend en la configuración y reinicie el servidor. Por ejemplo:

innodb_data_file_path=ibdata1:10M:autoextend

Cuando se utiliza el parámetro de extensión automática, el archivo de datos aumenta automáticamente de tamaño en incrementos de 8 MB cada vez que se requiere un espacio. También se puede especificar un nuevo archivo de datos de extensión automática (en este caso, el nuevo archivo de datos se llama ibdata2):

innodb_data_file_path=ibdata1:10M;ibdata2:10M:autoextend

• Cuando se utiliza InnoDB, el principal mecanismo utilizado es el grupo de búfer. InnoDB depende en gran medida del grupo de búfer y, como regla general, el parámetro innodb_buffer_pool_size debe ser aproximadamente del 60 % al 80 % de la memoria RAM total disponible en el servidor. Tenga en cuenta que también debe dejar algo de RAM para los procesos que se ejecutan en el sistema operativo;

• Innodb_log_file_size de InnoDB debe configurarse lo más grande posible, pero no más grande de lo necesario. En este caso, tenga en cuenta que un tamaño de archivo de registro más grande es mejor para el rendimiento, pero cuanto más grande es, más tiempo de recuperación se requiere después de un bloqueo. Como tal, no existe una solución única para todos, pero se dice que el tamaño combinado de los archivos de registro debe ser lo suficientemente grande. Esto ayuda al servidor MySQL a trabajar regularmente en puntos de control y actividad de vaciado de disco. Esto ahorra demasiada CPU y disco IO y puede funcionar sin problemas durante su hora pico o actividad de alta carga de trabajo. Aunque el enfoque recomendado es probarlo y experimentarlo usted mismo y encontrar el valor óptimo usted mismo;

• El valor de innodb_log_buffer_size debe establecerse en al menos 16 M. Un búfer de registro grande permite que se ejecuten transacciones grandes sin necesidad de escribir el registro en el disco antes de que se confirmen las transacciones, lo que ahorra E/S del disco;

• Al ajustar innodb_flush_log_at_trx_commit, tenga en cuenta que este parámetro acepta tres valores:0, 1 y 2. Con un valor de 1, obtiene el cumplimiento de ACID y con los valores 0 o 2 obtiene más rendimiento, pero menos confiabilidad porque en ese caso las transacciones cuyos registros aún no se han vaciado al disco pueden perderse en un bloqueo;

• Para establecer innodb_lock_wait_timeout en un valor adecuado, tenga en cuenta que este parámetro define el tiempo en segundos (el valor predeterminado es 50) antes emitiendo el siguiente error y revirtiendo la declaración actual:

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

• En InnoDB, hay varios métodos de vaciado disponibles. De manera predeterminada, esta configuración se establece en "async_unbuffered" en máquinas con Windows si el valor se establece en NULL y en "fsync" en máquinas con Linux. Esto es lo que son los métodos y lo que hacen:

• También debe considerar habilitar la configuración innodb_file_per_table. Este parámetro está activado de forma predeterminada en MySQL 5.6 y superior. Este parámetro lo libera de los problemas de administración relacionados con las tablas de InnoDB al almacenarlas en archivos separados y evitar los diccionarios principales y las tablas del sistema inflados. Habilitar esta variable también evita enfrentar la complejidad de la recuperación de datos cuando una determinada tabla está dañada
• Ahora que modificó esta configuración según las instrucciones descritas anteriormente, ¡debería estar casi listo para comenzar! Sin embargo, antes de comenzar a ejecutar, probablemente debería vigilar el archivo más ocupado en toda la infraestructura de InnoDB:el ibdata1.

Tratando con ibdata1

Hay varias clases de información que se almacenan en ibdata1:

1. Los datos de las tablas InnoDB;
2. Los índices de las tablas InnoDB;
3. Metadatos de la tabla InnoDB;
4. Datos de control de concurrencia multiversión (MVCC);
5. El búfer de escritura doble:dicho búfer permite que InnoDB se recupere de páginas a medio escribir. El propósito de dicho búfer es evitar la corrupción de datos;
6. El búfer de inserción:InnoDB utiliza dicho búfer para almacenar actualizaciones en la misma página para que se puedan realizar de una vez y no una tras otra.

Cuando se trata de grandes conjuntos de datos, el archivo ibdata1 puede volverse extremadamente grande y esto puede ser el núcleo de un problema muy frustrante:el archivo solo puede crecer y, de manera predeterminada, no puede reducirse. Puede cerrar MySQL y eliminar este archivo, pero esto no se recomienda a menos que sepa lo que está haciendo. Cuando se elimina, MySQL no funcionará correctamente ya que el diccionario y las tablas del sistema se han ido, por lo que la tabla principal del sistema está dañada.

Para reducir ibdata1 de una vez por todas, siga estos pasos:

1. Descargar todos los datos de las bases de datos InnoDB. Puede usar mysqldump o mysqlpump para esta acción;
2. Eliminar todas las bases de datos excepto las bases de datos mysql, performance_schema e information_schema;
3. Detener MySQL;
4. Agregue lo siguiente a su archivo my.cnf:

   [mysqld]
   innodb_file_per_table = 1
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 25% of innodb_buffer_pool_size
   innodb_buffer_pool_size = up to 60-80% of available RAM.

5. Elimine los archivos ibdata1 e ib_logfile* (se volverán a crear en el próximo reinicio de MySQL);
6. Inicie MySQL y restaure los datos del volcado que realizó anteriormente. Después de realizar los pasos descritos anteriormente, el archivo ibdata1 seguirá creciendo, pero ya no contendrá los datos de las tablas de InnoDB; el archivo solo contendrá metadatos y cada tabla de InnoDB existirá fuera de ibdata1. Ahora, si va al directorio /var/lib/mysql, verá dos archivos que representan cada tabla que tiene con el motor InnoDB. Los archivos se verán así:
   1. demotable.frm
   2. demotable.ibd

El archivo .frm contiene el encabezado del motor de almacenamiento y el archivo .ibd contiene los datos de la tabla y los índices de su tabla.

Sin embargo, antes de implementar los cambios, asegúrese de ajustar los parámetros de acuerdo con su infraestructura. Estos parámetros pueden hacer o deshacer el rendimiento de InnoDB, así que asegúrese de vigilarlos en todo momento. ¡Ahora deberías estar listo para irte!

Resumen

Para resumir, optimizar el rendimiento de InnoDB puede ser un gran beneficio si desarrolla aplicaciones que requieren integridad de datos y alto rendimiento al mismo tiempo:InnoDB le permite cambiar la cantidad de memoria que el motor puede usar. consumir, cambiar el tamaño del archivo de registro, el método de descarga que usa el motor, etc. Estos cambios pueden hacer que InnoDB funcione extremadamente bien si se ajustan correctamente. Sin embargo, antes de realizar cualquier mejora, tenga cuidado con las consecuencias de sus acciones tanto para su servidor como para MySQL.

Como siempre, antes de optimizar algo para el rendimiento, realice (¡y pruebe!) copias de seguridad para que pueda restaurar sus datos si es necesario y siempre pruebe cualquier cambio en un servidor local antes de implementar los cambios en producción.