15.4. Opciones de arranque de InnoDB

MySQL 5.0

previous page next page

15.4. Opciones de arranque de InnoDB

Esta sección describe las opciones de servidor relacionadas con . En MySQL 5.0, todas son especificadas con la forma = en la línea de comandos o en ficheros de opciones.

  • El tamaño del pool de memoria que utiliza para almacenar información del diccionario de datos y otras estructuras de datos internas. Mientras más tablas se tengan en la aplicación, mayor será este tamaño. Si se queda sin memoria en este pool, comenzará a tomar memoria del sistema operativo, y dejará mensajes de advertencia en el log de errores de MySQL. El valor por defecto es 1MB.

  • El tamaño a incrementar (en megabytes) cuando se extiende el tamaño de un espacio de tablas autoextensible, luego de llenarse. El valor por defecto es 8. Esta opción puede cambiarse en tiempo de ejecución como una variable de sistema global.

  • El tamaño (en MB) del pool de buffer, si está ubicado en la memoria AWE en Windows de 32 bits, y sólo relevante en este tipo de sistemas operativos. Si el sistema operativo Windows de 32 bits en uso soporta más de 4GB de memoria, usualmente llamado “Address Windowing Extensions”, se puede ubicar el pool del buffer de dentro de la memoria física AWE utilizando este parámetro. El máximo valor posible es de 64000. Si se especifica este parámetro, es la ventana en el espacio de direcciones de 32 bits de mysqld donde direcciona la memoria AWE. Un valor adecuado para son 500MB.

  • El tamaño del buffer de memoria que emplea para el almacenamiento intermedio de los datos e índices de sus tablas. Mientras más grande sea este valor, menores operaciones de E/S en disco serán necesarias para acceder a los datos de las tablas. En un servidor de bases de datos dedicado, se puede establecer este valor en hasta el 80% de la memoria física del ordenador. Sin embargo, no debe establecerse en un valor demasiado grande porque la pugna por la memoria física podría causar que el sistema oeprativo comience a paginar.

  • emplea validación por sumas de verificación (checksums) en todas las páginas leídas desde el disco, para asegurar una tolerancia extra contra fallas frente a hardware averiado o ficheros corruptos. Sin embargo, bajo ciertas circunstancias inusuales (por ejemplo al ejecutar pruebas de rendimiento) esta característica extra de seguridad es innecesaria. En tales casos, esta opción (que está habilitada por defecto) puede deshabilitarse con . Esta opción fue agregada en MySQL 5.0.3.

  • Las rutas a los ficheros individuales de datos y sus tamaños. La ruta de directorio completa a cada fichero de datos se obtiene concatenando con cada ruta especificada aquí. Los tamaños de fichero se especifican en megabytes o gigabytes (1024MB) agregando o al valor que representa el tamaño. La sumatoria de los tamaños de fichero debe ser de al menos 10MB. En algunos sistemas operativos, los ficheros deben tener menos de 2GB. Si no se indica , el comportamiento predeterminado de inicio es crear un único fichero autoextensible de 10MB llamado . En aquellos sistemas operativos que soporten ficheros grandes, se puede establecer el tamaño de fichero en más de 4GB. También pueden utilizarse como ficheros de datos particiones de dispositivos en bruto. Consulte Sección 15.14.2, “Usar dispositivos en bruto (raw devices) para espacios de tablas”.

  • La porción común de la ruta de directorio para todos los ficheros de datos . Si este valor no se establece, por defecto será el directorio de datos de MySQL. También puede especificarse como una cadena vacía, en cuyo caso se podrán utilizar rutas absolutas en .

  • Por defecto, almacena todos los datos dos veces, la primera en el buffer de escritura doble (o doublewrite), y luego a los ficheros de datos reales. Esta opción puede emplearse para desactivar dicha funcionalidad. Al igual que , esta opción está habilitada por defecto; puede desactivarse con en pruebas de rendimiento o casos en que el máximo desempeño prevalezca sobre la preocupacion por la integridad de los datos o las posibles fallas. Esta opción se agregó en MySQL 5.0.3.

  • Si se establece a 0, efectúa una descarga completa y vuelca los buffers de inserción antes de llevar a cabo el cierre del servidor. Estas operaciones pueden tomar minutos o incluso horas en casos extremos. Si se establece en 1, pasa por alto estas operaciones al cierre. El valor por defecto es 1. Si se establece en 2 (opción que está disponible desde MySQL 5.0.5, excepto en Netware), InnoDB simplemente vuelca a disco sus registros (logs) y se cierra en frío, como si hubiera ocurrido una caída; ninguna transacción confirmada se perderá, pero en el siguiente inicio se ejecutará una recuperación ante caídas.

  • El número de subprocesos (threads) de E/S de fichero en . Normalmente esto debería ser dejado en el valor predeterminado de 4, pero la E/S de disco en Windows puede beneficiarse con un número mayor. En Unix, incrementar el número no tiene efecto; siempre utiliza el valor predeterminado.

  • Esta opción provoca que cree cada nueva tabla utilizando su propio fichero para almacenar datos e índices, en lugar de colocarlo en el espacio de tablas compartidas. Consulte Sección 15.6.6, “Usar un espacio de tablas para cada tabla”.

  • Cuando se establece en 0, una vez por segundo el buffer de registros (log buffer) se graba en el fichero de registro y se vuelca a disco, pero no se hace nada al confirmar una transacción. Cuando este valor es 1 (predeterminado), cada vez que se confirma una transacción el buffer de registros (log buffer) se graba en el fichero de registro y se vuelca a disco Cuando se establece en 2, el buffer de registros (log buffer) se graba en el fichero de registro, pero no se vuelca a disco. Sin embargo, el volcado a disco del fichero de registro se produce una vez por segundo también cuando vale 2. Se debe tener en cuenta que el volcado una vez por segundo no está 100% garantizado que ocurra en cada segundo, debido a cuestiones de programación (scheduling) de procesos. Se puede alcanzar un mayor rendimiento estableciendo un valor diferente de 1, pero en caso de caída se puede perder un segundo de transacciones. Si se establece el valor en 0, cualquier caída en un proceso de mysqld puede borrar el último segundo de transacciones. Si se establece el valor en 2, entonces únicamente una caída del sistema operativo o una interrupción de energía pueden borrar el último segundo de transacciones. Hay que notar que muchos sistemas operativos y algunos tipos de discos puedne ser engañosos en las operaciones de volcado a disco. Podrían indicarle a mysqld que el volcado ha tenido lugar, aunque no sea así. En tal caso la estabilidad de las transacciones no está garantizada ni aún con el valor 1, y en el peor de los casos una interrupción de energía puede incluso corromper la base de datos InnoDB. Utilizar un caché de disco apoyado por baterías en el controlador de disco SCSI o en el propio disco, acelera los volcados a disco, y hace más segura la operación. También puede intentarse con el comando de Unix hdparm, el cual deshabilita el almacenamiento en caches de hardware de las operaciones de escritura a disco, o utilizar algún otro comando específico del fabricante del hardware. El valor por defecto de esta opción es 1

  • Esta opción solamente es relevante en sistemas Unix. Si se establece en (el valor predeterminado), utiliza para volcar tanto los ficheros de datos como de registro (log). Si se establece en , emplea para abrir y volcar los ficheros de registro, pero utiliza para volcar los ficheros de datos. Si se especifica (disponible en algunas versiones de GNU/Linux), utiliza para abrir los ficheros de datos, y para volcar tanto los ficheros de datos como de registro. Nótese que emplea en lugar de , y no emplea por defecto porque han ocurrido problemas con éste en muchas variedades de Unix.

  • Advertencia: Esta opción debería ser definida solamente en una situación de emergencia cuando se desean volcar las tablas desde una base de datos corrupta. Los posibles valores van de 1 a 6. Los significados de estos valores se describen en Sección 15.8.1, “Forzar una recuperación”. Como una medida de seguridad, impide que un usuario modifique datos cuando esta opción tiene un valor mayor a 0.

  • El límite de tiempo, en segundos, que una transacción puede esperar por un bloqueo antes de ser cancelada. automáticamente detecta bloqueos mutuos (deadlocks) en su propia tabla de bloqueos, y cancela la transacción. InnoDB detecta los bloqueos por el uso de la sentencia . El valor predeterminado es de 50 segundos.

    Para conseguir la mayor estabilidad y consistencia posibles en una configuración de replicación, se debería utilizar , , y en el fichero principal.

  • Esta opción desactiva el bloqueo de la clave siguiente en búsquedas y exploraciones de índices . El valor por defecto de esta opción es falso.

    Normalmente, utiliza un algoritmo denominado bloqueo de clave siguiente (next-key). efectúa un bloqueo a nivel de fila de tal forma que cuando busca o explora el índice de una tabla, establece bloqueos compartidos o exclusivos en cualquier registro de índice que encuentre. El bloqueo que establece en registros de índice también afecta al “vacío” que precede a ese registro. Si un usuario tiene un bloqueo compartido o exclusivo sobre el registro R en un índice, otro usuario no puede insertar un nuevo registro de índice inmediatamente antes de R en el orden del índice. Esta opción provoca que no utilice el bloqueo de clave siguiente en búsquedas o exploraciones de índices. El bloqueo de clave siguiente es todavía utilizado para asegurar las restricciones de claves foráneas y la verificación de claves duplicadas. Nótese que el uso de esta opción puede provocar problemas secundarios: suponiendo que se deseen leer y bloquear todos los registros hijos de la tabla que tengan un identificador mayor a 100, junto al posterior intento de actualizar algunas columnas en las filas seleccionadas: 

    SELECT * FROM child WHERE id > 100 FOR UPDATE;

    Supóngase que hay un índice sobre la columna . La consulta explora aquel índice comenzando por el primer registro en que sea mayor que 100. Si el bloqueo efectuado sobre los registros del índice no bloquea las inserciones realizadas en los espacios vacíos, en la tabla se insertará un nuevo registro. Si se ejecuta el mismo dentro de la misma transacción, se verá un nuevo registro en el conjunto de resultados devuelto por la consulta. Esto también significa que si se agregan nuevos elementos a la base de datos, InnoDB no garantiza la serialización; sin embargo, los conflictos de serialización aún están garantizados. Por lo tanto, si esta opción se utiliza, InnoDB garantiza como mucho el nivel de aislamiento .

    A partir de MySQL 5.0.2 esta opción es aún más insegura. en un o solamente bloquea los registros que se actualizan o borran. Esto reduce notablemente la probabilidad de bloqueos mutuos (deadlocks), pero aún pueden ocurrir. Nótese que esta opción todavía no le permite a operaciones como predominar sobre otras operaciones similares (como otro ) aún en el caso en que actúen sobre registros diferentes. Considérese lo siguiente: example: 

    CREATE TABLE A(A INT NOT NULL, B INT);
