Los días de mayores compras en línea del año están a la vuelta de la esquina. ¿Está lista su base de datos? Al ajustar 20 variables clave del sistema MariaDB, reforzará el rendimiento de su base de datos , escalabilidad y disponibilidad , asegurando que cada cliente potencial tenga una experiencia de usuario fluida. Las siguientes variables del sistema aparecen repetidamente al configurar un entorno de servidor MariaDB óptimo. Implemente nuestras recomendaciones para obtener los valores más ajustados y haga que el período Black Friday-Cyber Monday de este año sea el mejor de todos.
Un par de notas importantes:
- No acepte estas sugerencias a ciegas. Cada entorno de MariaDB es único y requiere una reflexión adicional antes de realizar cualquier cambio. Lo más probable es que necesite ajustar esta configuración para su caso de uso y entorno específicos.
- El archivo de configuración de MariaDB se encuentra en /etc/my.cnf. Cada vez que modifique este archivo, deberá reiniciar el servicio MySQL para que los nuevos cambios surtan efecto.
20 recomendaciones de ajuste para Black Friday y Cyber Monday
El tamaño del grupo de búfer de InnoDB esta es la configuración n.º 1 que se debe tener en cuenta para cualquier instalación que use InnoDB. El grupo de búfer es donde se almacenan en caché los datos y los índices; tenerlo lo más grande posible garantizará que use memoria y no discos para la mayoría de las operaciones de lectura.
innodb_log-file-size es el tamaño de los registros de rehacer, que se utilizan para garantizar que las escrituras sean rápidas y duraderas. Hay dos sugerencias generales para el tamaño del archivo de registro de InnoDB:
- Establecer el tamaño total combinado de archivos de registro de InnoDB superior al 25-50 % del tamaño del grupo de búfer de InnoDB
o
- Establecer el tamaño de registro del archivo de registro de InnoDB combinado igual al valor de una hora de entradas de registro durante la carga máxima
Los archivos de registro más grandes pueden hacer que la recuperación sea más lenta en caso de que se bloquee el servidor. Sin embargo, también reducen la cantidad de puntos de control necesarios y reducen la E/S del disco.
Evalúe el tamaño de los registros binarios de una hora bajo carga operativa y luego decida si aumenta el tamaño de los archivos de registro de InnoDB.
Conseguir el tamaño correcto de los archivos de registro de innodb es importante para lograr un buen rendimiento del sistema. El motor de almacenamiento InnoDB de MariaDB utiliza un espacio de registro de rehacer de tamaño fijo (circular). El tamaño está controlado por innodb_log_file_size e innodb_log_files_in_group (predeterminado 2). Multiplique esos valores para obtener el espacio de registro de rehacer disponible para su uso. Si bien técnicamente no debería importar si usa la variable innodb_log_file_size o innodb_log_files_in_group para controlar el tamaño del espacio de rehacer, la mayoría de las personas solo trabajan con innodb_log_file_size y dejan innodb_log_files_in_group solo.
El tamaño del espacio de rehacer de InnoDB es una de las opciones de configuración más importantes para las cargas de trabajo de escritura intensiva. Sin embargo, viene con compensaciones. Cuanto más espacio de rehacer esté configurado, InnoDB podrá optimizar mejor la E/S de escritura. Sin embargo, aumentar el espacio de rehacer también significa tiempos de recuperación más prolongados cuando el sistema se queda sin energía o falla por otros motivos.
Un tamaño de búfer de registro de InnoDB más grande significa menos E/S de disco para transacciones más grandes. Se sugiere establecer esto en 64M en todos los servidores.
La variable innodb_flush_log_at_trx_commit controla cuándo se produce el vaciado del búfer de registro en el disco. innodb_flush_log_at_trx_commit =1 (predeterminado) vacía el búfer de registro en el disco en cada confirmación de transacción. Esta es la opción más segura, pero también la de menor rendimiento.
innodb_flush_log_at_trx_commit =0 vacía el búfer de registro en el disco cada segundo, pero nada en la confirmación de la transacción. Se podría perder hasta un segundo (posiblemente más debido a la programación del proceso). Si hay algún bloqueo, MySQL o el servidor pueden perder datos. Esta es la opción más rápida pero menos segura.
innodb_flush_log_at_trx_commit =2 escribe el búfer de registro en un archivo en cada confirmación, pero se descarga en el disco cada segundo. Si la memoria caché del disco tiene una batería de respaldo (por ejemplo, un controlador de incursión de caché respaldado por batería), este es generalmente el mejor equilibrio entre rendimiento y seguridad. Un bloqueo de MySQL no debería perder datos. Un bloqueo del servidor o un corte de energía podría perder hasta un segundo (posiblemente más debido a la programación del proceso). Una caché respaldada por batería reduce esta posibilidad.
Sugerimos usar la primera opción por seguridad.
innodb_io_capacity debe establecerse en aproximadamente la cantidad máxima de IOPS que puede manejar el almacenamiento subyacente.
De forma predeterminada, está configurado en 1000. Recomendamos comparar el almacenamiento para determinar si puede aumentar este valor aún más.
Supervisar el valor de Threads_created. Si continúa aumentando a más de unos pocos subprocesos por minuto, aumente el valor de thread_cache_size.
El tamaño de caché de subprocesos se establece en 200 en la configuración predeterminada actual.
Las variables table_open_cache y table_definition_cache controlan el número de tablas y definiciones que se mantienen abiertas para todos los subprocesos.
Supervise Open_tables, Open_table_definitions, Opened_tables y Opened_table_definitions para determinar el mejor valor. La sugerencia general es establecer table_open_cache (y, posteriormente, table_definition_cache) solo lo suficientemente alto como para reducir la tasa de aumento del valor de estado Opened_tables (y Opened_table_definitions).
Tanto table_open_cache como table_definition_cache están establecidos en 2048 en la configuración predeterminada.
La caché de consultas es un cuello de botella bien conocido que se puede ver incluso cuando la simultaneidad es moderada. La mejor opción es deshabilitarlo desde el primer día configurando query_cache_size =0 (el valor predeterminado en MariaDB 10) y usar otras formas de acelerar las consultas de lectura:tener una buena indexación, agregar réplicas para distribuir la carga de lectura o usar un caché externo ( memcache o redis, por ejemplo). Si ya creó su aplicación MariaDB con la caché de consultas habilitada y nunca notó ningún problema, la caché de consultas puede ser beneficiosa para usted. En ese caso, tenga cuidado si decide desactivarlo.
MySQL usa el menor de max_heap_table_size y tmp_table_size para limitar el tamaño de tablas temporales en la memoria. Estas son por variables de cliente. Si bien tener este valor grande puede ayudar a reducir la cantidad de tablas temporales creadas en el disco, también aumenta el riesgo de alcanzar la capacidad de memoria del servidor, ya que esto es por cliente. Generalmente, 32M a 64M es el valor sugerido para comenzar con ambas variables y ajústelo según sea necesario.
Las tablas temporales a menudo se usan para GROUP BY, ORDER BY, DISTINCT, UNION, subconsultas, etc. Idealmente, MySQL debería crearlas en la memoria, con la menor cantidad posible en el disco.
Es importante tener en cuenta que las consultas que no usan uniones de forma adecuada y que crean tablas temporales grandes pueden ser una de las razones de una mayor cantidad de tablas temporales en el disco. Otra razón es que el motor de almacenamiento de memoria usa columnas de longitud fija y asume el peor de los casos. Si las columnas no tienen el tamaño correcto (por ejemplo, un VARCHAR(255) para una cadena corta), esto influye en el tamaño de la tabla en la memoria y puede hacer que vaya al disco antes de lo que debería. Además, las tablas temporales con columnas de blob y de texto se guardarán inmediatamente en el disco, ya que el motor de almacenamiento de memoria no las admite.
Ambos están configurados actualmente en 64M de forma predeterminada.
Recomendamos establecer el nivel de registro de advertencia en log_warnings =2. Al hacerlo, se registra información sobre conexiones anuladas y errores de acceso denegado.
Si a menudo se encuentra con el error "Demasiadas conexiones", el valor de max_connections es demasiado bajo. Con frecuencia, debido a que la aplicación no cierra correctamente las conexiones a la base de datos, necesita mucho más que las 151 conexiones predeterminadas. El principal inconveniente de los valores altos para max_connections (por ejemplo, 1000 o más) es que el servidor dejará de responder si debe ejecutar tantas transacciones activas. El uso de un grupo de conexiones en el nivel de la aplicación o un grupo de subprocesos en el nivel de MariaDB puede ayudar aquí.
Investigue los niveles de aislamiento de transacciones disponibles y determine el mejor aislamiento de transacciones para el caso de uso de su servidor.
Recomendamos usar el formato de registro binario ROW para la replicación maestro-maestro.
Para ayudar a reducir las posibilidades de colisión entre dos maestros que se escriben simultáneamente, los valores de incremento automático y compensación de incremento automático deben ajustarse en consecuencia.
De forma predeterminada, el sistema operativo maneja el vaciado del binlog en el disco. En caso de que se bloquee el servidor, es posible que se pierdan transacciones del registro binario, lo que provocaría que la replicación no esté sincronizada. Establecer sync_binlog =1 hace que el archivo binlog se vacíe en cada confirmación.
Esta es la opción más lenta, pero la más segura.
Para ayudar a evitar errores de replicación después de un bloqueo del esclavo, habilite la recuperación del registro de retransmisión y la sincronización del registro de retransmisión y los archivos de información del registro de retransmisión en el disco.
Para tener una replicación encadenada (maestro -> esclavo -> esclavo), se debe habilitar log_slave_updates. Esto le dice a un esclavo que escriba transacciones replicadas en su propio registro binario para que luego puedan replicarse a los esclavos fuera de él.
Los esclavos deben ser de solo lectura para evitar que se escriban datos accidentalmente en ellos.
Nota :Los usuarios con superprivilegios aún pueden escribir cuando el servidor es de solo lectura.
La variable slave_net_timeout es la cantidad de segundos que el esclavo esperará un paquete del maestro antes de intentar volver a conectarse. El valor predeterminado es 3600 (1 hora). Esto significa que si el enlace se cae y no se detecta, podría pasar hasta una hora antes de que el esclavo se vuelva a conectar. Esto podría llevar a que el esclavo esté de repente hasta una hora por detrás del maestro.
Recomendamos establecer slave_net_timeout en un valor más razonable, como 30 o 60.
Vea nuestro seminario web a pedido:Preparación para el Black Friday y el Cyber Monday para conocer los cuatro principios vitales de la preparación de bases de datos: medidas de seguridad para proteger su base de datos de ataques maliciosos, ajuste de rendimiento para asegurarse de ofrecer una experiencia de usuario fluida, estrategias de alta disponibilidad para asegurarse de no perderse una sola venta y escalabilidad para prepararse tanto para el crecimiento anticipado como para los picos inesperados.
