MariaDB Server, conocida abreviadamente como MariaDB, es una base de datos de código abierto creada por los fundadores de MySQL. Tiene raíces similares a Percona Server para MySQL, pero se está apartando rápidamente de la compatibilidad con MySQL y creciendo por sí sola. Se ha convertido en la instalación de serie para varios Sistemas Operativos. Los cambios en las variables predeterminadas pueden marcar una gran diferencia en el rendimiento de la base de datos, por lo que conocer sus diferencias es importante.
Como MariaDB crece por sí sola y no es 100% compatible con MySQL, la configuración que trae por defecto puede no comportarse de la misma manera en que solía hacerlo. Puede usar diferentes nombres de variable o implementar las mismas variables de nuevas maneras. También debemos tener en cuenta que MariaDB utiliza su propio motor de almacenamiento Aria, que tiene muchas opciones de configuración que no existen en MySQL.
En este artículo, buscaremos variables comunes tanto para MySQL como para MariaDB, pero hay diferentes valores por defecto, no variables que son específicas de MySQL o MariaDB (excepto por los diferentes switches dentro de optimizer_switch).
Registros Binarios
MySQL ha adoptado una postura más conservadora cuando se trata del registro binario. En las versiones más recientes de MySQL 5.7, han actualizado dos variables para ayudar a garantizar que todos los datos aceptados permanezcan intactos e idénticos. Binlog_format ha sido actualizada a ROW en MySQL para evitar que las declaraciones no deterministas tengan resultados diferentes en el esclavo. Por el contrario, MariaDB tiene el formato mixto (MIXED) como predeterminado. Este utiliza un formato basado en declaraciones a menos que se cumplan ciertos criterios. En ese caso, usa el formato ROW.La otra diferencia que puede causar un impacto significativo en el rendimiento se relaciona con sync_binlog. Sync_binlog controla el número de grupos de compromiso que se deben recopilar antes de sincronizar el registro binario con el disco. MySQL ha cambiado su valor a 1, lo que significa que cada transacción se vacía en el disco antes de aceptarse. Esto garantiza que nunca puede haber una transacción aceptada que no se haya registrado (incluso durante un fallo del sistema). Esta decisión puede crear un gran impacto en el rendimiento, tal y como dice Roel Van de Paar en su artículo.
MariaDB utiliza el valor 0 para sync_binlog, lo que permite que el Sistema Operativo determine cuándo se debe limpiar el binlog. Esto proporciona un mejor rendimiento, pero agrega el riesgo de que si MariaDB falla, algunos datos puedan perderse.
MyISAM
InnoDB ha reemplazado a MyISAM como motor de almacenamiento predeterminado, pero todavía se usa para muchas tablas del sistema. MySQL ha desactivado la configuración de MyISAM ya que no la utiliza mucho.Cuando mysqld abre una tabla, comprueba si está marcada como bloqueada o si no se cerró correctamente, y ejecuta una comprobación en función de la configuración de myisam_recover_options. MySQL lo desactiva de manera predeterminada, impidiendo la recuperación. Por el contrario, MariaDB ha habilitado las opciones BACKUP y recuperación rápida (QUICK). BACKUP provoca que se cree un archivo table_name-datetime.bak cada vez que se cambia un archivo de datos durante la recuperación. La recuperación rápida hace que mysqld no compruebe las filas en una tabla si no hay bloques de eliminación, lo que garantiza que se ejecute más rápido.
MariaDB 10.2 aumentó el valor key_buffer_size. Esto permite que se almacenen más bloques de índice en la memoria. Todos los subprocesos usan este buffer, por lo que puede hacer que la información se mueva dentro y fuera de ella más rápidamente.
InnoDB
Las variables de InnoDB se han mantenido básicamente sin cambios entre MariaDB 10.2 y MySQL 5.7. MariaDB ha reducido el innodb_max_undo_log_size inicial en la versión 10.2.6. Esto redujo el valor predeterminado de MySQL de 1024 MiB a 10 MiB. Estos tamaños reflejan el tamaño máximo que puede tener un tablespace antes de truncarse. Este no se trunca a menos que innodb_undo_log_truncate esté habilitado, y está deshabilitado en MySQL 5.7 y MariaDB 10.2 de manera predeterminada.Logging
Los registros son extremadamente importantes para solucionar cualquier problema, por lo que las diferentes opciones de registro para MySQL 5.7 y MariaDB 10.2 son muy interesantes.La variable log_error nos permite controlar dónde se registran los errores. MariaDB 10.2 deja esta variable en blanco y escribe todos los errores en stderr. MySQL 5.7 usa un archivo creado explícitamente en /var/log/mysqld.log.
MariaDB 10.2 también ha habilitado el registro de declaraciones lentas adicionales.Log_slow_admin_statements crea un registro para cualquier declaración administrativa que normalmente no se escribe en el binlog, registrando las declaraciones copiadas que se envían desde el maestro si tardan en completarse. MySQL 5.7 no habilita el registro de estas declaraciones de forma predeterminada.
Lc_messages_dir es el directorio que contiene los archivos de mensajes de error para varios idiomas. Los valores predeterminados de las variables pueden ser un poco engañosos en MariaDB 10.2. Lc_messages_dir se deja vacío por defecto, aunque todavía utiliza la misma ruta que MySQL 5.7. Los archivos están ubicados en /usr/share/mysql de forma predeterminada para ambas bases de datos.
Esquema de rendimiento
Se trata de una herramienta de instrumentación diseñada para ayudar a solucionar varios problemas de rendimiento. MySQL 5.7 lo habilita, junto con muchos de sus instrumentos, por defecto. Incluso llega a detectar el valor apropiado para muchas de sus variables, en lugar de establecer un valor predeterminado estático. El esquema de rendimiento viene con algunos gastos generales, y hay muchos blogs sobre cuánto puede afectar el rendimiento.MariaDB lo ha deshabilitado por defecto y ha ajustado un par de variables dinámicas. Debemos tener en cuenta que si deseamos deshabilitar o habilitar el esquema de rendimiento, tenemos que reiniciar el servidor, ya que estas variables no son dinámicas. Los valores de performance_schema_setup_actors_size y performance_schema_setup_objects_size se han establecido en 100 de forma estática, en lugar del valor dinámico -1 utilizado en MySQL 5.7. Ambos limitan la cantidad de filas que se pueden almacenar en tablas relativas. Esto crea un límite estricto para el tamaño al que pueden crecer estas tablas, lo que ayuda a reducir su huella de datos.
SSL / TLS
Secure Sockets Layer (SSL) y Transport Layer Security (TLS) son protocolos criptográficos que permiten una comunicación segura. SSL es en realidad el predecesor de TLS, aunque a ambos se les conoce como SSL. MySQL 5.7 y MariaDB 10.2 son compatibles con yaSSL y OpenSSL. Las configuraciones predeterminadas para SSL / TLS difieren solo ligeramente entre MySQL 5.7 y MariaDB 10.2. MySQL 5.7 establece un nombre de archivo específico para ssl_ca, ssl_cert y ssl_key. Estos archivos se crean en el directorio base, identificados por la variable basedir. Cada una de estas variables se deja en blanco en MariaDB 10.2, por lo que debemos configurarlas antes de usar conexiones seguras. Estas variables no son dinámicas, así que tenemos que asegurarnos de establecer los valores antes de montar nuestra base de datos.Optimizador de consultas
Tiene varias variaciones que no solo afectan el rendimiento de la consulta, sino también la forma de escribir las sentencias de SQL. El optimizador de consultas es sustancialmente diferente entre MariaDB y MySQL, por lo que incluso con configuraciones idénticas, es probable que veamos un rendimiento variable.Sql_mode impone restricciones a la forma de escribir consultas. MySQL 5.7 tiene varias restricciones adicionales en comparación con MariaDB 10.2. Only_full_group_by requiere que todos los campos en cualquier declaración del tipo select … group by se añadan o estén dentro de la cláusula group by. El optimizador no asume nada con respecto a la agrupación, por lo que debemos especificarlo explícitamente.
No_zero_date y no_zero_in_date afectan a la forma en que el servidor interpreta ceros en las fechas. Cuando no_zero_date está habilitado, los valores de 0000-00-00 están permitidos pero producen una advertencia. Con el modo estricto habilitado, el valor no está permitido y produce un error. No_zero_in_date es similar, excepto que se aplica a cualquier sección de la fecha (mes, día o año). Con esta opción desactivada, las fechas con 0’s, como 2017-00-16, están permitidas tal como están. Cuando está habilitado, la fecha se cambia a 0000-00-00 sin previo aviso. El modo estricto impide que la fecha sea insertada, a menos que se indique ignore. INSERT IGNORE y UPDATE IGNORE insertan las fechas como 0000-00-00. La versión 5.7.4 de MySQL cambió esto. No_zero_in_date se consolidó con el modo estricto, y la opción explícita está en desuso.
Query_prealloc_size determina el tamaño del buffer persistente usado para el análisis y la ejecución. Si usamos regularmente consultas complejas, nos puede ser útil aumentar el tamaño de este buffer, ya que no necesita asignar memoria adicional durante el análisis de la consulta. MySQL 5.7 ha establecido este buffer en 8192 B, con un tamaño de bloque de 1024 B. MariaDB aumentó este valor en la versión 10.1.2 hasta 24576 B.
Query_alloc_block_size dicta el tamaño en bytes de cualquier bloque adicional asignado durante el análisis de consultas. Si la fragmentación de la memoria es un problema común, es posible que deseemos aumentar este valor. MySQL 5.7 usa 8192 B, mientras que MariaDB 10.2 usa 16384 B (el doble). Debemos tener cuidado al ajustar los tamaños de los bloques: uno demasiado alto consume más cantidad de memoria de la necesaria, y demasiado bajo provoca una fragmentación significativa.
La variable optimizer_switch contiene muchos modificadores diferentes que afectan a la forma en que el optimizador de consultas planifica y realiza las diferentes consultas. MariaDB 10.2 y MySQL 5.7 tienen muchas diferencias en sus opciones habilitadas e incluso en las opciones disponibles.
Misceláneas
Hay muchas variables que no encajan bien en un grupo. Vamos a repasarlas en este apartado.Al crear tablas temporales, si no especificamos un motor de almacenamiento, se usa un valor predeterminado. En MySQL 5.7, esto está configurado en InnoDB, lo mismo que el valor default_storage_engine. MariaDB 10.2 también usa InnoDB, pero no está establecido explícitamente. MariaDB establece default_tmp_storage_engine a NULL, lo que hace que use default_storage_engine. Es importante que recordemos esto si cambiamos el motor de almacenamiento predeterminado, ya que también cambiaríamos el valor predeterminado para las tablas temporales.
En MariaDB, esto solo es relevante para las tablas creadas con CREATE TEMPORARY TABLE. Las tablas temporales internas en memoria utilizan el motor de almacenamiento de memoria, y las tablas internas en disco usan el motor Aria de manera predeterminada.
La función group_concat puede devolver grandes resultados si la dejamos sin marcar. Podemos restringir el tamaño máximo de los resultados de esta función con group_concat_max_len. MySQL 5.7 limita esto a 1024 B. MariaDB aumentó el valor en su versión 10.2.4 hasta 1048576 B.
Lock_wait_timeout controla el tiempo que un hilo espera mientras intenta adquirir un bloqueo de metadatos. Varias declaraciones requieren un bloqueo de metadatos, que incluye operaciones DDL y DML, tablas de bloqueo, tablas de vaciado con bloqueo de lectura e instrucciones de controlador. MySQL 5.7, por defecto, tiene el valor máximo posible (un año), mientras que MariaDB 10.2 lo ha reducido a un día.
Max_allowed_packet establece un límite para el tamaño máximo de un paquete, o una cadena generada / intermedia. Este valor se mantiene intencionalmente pequeño (4 MB) en MySQL 5.7 para detectar los paquetes más grandes e incorrectos. MariaDB ha aumentado este valor a 16 MB. Si usamos cualquier campo más grande que BLOB, necesitamos ajustar este valor al tamaño del BLOB más grande, en múltiplos de 1024 B, o corremos el riesgo de tener errores al transferir los resultados.
Max_write_lock_count controla el número de bloqueos de escritura que pueden darse antes de que se procesen algunas solicitudes de bloqueo de lectura. En cargas de escritura extremadamente pesadas, nuestras lecturas pueden acumularse mientras esperamos que las escrituras se completen. La modificación de max_write_lock_count nos permite ajustar cuántas escrituras pueden ocurrir antes de que podamos ver algunas lecturas en la tabla. MySQL 5.7 mantiene este valor al máximo (18446744073709551615 B), mientras que MariaDB 10.2 bajó esto a 4294967295 B. Una cosa a tener en cuenta es que este sigue siendo el valor máximo en MariaDB 10.2.
Old_passwords controla el método de hash utilizado por la función de contraseña, crear usuario y otorgar instrucciones. Esta variable ha sufrido varios cambios en MySQL 5.7. MariaDB 10.2 usa un valor booleano simple para esta variable en lugar del enumerado en MySQL 5.7, aunque la intención es la misma. Ambos valores predeterminados son old_passwords OFF, o 0, y permiten habilitar el método anterior si es necesario.
Open_files_limit restringe la cantidad de descriptores de archivos que mysqld puede reservar. Si lo establecemos en 0 (el valor predeterminado en MariaDB 10.2), entonces mysqld reserva max_connections * 5 o max_connections + table_open_cache * 2, el que sea mayor. Cabe señalar que mysqld no puede usar una cantidad mayor que el límite estricto impuesto por el Sistema Operativo. MySQL 5.7 también está restringido por el límite de los Sistemas Operativos, pero se establece en tiempo de ejecución al valor real permitido por el propio sistema.
Pid_file nos permite controlar dónde almacenamos el archivo de ID de proceso. Este no es un archivo que normalmente necesitemos, pero es bueno saber dónde se encuentra en caso de que se produzcan algunos errores inusuales. En MariaDB, podemos encontrar esto dentro de /var/lib/mysql/, mientras que en MySQL 5.7, lo encontraremos dentro de /var/run/mysqld/.
Secure_file_priv es una función de seguridad que nos permite restringir la ubicación de los archivos utilizados en las operaciones de importación y exportación de datos. Cuando esta variable está vacía, que era la predeterminada en MySQL antes de 5.7.6, no hay restricciones. Si el valor está establecido en NULL, las operaciones de importación y exportación no están permitidas. El otro valor válido es la ruta del directorio desde donde se pueden importar o exportar los archivos. MariaDB 10.2 está predeterminado en vacio. A partir de MySQL 5.7.6, el valor predeterminado dependerá de la opción install_layout.
Mysqld usa un buffer de ordenación independientemente del motor de almacenamiento. Cada sesión que deba realizar una clasificación asigna un almacenamiento intermedio igual al valor de sort_buffer_size. Este buffer debe ser lo suficientemente grande como para contener 15 tuplas. En MySQL 5.7, el valor predeterminado es 262144 B, mientras que MariaDB 10.2 usa el valor más grande 2097152 B.
Table_definition_cache restringe la cantidad de definiciones de tabla que pueden almacenarse en caché. Si tenemos una gran cantidad de tablas, es posible que mysqld tenga que leer el archivo .frm para obtener esta información. MySQL 5.7 detecta automáticamente el tamaño apropiado para usar, mientras que MariaDB 10.2 predetermina este valor a 400 B.
Table_open_cache_instances varía en la implementación entre MySQL y MariaDB. MySQL 5.7 crea múltiples instancias de table_open_cache, una de las cuales contiene una parte de las tablas. Esto ayuda a reducir la contención, ya que una sesión necesita bloquear solo una instancia de la memoria caché para las declaraciones DML. En MySQL 5.7.7, el valor predeterminado era una sola instancia, pero esto se modificó en MySQL 5.7.8 (aumentó a 16). MariaDB tiene un enfoque más dinámico para el table_open_cache. Inicialmente, solo hay una instancia única de la memoria caché, y la variable table_open_cache_instances es la cantidad máxima de instancias que podemos crear. Si se detecta un conflicto en la memoria caché única, se crea otra instancia y se registra un error. MariaDB 10.2 supone que el máximo de ocho instancias que establece de forma predeterminada debe admitir hasta 100 núcleos de CPU.
Thread_cache_size controla cuando se crea un nuevo hilo. Cuando un cliente se desconecta, el hilo se almacena en la caché siempre que no exista la cantidad máxima de hilos. Aunque esto normalmente no se nota, si nuestro servidor ve cientos de conexiones por segundo, debemos aumentar este valor para que las nuevas conexiones puedan usar la caché. Thread_cache_size es una variable detectada automáticamente tanto en MySQL 5.7 como en MariaDB 10.2, pero sus métodos para calcular el valor predeterminado varían significativamente. MySQL usa una fórmula, con un máximo de 100: 8 + (max_connections / 100). MariaDB 10.2 usa el menor valor de 256 o el tamaño de max_connections
Thread_stack es el tamaño de la pila para cada hilo. Si el tamaño de la pila es demasiado pequeño, limita la complejidad de las sentencias SQL, la profundidad de recurrencia de los procedimientos almacenados y otras acciones que consumen memoria. MySQL 5.7 predetermina el tamaño de la pila a 192 KB en plataformas de 32 bits y 256 KB en sistemas de 64 bits. MariaDB 10.2 ajustó este valor varias veces. MariaDB 10.2.0 usó 290KB, 10.2.1 usó 291KB y 10.2.5 usó 292KB.
Desde Web App Design, esperamos que este artículo te pueda ayudar con las opciones de configuración entre MySQL y MariaDB. Te invitamos a poner un comentario o contactarnos a través de nuestro formulario si tienes alguna pregunta.
0 Comentarios