INSERT INTO A VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

    Si una conexión realiza una consulta: 

    SET AUTOCOMMIT = 0;
UPDATE A SET B = 5 WHERE B = 3;

    y la otra conexión ejecuta otra consulta a continuación de la primera: 

    SET AUTOCOMMIT = 0;
UPDATE A SET B = 4 WHERE B = 2;

    La consulta dos tendrá que esperar la confirmación o la cancelación de la consulta uno, porque ésta tiene un bloqueo exclusivo en el registro (2,3), y la consulta dos, mientras explora los registros, también intenta colocar un bloqueo exclusivo en la misma fila, cosa que no puede hacer. Esto se debe a que la consulta dos primero establece el bloqueo sobre un registro y luego determina si el registro pertenece al conjunto de resultados, y si no es así libera el bloqueo innecesario, cuando se emplea la opción .

    Por lo tanto, la consulta uno se ejecuta de este modo: 

    x-lock(1,2)
unlock(1,2)
x-lock(2,3)
update(2,3) to (2,5)
x-lock(3,2)
unlock(3,2)
x-lock(4,3)
update(4,3) to (4,5)
x-lock(5,2)
unlock(5,2)

    entonces la consulta dos se ejecuta así: 

    x-lock(1,2)
update(1,2) to (1,4)
x-lock(2,3) - wait for query one to commit or rollback

  • El directorio donde los ficheros de registro (logs) terminados se archivarán si se utiliza el archivo de ficheros de registro. Si se utiliza, el valor de este parámetro debería ser el mismo que . Sin embargo, no es requerido.

  • Este valor generalmente debería establecerse a 0. Debido a que la recuperación a partir de una copia de respaldo es realizada por MySQL empleando sus propios ficheros de registro (log), en general no hay necesidad de archivar los ficheros de registro de . El valor predeterminado para esta opción es 0.

  • El tamaño del buffer que emplea para escribir los ficheros de registro (logs) en disco. Los valores razonables se encuentran entre 1MB y 8MB. El valor predeterminado es 1MB. Un buffer de fichero de registro grande le permite a las transacciones extensas ejecutarse sin necesidad de guardar el fichero de registro en disco antes de que la transacción se confirme. Por lo tanto, si se manejan grandes transacciones, incrementar el tamaño del buffer de ficheros de registro ahorra operaciones de E/S en disco.

  • El tamaño de cada fichero de registro (log) en un grupo de ficheros de registro. El tamaño combinado de estos ficheros debe ser inferior a 4GB en ordenadores de 32 bits. El valor predeterminado es de 5MB. El rango de valores razonables va desde 1MB hasta la 1/ parte del tamaño del pool de buffer, donde es la cantidad de ficheros de registro en el grupo. Mientras mayor es el valor, menor es la cantidad de guardado de puntos de verificación que se necesitan en el pool de buffer, ahorrando operaciones de E/S en disco. Pero tener ficheros de registro más grandes también significa que la recuperación es más lenta en caso de caídas.

  • En un grupo de ficheros de registro (logs), es la cantidad de ficheros que contiene. escribe en los ficheros siguiendo una forma circular. El valor predeterminado es 2 (recomendado).

  • La ruta de directorio a los ficheros de registro (log) de . Debe tener el mismo valor que . Si no se especifican parámetros de ficheros de registro , la acción predeterminada es crear dos ficheros de 5MB llamados y en el directorio de datos de MySQL.

  • Un entero en el rango de 0 a 100. El valor por defecto es 90. El subproceso (thread) principal en intenta volcar páginas desde el pool de buffer de modo que a lo sumo este porcentaje de las páginas aún sin volcar sea volcado en un momento determinado. Si se tiene el privilegio , este porcentaje pude cambiarse mientras el servidor está en ejecución: 

    SET GLOBAL innodb_max_dirty_pages_pct = ;

  • Esta opción controla la forma de retrasar las operaciones , y cuando las operaciones de descarga (ver Sección 15.12, “Implementación de multiversión”) están sufiendo demoras. TEl valor por defecto de este parámetro es cero, lo que significa que no se retrasarán. Esta opción puede modificarse en tiempo de ejecución como una variable global de sistema.

    El sistema de transacciones de InnoDB mantiene una lista de transacciones que have delete-marked index records by or operations. Se deja que la longitud de esta lista sea . Cuando excede a , cada operación de , y se retrasa durante ((/)*10)-5 milisegundos. El retraso se computa en el comienzo de un lote de descarga, cada diez segundos. Las operaciones no se retrasan si no puede ejecutarse la descarga debido a una vista de lectura consistente (consistent read) anterior que contenga los registros a ser descargados.

    Un escenario típico para una carga de trabajo problemática podría ser 1 millón, asumiendo que las transacciones son pequeñas, sólo 100 bytes de tamaño, y se pueden permitir 100 MB de registros sin descargar en las tablas.

  • El número de copias idénticas de grupos de ficheros de registro que se mantienen para la base de datos. Actualmente debería establecerse en 1.

  • Esta opción sólo es relevante si se emplean múltiples espacios de tablas en . Especifica el número máximo de ficheros que puede mantener abiertos al mismo tiempo. El mínimo es 10. El valor predeterminado es 300.

    Los descriptores de fichero empleados para ficheros son únicamente para . Son independientes de los especificados por la opción de servidor , y no afectan la operación del caché de tablas.

  • Contribuye a asegurar la consistencia entre el contenido de las tablas y el registro binario (binary log). Consulte Sección 5.10.3, “El registro binario (Binary Log)”.

  • Esta opción provoca que cree un fichero /innodb_status. para la salida períodica de . Disponible desde MySQL 4.0.21.

  • respeta lo establecido por , y MySQL no retorna desde un hasta que todos los otros flujos (threads) han levantado sus bloqueos a la tabla. El valor por defecto es 1, lo cual significa que causará que InnoDB bloquee una tabla internamente. En aplicaciones que emplean , los bloqueos internos de tabla de InnoDB pueden originar bloqueos mutuos (deadlocks). Se puede establecer en (o en Windows) para eliminar ese problema.

  • intenta mantener el número de flujos (threads) del sistema operativo que concurren dentro de en un valor menor o igual al límite especificado por este parámetro. Antes de MySQL 5.0.8, el valor por defecto es 8. Si se tienen dificultades de rendimiento, y indica que hay muchos subprocesos esperando por semáforos, se podrían tener subprocesos pugnando por recursos, y se debería establecer este parámetro en un número mayor o menor. Si se posee un ordenador con varios procesadores y discos, se puede intentar aumentar el valor para hacer mejor uso de los recursos del ordenador. Un valor recomendado es la suma del número de procesadores y discos que tiene el sistema. Un valor de 500 o mayor deshabilitará la verificación de concurrencia. A partir de MySQL 5.0.8, el valor por defecto es 20, y la verificación de concurrencia se deshabilita si se establece en 20 o más.

  • Esta opción provoca que cree un fichero /innodb_status. para almacenar periódicamente la salida de .

previous page start next page