Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 1
InnoDB El motor de almacenamiento
Tabla de contenidos
1. Panorámica de InnoDB
2. Información de contacto de InnoDB
3. Configuración de InnoDB
4. Opciones de arranque de InnoDB
5. Crear el espacio de tablas InnoDB [+/-]
6. Crear tablas InnoDB [+/-]
7. Añadir y suprimir registros y ficheros de datos InnoDB
8. Hacer una copia de seguridad y recuperar una base de datosInnoDB [+/-]
9. Trasladar una base de datos InnoDB a otra máquina
10. Bloqueo y modelo de transacciones de InnoDB [+/-]
11. Consejos de afinamiento del rendimiento de InnoDB [+/-]
12. Implementación de multiversión
13. Estructuras de tabla y de índice [+/-]
14. Gestión de espacio de ficheros y de E/S de disco (Disk I/O) [+/-]
15. Tratamiento de errores de InnoDB [+/-]
16. Restricciones de las tablas InnoDB
17. Resolver problemas relacionados con InnoDB [+/-]
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 2
InnoDB
1. InnoDB dota a MySQL de un motor de almacenamiento transaccional (conforme
a ACID) con capacidades de commit (confirmación), rollback (cancelación) y
recuperación de fallas. InnoDB realiza bloqueos a nivel de fila y también
porporciona funciones de lectura consistente sin bloqueo al estilo Oracle en
sentencias SELECT. Estas características incrementan el rendimiento y la
capacidad de gestionar múltiples usuarios simultáneos. No se necesita un bloqueo
escalado en InnoDB porque los bloqueos a nivel de fila ocupan muy poco
espacio. InnoDB también soporta restriccionesFOREIGN KEY. En consultas SQL,
aún dentro de la misma consulta, pueden incluirse libremente tablas del
tipo InnoDB con tablas de otros tipos.
InnoDB se diseñó para obtener el máximo rendimiento al procesar grandes volúmenes de
datos. Probablemente ningún otro motor de bases de datos relacionales en disco iguale su
eficiencia en el uso de CPU.
A pesar de estar totalmente integrado con el servidor MySQL, el motor de
almacenamiento InnoDB mantiene su propio pool de almacenamiento intermedio para
tener un cache de datos e índices en la memoria principal.InnoDB almacena sus tablas e
índices en un espacio de tablas, el cual puede consistir de varios ficheros (o particiones
disco). Esto difiere de, por ejemplo, el motor MyISAM, donde cada tabla se almacena
empleando ficheros separados. Las tablas InnoDB pueden ser de cualquier tamaño, aún
en sistemas operativos donde el tamaño de los ficheros se limita a 2GB.
En MySQL 5.0, InnoDB viene incluido por defecto en las distribuciones binarias. El
instalador Windows Essentials configura a InnoDB como el tipo de base de datos MySQL
por defecto en Windows.
InnoDB se utiliza en muchos grandes sitios de bases de datos que necesitan alto
rendimiento. El famoso sitio de noticias de Internet Slashdot.org corre sobre InnoDB.
Mytrix, Inc. almacena más de 1TB de datos en InnoDB, y otros sitios manejan una carga
promedio de 800 inserciones y actualizaciones por segundo en InnoDB.
InnoDB se publica bajo la misma licencia GNU GPL Versión 2 (de Junio de 1991) que
MySQL.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 3
InnoDB Información de contacto
2. Información de contacto para Innobase Oy, creador del motor InnoDB.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse
en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y
esta traducción no necesariamente está tan actualizada como la versión original. Para
cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo,
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 4
InnoDB Configuración
3. En MySQL 5.0, el motor de almacenamiento InnoDB está habilitado por defecto. Si
no se desean emplear tablas InnoDB, puede agregarse la opciónskip-innodb al
fichero de opciones de MySQL.
Dos recursos basados en disco muy importantes que gestiona el motor de
almacenamiento InnoDB son sus ficheros de datos de espacios de tablas y sus ficheros de
registro (log).
Si no se especifican opciones de configuración para InnoDB, MySQL 5.0 crea en el
directorio de datos de MySQL un fichero de datos de 10MB (autoextensible)
llamado ibdata1 y dos ficheros de registro (log) de 5MB
llamados ib_logfile0 y ib_logfile1.
Nota: InnoDB dota a MySQL de un motor de almacenamiento transaccional (conforme
a ACID) con capacidades de commit (confirmación), rollback (cancelación) y recuperación
de fallas. Esto no es posible si el sistema operativo subyacente y el hardware no
funcionan como se requiere. Muchos sistemas operativos o subsistemas de disco podrían
diferir o reordenar operaciones de escritura a fin de mejorar el rendimiento. En algunos
sistemas operativos, la propia llamada del sistema (fsync()), que debería esperar hasta
que todos los datos no guardados de un fichero se graben a disco, en realidad puede
retornar antes de que los datos se guarden en las tablas de almacenamiento. Debido a
esto, una caída del sistema operativo o un corte en el suministro eléctrico pueden destruir
datos recientemente grabados, o, en el peor de los casos, corromper la base de datos
debido a que las operaciones de escritura han sido reordenadas. Si la integridad de los
datos es importante, se deberían llevar a cabo algunas pruebas que simulen caídas (“pull-
the-plug”) e interrupciones súbitas, antes de comenzar el uso para producción. En Mac OS
X 10.3 y posteriores, InnoDB emplea un método especial de volcado a fichero
llamado fcntl(). Bajo Linux, es aconsejable deshabilitar el write-back cache.
En discos duros ATAPI, un comando como hdparm -W0 /dev/hda puede funcionar. Hay
que tener en cuenta que algunas unidades o controladores de disco podrían estar
imposibilitados de desactivar el write-back cache.
Nota: Para obtener un buen desempeño, se deberían proveer expresamente los
parámetros de InnoDB como se explica en los siguientes ejemplos. Naturalmente, habrá
que editar la configuración para acomodarla a los requerimientos del hardware en uso.
Para configurar los ficheros de espacio de tablas de InnoDB, debe utilizarse la
opción innodb_data_file_pathen la sección [mysqld] del fichero de opciones my.cnf.
En Windows, se puede emplear en su lugar my.ini.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 5
El valor de innodb_data_file_path debería ser una lista de una o más especificaciones
de ficheros. Si se incluirá más de un fichero de datos, habrá que separarlos con punto y
coma (';'):
Por ejemplo, la siguiente es una configuración que creará explícitamente un espacio de
tablas con las mismas características que el predeterminado:
Esto configura un único fichero de 10MB llamado ibdata1 el cual es autoextensible. No se
suministra la ubicación del fichero, por lo tanto, el directorio predeterminado es el directorio
de datos de MySQL.
El tamaño del fichero se especifica empleando como sufijo las letras M o G para indicar
unidades de MB o GB.
A continuación se configura un espacio de tablas que contiene un fichero de datos de
tamaño fijo de 50MB llamado ibdata1 y un fichero autoextensible de 50MB
llamado ibdata2, ambos en el directorio de datos:
La sintaxis completa para especificar un fichero de datos incluye el nombre del fichero, su
tamaño, y varios atributos opcionales:
El atributo autoextend y aquellos que lo siguen sólo pueden emplearse con el último
fichero en la línea deinnodb_data_file_path.
Si se especifica la opción autoextend para el último fichero de
datos, InnoDB incrementará el tamaño del fichero si se queda sin capacidad para el
espacio de tablas. El incremento es de 8MB cada vez.
Si se agotara la capacidad del disco, podría desearse agregar otro fichero de datos en otro
disco. Las instrucciones para reconfigurar un espacio de tablas existente se encuentran
en Sección 7, “Añadir y suprimir registros y ficheros de datos InnoDB”.
InnoDB no detecta el tamaño máximo de fichero, por lo tanto, hay que ser cuidadoso en
sistemas de ficheros donde el tamaño máximo sea de 2GB. Para especificar el tamaño
máximo de un fichero autoextensible, se emplea el atributo max. La siguiente configuración
le permite a ibdata1 crecer hasta un límite de 500MB:
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 6
InnoDB crea los ficheros de espacios de tablas en el directorio de datos de MySQL en
forma predeterminada. Para especificar una ubicación expresamente, se emplea la
opción innodb_data_home_dir. Por ejemplo, para crear dos ficheros
llamados ibdata1 e ibdata2 pero creándolos en el directorio /ibdata, InnoDB se
configura de este modo:
Nota: InnoDB no crea directorios, de modo que hay que estar seguro de que el
directorio /ibdata existe antes de iniciar el servidor. Esto se aplica también a cualquier
directorio de ficheros de registro (log) que se configure. Para crear los directorios
necesarios se emplea el comando mkdir que existe en Unix y DOS.
InnoDB forma el directorio para cada fichero de datos concatenando el valor textual
de innodb_data_home_dircon el nombre del fichero, agregando una barra o barra
invertida entre ellos si se necesita. Si la opcióninnodb_data_home_dir no aparece
en my.cnf, el valor predeterminado es el directorio ./, lo cual indica el directorio de datos
de MySQL.
Si se especifica una cadena vacía en innodb_data_home_dir, se pueden especificar
rutas absolutas para los ficheros de datos listados en el valor
de innodb_data_file_path. El siguiente ejemplo es equivalente al anterior:
Un ejemplo sencillo de my.cnf . Suponiendo que se posee un ordenador con 128MB de
RAM y un disco duro, el siguiente ejemplo muestra posibles parámetros de
configuración InnoDB en my.cnf o my.ini incluyendo el atributo autoextend.
Este ejemplo satisface las necesidades de la mayoría de los usuarios, tanto en Unix como
en Windows, que no deseen distribuir los ficheros de datos InnoDB en varios discos. Crea
un fichero de datos autoextensible llamadoibdata1 y dos ficheros de registro (log)
de InnoDB llamados ib_logfile0 y ib_logfile1 en el directorio de datos de MySQL.
También, el fichero de registros archivados de InnoDB ib_arch_log_0000000000 que
MySQL crea automáticamente, termina ubicado en el directorio de datos.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 7
Hay que asegurarse de que el servidor MySQL tiene los derechos de acceso apropiados
para crear ficheros en el directorio de datos. Más generalmente, el servidor debe tener
derechos de acceso a cualquier directorio donde necesite crear ficheros de datos o registro
(logs).
Notar que los ficheros de datos deben ser menores de 2GB en algunos sistemas de
ficheros. El tamaño combinado de los ficheros de registro debe ser menor de 4GB. El
tamaño combinado de los ficheros de datos debe ser de por lo menos 10MB.
Cuando se crea un espacio de tablas InnoDB por primera vez, es mejor iniciar el servidor
MySQL desde la línea de comandos. Entonces, InnoDB imprimirá en pantalla la
información acerca de la creación de bases de datos, de forma que se podrá ver lo que
está ocurriendo. Por ejemplo, en Windows, si mysqld-max se ubica enC:\mysql\bin, se
puede iniciar de este modo:
Si no se envía la salida del servidor a la pantalla, se puede ver el fichero de registro de
errores del servidor para averiguar lo que InnoDB imprime durante el proceso de inicio.
Consulte Sección 5, “Crear el espacio de tablas InnoDB” para un ejemplo de cómo debería
lucir la información mostrada por InnoDB.
¿Dónde deben especificarse las opciones en Windows? Las reglas para ficheros de
opciones en Windows son las siguientes
:
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 8
Solo debe crearse el fichero my.cnf o my.ini, pero no los dos.
El fichero my.cnf debe colocarse en el directorio raíz de la unidad C:.
El fichero my.ini debería colocarse en el directorio WINDIR; por
ejemplo, C:\WINDOWS o C:\WINNT. Puede utilizarse el comando SET en una ventana
de consola para mostrar el valor de WINDIR:
Si el ordenador emplea un gestor de arranque donde la unidad C: no es la unidad de
arranque, sólo es posible emplear el fichero my.ini.
Si se instaló MySQL empleando los asistentes de instalación y configuración, el
fichero my.ini se ubica en el directorio de instalación de MySQL.
¿Dónde deben especificarse las opciones en Unix? En Unix, mysqld lee las
opciones en los siguientes ficheros, si existen, en el siguiente orden:
/etc/my.cnf
Opciones globales.
$MYSQL_HOME/my.cnf
Opciones específicas del servidor.
defaults-extra-file
El fichero especificado con la opción --defaults-extra-file.
~/.my.cnf
Opciones específicas del usuario.
MYSQL_HOME representa una variable de entorno la cual contiene la ruta al directorio que
hospeda al fichero específico de servidor my.cnf.
Si se desea estar seguro de que mysqld lee sus opciones únicamente desde un fichero
determinado, se puede emplear --defaults-option como la primera opción en la línea
de comandos cuando se inicia el servidor:
Un ejemplo avanzado de my.cnf . Suponiendo que se posee un ordenador Linux con
2GB de RAM y tres discos duros de 60GB (en los directorios /, /dr2 y /dr3). El siguiente
ejemplo muestra posibles parámetros de configuración InnoDB en my.cnf.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 9
Nótese que el ejemplo ubica los dos ficheros de datos en discos diferentes. InnoDB llena
el espacio de tablas comenzando por el primer fichero de datos. En algunos casos, el
rendimiento de la base de datos mejorará si no se colocan todos los datos en el mismo
disco físico. Colocar los ficheros de registro (log) en un disco diferente a los datos, a
menudo es beneficioso para el rendimiento. También se pueden utilizar dispositivos en
bruto (raw devices) como ficheros de datos InnoDB, lo cual mejorará la velocidad de E/S.
Advertencia: En GNU/Linux x86 de 32 bits, se debe tener cuidado con no establecer el
uso de memoria en un número demasiado alto. glibc le puede permitir al heap de
proceso que crezca por sobre la pila de los subprocesos, lo cual hará caer el servidor. Es
arriesgado que el resultado del siguiente cálculo exceda los 2GB:
Cada hilo emplea una pila (a menudo de 2MB, pero de solamente 256KB en los binarios
de MySQL AB) y en el peor caso también empleará una cantidad de memoria adicional
igual a sort_buffer_size + read_buffer_size.
Compilando MySQL por sí mismo, el usuario puede emplear hasta 64GB de memoria
física en Windows de 32 bits. Consulte la descripción
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 10
de innodb_buffer_pool_awe_mem_mb en Sección 15.4, “Opciones de arranque
deInnoDB”.
¿Cómo deben ajustarse otros parámetro del servidor mysqld? Los siguientes son
valores típicos adecuados para la mayoría de los usuarios:
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 11
InnoDB Opciones de arranque
4. Esta sección describe las opciones de servidor relacionadas con InnoDB. En
MySQL 5.0, todas son especificadas con la forma --opt_name=value en la línea
de comandos o en ficheros de opciones.
innodb_additional_mem_pool_size
El tamaño del pool de memoria que InnoDB 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 InnoDB 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.
innodb_autoextend_increment
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.
innodb_buffer_pool_awe_mem_mb
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 InnoDB 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, innodb_buffer_pool_sizees
la ventana en el espacio de direcciones de 32 bits de mysqld dondeInnoDB direcciona
la memoria AWE. Un valor adecuado para innodb_buffer_pool_size son 500MB.
innodb_buffer_pool_size
El tamaño del buffer de memoria que InnoDB 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 operativo comience a paginar.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 12
innodb_checksums
InnoDB 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--skip-innodb-checksums. Esta opción fue agregada en MySQL
5.0.3.
innodb_data_file_path
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 innodb_data_home_dir con cada ruta especificada aquí. Los tamaños
de fichero se especifican en megabytes o gigabytes (1024MB) agregando M o G 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 innodb_data_file_path, el comportamiento predeterminado de inicio
es crear un único fichero autoextensible de 10MB llamado ibdata1. 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.
innodb_data_home_dir
La porción común de la ruta de directorio para todos los ficheros de datos InnoDB. 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 innodb_data_file_path.
innodb_doublewrite
Por defecto, InnoDB 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 innodb_checksums, esta opción está habilitada por defecto; puede desactivarse
con--skip-innodb-doublewrite 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.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 13
innodb_fast_shutdown
Si se establece a 0, InnoDB 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, InnoDB 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.
innodb_file_io_threads
El número de subprocesos (threads) de E/S de fichero en InnoDB. 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; InnoDB siempre utiliza el valor predeterminado.
innodb_file_per_table
Esta opción provoca que InnoDB cree cada nueva tabla utilizando su propio
fichero .ibd 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”.
innodb_flush_log_at_trx_commit
Cuando innodb_flush_log_at_trx_commit 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.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 14
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
innodb_flush_method
Esta opción solamente es relevante en sistemas Unix. Si se establece
en fdatasync (el valor predeterminado),InnoDB utiliza fsync() para volcar tanto los
ficheros de datos como de registro (log). Si se establece
enO_DSYNC, InnoDB emplea O_SYNC para abrir y volcar los ficheros de registro, pero
utiliza fsync() para volcar los ficheros de datos. Si se especifica O_DIRECT (disponible
en algunas versiones de GNU/Linux), InnoDB utilizaO_DIRECT para abrir los ficheros de
datos, y fsync() para volcar tanto los ficheros de datos como de registro. Nótese
que InnoDB emplea fsync() en lugar de fdatasync(), y no emplea O_DSYNC por
defecto porque han ocurrido problemas con éste en muchas variedades de Unix.
innodb_force_recovery
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, InnoDBimpide que un usuario modifique datos cuando esta opción tiene un
valor mayor a 0.
innodb_lock_wait_timeout
El límite de tiempo, en segundos, que una transacción InnoDB puede esperar por un
bloqueo antes de ser cancelada. InnoDB 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 LOCK TABLES. 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 innodb_flush_logs_at_trx_commit=1, sync-
binlog=1, y innodb_safe_binlog en el fichero my.cnfprincipal.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 15
innodb_locks_unsafe_for_binlog
Esta opción desactiva el bloqueo de la clave siguiente en búsquedas y exploraciones
de índices InnoDB. El valor por defecto de esta opción es falso.
Normalmente, InnoDB utiliza un algoritmo denominado bloqueo de clave siguiente
(next-key). InnoDB 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 InnoDB 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 InnoDB 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 child 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 id. La consulta explora aquel índice
comenzando por el primer registro en que id 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
mismoSELECT 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 READ COMMITTED.
A partir de MySQL 5.0.2 esta opción es aún más insegura. InnoDB en
un UPDATE o DELETE 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 UPDATEpredominar sobre otras operaciones similares (como otro UPDATE) aún en
el caso en que actúen sobre registros diferentes. Considérese lo siguiente: example:
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 16
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 innodb_locks_unsafe_for_binlog.
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
innodb_log_arch_dir
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 innodb_log_group_home_dir. Sin embargo, no es requerido.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 17
innodb_log_archive
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 InnoDB. El valor predeterminado para esta opción es 0.
innodb_log_buffer_size
El tamaño del buffer que InnoDB 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.
innodb_log_file_size
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/N parte del tamaño del pool de buffer, donde N 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.
innodb_log_files_in_group
En un grupo de ficheros de registro (logs), es la cantidad de ficheros que
contiene. InnoDB escribe en los ficheros siguiendo una forma circular. El valor
predeterminado es 2 (recomendado).
innodb_log_group_home_dir
La ruta de directorio a los ficheros de registro (log) de InnoDB. Debe tener el mismo
valor queinnodb_log_arch_dir. Si no se especifican parámetros de ficheros de
registro InnoDB, la acción predeterminada es crear dos ficheros de 5MB
llamados ib_logfile0 y ib_logfile1 en el directorio de datos de MySQL.
innodb_max_dirty_pages_pct
Un entero en el rango de 0 a 100. El valor por defecto es 90. El subproceso (thread)
principal en InnoDB 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 SUPER, este porcentaje pude cambiarse mientras
el servidor está en ejecución:
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 18
SET GLOBAL innodb_max_dirty_pages_pct = value;
innodb_max_purge_lag
Esta opción controla la forma de retrasar las
operaciones INSERT, UPDATE y DELETE cuando las operaciones de descarga (ver 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 tienen
entradas en los índices marcadas para ser eliminadas por
operaciones UPDATE o DELETE. Se deja que la longitud de esta lista seapurge_lag.
Cuando purge_lag excede a innodb_max_purge_lag, cada operación
de INSERT, UPDATE yDELETE se retrasa durante
((purge_lag/innodb_max_purge_lag)*10)-5 milisegundos. El retraso se computa en
el comienzo de un lote de depuración, cada diez segundos. Las operaciones no se
retrasan si no puede ejecutarse la depuración debido a una vista de lectura consistente
(consistent read) anterior que contenga los registros a ser depurados.
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.
innodb_mirrored_log_groups
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.
innodb_open_files
Esta opción sólo es relevante si se emplean múltiples espacios de tablas en InnoDB.
Especifica el número máximo de ficheros .ibd que InnoDB puede mantener abiertos al
mismo tiempo. El mínimo es 10. El valor predeterminado es 300.
Los descriptores de fichero empleados para ficheros .ibd son únicamente
para InnoDB. Son independientes de los especificados por la opción de servidor --
open-files-limit, y no afectan la operación del caché de tablas.
innodb_safe_binlog
Contribuye a asegurar la consistencia entre el contenido de las tablas InnoDB y el
registro binario (binary log).
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 19
innodb_status_file
Esta opción provoca que InnoDB cree un
fichero <datadir>/innodb_status.<pid> para la salida períodica deSHOW INNODB
STATUS. Disponible desde MySQL 4.0.21.
innodb_table_locks
InnoDB respeta lo establecido por LOCK TABLES, y MySQL no retorna desde un LOCK
TABLE .. WRITE hasta que todos los otros flujos (threads) han levantado sus
bloqueos a la tabla. El valor por defecto es 1, lo cual significa que LOCK
TABLES causará que InnoDB bloquee una tabla internamente. En aplicaciones que
empleanAUTOCOMMIT=1, los bloqueos internos de tabla de InnoDB pueden originar
bloqueos mutuos (deadlocks). Se puede
establecer innodb_table_locks=0 en my.cnf (o my.ini en Windows) para eliminar
ese problema.
innodb_thread_concurrency
InnoDB intenta mantener el número de flujos (threads) del sistema operativo que
concurren dentro de InnoDB 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 SHOW INNODB STATUS 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.
innodb_status_file
Esta opción provoca que InnoDB cree un
fichero <datadir>/innodb_status.<pid> para almacenar periódicamente la salida
de SHOW INNODB STATUS.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 20
InnoDB Crear el espacio de tablas
5. Suponiendo que se ha instalado MySQL y se editó el fichero de opciones para que
contenga los parámetros de InnoDB necesarios, antes de iniciar MySQL se
debería verificar que los directorios indicados para los ficheros de datos y de
registro (log) InnoDB existen y que el servidor MySQL tiene permisos de acceso a
dichos directorios. InnoDB no puede crear directorios, solamente ficheros. Hay que
verificar también que se tiene suficiente espacio en disco para los ficheros de datos
y de registro.
Cuando se crea una base de datos InnoDB, es mejor ejecutar el servidor
MySQL mysqld desde la línea de comandos, no desde el envoltoriomysqld_safe o como
un servicio de Windows. Cuando se lo ejecuta desde la línea de comandos, se puede ver
lo que mysqld imprime y qué está ocurriendo. En Unix, simplemente debe
invocarse mysqld. En Windows, hay que usar la opción --console.
Cuando se inicia el servidor MySQL luego de la configuración inicial deInnoDB en el
fichero de opciones, InnoDB crea los ficheros de datos y de registro e imprime algo como
lo siguiente:
InnoDB: The first specified datafile /home/heikki/data/ibdata1
did not exist:
InnoDB: a new database to be created!
InnoDB: Setting file /home/heikki/data/ibdata1 size to 134217728
InnoDB: Database physically writes the file full: wait...
InnoDB: datafile /home/heikki/data/ibdata2 did not exist:
new to be created
InnoDB: Setting file /home/heikki/data/ibdata2 size to 262144000
InnoDB: Database physically writes the file full: wait...
InnoDB: Log file /home/heikki/data/logs/ib_logfile0 did not exist:
new to be created
InnoDB: Setting log file /home/heikki/data/logs/ib_logfile0 size
to 5242880
InnoDB: Log file /home/heikki/data/logs/ib_logfile1 did not exist:
new to be created
InnoDB: Setting log file /home/heikki/data/logs/ib_logfile1 size
to 5242880
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
InnoDB: Started
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 21
mysqld: ready for connections
Se ha creado una nueva base de datos InnoDB. Se puede conectar al servidor MySQL
con los programas cliente acostumbrados, como mysql. Cuando se detiene el servidor
MySQL, con mysqladmin shutdown, la salida es como la siguiente:
010321 18:33:34 mysqld: Normal shutdown
010321 18:33:34 mysqld: Shutdown Complete
InnoDB: Starting shutdown...
InnoDB: Shutdown completed
Se puede mirar en los directorios de ficheros de datos y registro y se verán los ficheros
creados. El directorio de registro (log) también contiene un pequeño fichero
llamado ib_arch_log_0000000000. Ese fichero resulta de la creación de la base de
datos, luego de lo cual InnoDB desactivó el guardado de registros (log). Cuando MySQL
inicia de nuevo, los ficheros de datos y de registro ya han sido creados, por lo que la salida
es más breve:
InnoDB: Started
mysqld: ready for connections
Es posible agregar la opción innodb_file_per_table a my.cnf, y hacer que InnoDB
almacene cada tabla en su propio fichero .ibd
InnoDB Crear tablas
6. Suponiendo que se ha iniciado el cliente MySQL con el comando mysql test,
para crear una tabla InnoDB se debe especificar la opción ENGINE =
InnoDB o TYPE = InnoDB en la sentencia SQL de creación de tabla:
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) ENGINE=InnoDB;
CREATE TABLE customers (a INT, b CHAR (20), INDEX (a)) TYPE=InnoDB;
La sentencia SQL crea una tabla y un índice en la columna a en el espacio de
tablas InnoDB que consiste en los ficheros de datos especificados enmy.cnf.
Adicionalmente, MySQL crea un fichero customers.frm en el directorio test debajo del
directorio de bases de datos de MySQL. Internamente, InnoDB agrega a su propio
diccionario de datos una entrada para la tabla 'test/customers'. Esto significa que
puede crearse una tabla con el mismo nombre customers en otra base de datos, y los
nombres de las tablas no entrarán en conflicto dentro de InnoDB.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 22
Se puede consultar la cantidad de espacio libre en el espacio de tablasInnoDB dirigiendo
una sentencia SHOW TABLE STATUS para cualquier tablaInnoDB. La cantidad de espacio
libre en el espacio de tablas aparece en la sección Comment en la salida de SHOW TABLE
STATUS. Un ejemplo:
SHOW TABLE STATUS FROM test LIKE 'customers'
Nótese que las estadísticas que SHOW muestra acerca de las tablas InnoDBson solamente
aproximadas. Se utilizan en la optimización SQL. No obstante, los tamaños en bytes
reservados para las tablas e índices son exactos.
InnoDB Añadir y suprimir registros y ficheros de
datos
7. Esta sección describe lo que se puede hacer cuando el espacio de
tablasInnoDB se queda sin espacio o cuando se desea cambiar el tamaño de los
ficheros de registro (log).
La manera más sencilla de incrementar el tamaño del espacio de tablasInnoDB es
configurarlo desde un principio para que sea autoextensible, especificando el
atributo autoextend para el último fichero de datos en la definición del espacio de tablas.
Entonces, InnoDB incrementa el tamaño de ese fichero automáticamente en intervalos de
8MB cuando se queda sin espacio. El tamaño del intervalo a incrementar puede
configurarse estableciendo el valor de innodb_autoextend_increment, el cual está
expresado en megabytes, y cuyo valor predeterminado es 8.
Alternativamente, se puede incrementar el tamaño del espacio de tablas agregando otro
fichero de datos. Para hacer esto, se debe detener el servidor MySQL, editar el
fichero my.cnf para agregar un nuevo fichero de datos al final
de innodb_data_file_path, e iniciar nuevamente el servidor.
Si el último fichero de datos especificado tiene la palabra clave autoextend, el
procedimiento para editar a my.cnf debe tener en cuenta el tamaño que ha alcanzado
este último fichero. Hay que obtener el tamaño del fichero de datos, redondearlo hacia
abajo a la cantidad de megabytes (1024 * 1024 bytes) más cercana, y especificar este
número explícitamente eninnodb_data_file_path. Entonces se podrá agregar otro
fichero de datos. Hay que recordar que solamente el último fichero de datos
eninnodb_data_file_path puede especificarse como autoextensible.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 23
Como ejemplo, se asumirá que el espacio de tablas tiene sólo un fichero de datos
autoextensible ibdata1:
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:10M:autoextend
Suponiendo que este fichero de datos, a lo largo del tiempo, ha crecido hasta 988MB,
debajo se ve la línea de configuración luego de agregar otro fichero de datos
autoextensible.
innodb_data_home_dir =
innodb_data_file_path =
/ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
Cuando se agrega un nuevo fichero al espacio de tablas, hay que asegurarse de que no
exista. InnoDB crea e inicializa el fichero al reiniciar el servidor.
Actualmente no es posible quitar un fichero de datos del espacio de tablas. Para reducir el
tamaño del espacio de tablas, emplear este procedimiento:
1. Utilizar mysqldump para hacer un volcado de todas las tablas InnoDB.
2. Detener el servidor.
3. Eliminar todos los ficheros existentes del espacio de tablas.
4. Configurar un nuevo espacio de tablas.
5. Reiniciar el servidor.
6. Importar el fichero de volcado de tablas.
Si se desea modificar la cantidad o tamaño de los ficheros de registro (log) de InnoDB, se
debe detener el servidor MySQL y asegurarse de que se cerró sin errores. Luego, copiar
los ficheros de registro antiguos en un lugar seguro, sólo para el caso de que algo haya
fallado en el cierre del servidor y se necesite recuperar el espacio de tablas. Eliminar los
antiguos ficheros de registro del directorio de ficheros de registro, editar my.cnfpara
modificar la configuración de los ficheros de registro, e iniciar nuevamente el servidor
MySQL. mysqld verá al iniciar que no hay ficheros de registro e informará que está
creando nuevos.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 24
InnoDB Hacer una copia de seguridad y recuperar una
base de datos
8. La clave de una administración de bases de datos segura es realizar copias de
respaldo regularmente.
InnoDB Hot Backup es una herramienta de respaldo en línea que puede utilizarse para
respaldar la base de datos InnoDB mientras ésta se está ejecutando. InnoDB Hot
Backup no necesita que se detenga la base de datos y no establece ningún bloqueo ni
dificulta el normal procesamiento de la base de datos. InnoDB Hot Backup es una
herramienta adicional comercial (no grautita) cuyo cargo anual de licencia es de €390 por
cada ordenador en el que se ejecute el servidor MySQL. Consulte la página de Internet
de InnoDB Hot Backup para obtener información detallada y ver capturas de pantallas.
Si se está en condiciones de detener el servidor MySQL, puede realizarse una copia de
respaldo binaria, que consiste en todos los ficheros usados por InnoDB para administrar
sus tablas. Se utiliza el siguiente procedimiento:
1. Detener el servidor MySQL y asegurarse de que lo hace sin errores.
2. Copiar todos los ficheros de datos (ficheros ibdata e .ibd) en un lugar seguro.
3. Copiar todos los ficheros ib_logfile en un lugar seguro.
4. Copiar el o los ficheros de configuración my.cnf en un lugar seguro.
5. Copiar todos los ficheros .frm de las tablas InnoDB en un lugar seguro.
La replicación funciona con tablas InnoDB, de forma que puede emplearse para mantener
una copia de la base de datos en sitios de bases de datos que necesiten alta
disponibilidad.
Adicionalmente a la realización de copias de respaldo binarias como se ha descripto,
también se deberían realizar regularmente volcados de las tablas con mysqldump. El
motivo de esto es que un fichero binario podría corromperse sin que el usuario lo note. El
volcado de las tablas se almacena en ficheros de texto que son legibles por los seres
humanos, facilitando la localización de corrupción en las tablas. Además, puesto que el
formato es más simple, las probabilidades de una corrupción seria de datos son
menores. mysqldump también tiene una opción --single-transaction que puede
usarse para capturar una imagen consistente de la base de datos sin bloquear otros
clientes.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 25
Para estar en condiciones de recuperar una base de datos InnoDB a partir del respaldo
binario descripto anteriormente, se debe ejecutar el servidor MySQL con el registro binario
(binary logging) activo. Entonces se puede aplicar el log binario al respaldo de la base de
datos para lograr la recuperación a una fecha y hora determinadas:
mysqlbinlog nombre_de_host-bin.123 | mysql
Para recuperarse de una caida del servidor, sólo se requiere reiniciarlo. InnoDB verifica
automáticamente los registros (logs) y ejecuta una recuperación de la base de datos del
tipo roll-forward, es decir, hasta el momento anterior a la falla. InnoDB revierte
automáticamente las transacciones no grabadas que existían al momento de la caída.
Durante la recuperación, mysqld muestra información parecida a esta:
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
InnoDB: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
...
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
Si la base de datos se corrompe o falla el disco, habrá que efectuar la recuperación desde
una copia de respaldo. En el caso de corrupción, primero habría que encontrar una copa
de respaldo realizada antes de la corrupción. Luego de restaurar la copia de respaldo
base, debe realizarse la recuperación a partir de los ficheros de registro binario.
En algunos casos de corrupción de base de datos es suficiente con volcar, eliminar, y
volver a crear una o unas pocas tablas corruptas. Se puede emplear la sentencia
SQL CHECK TABLE para verificar si una tabla está corrupta, aunque CHECK TABLE,
naturalmente, no puede detectar cada posible clase de corrupción. Se puede
emplear innodb_tablespace_monitor para verificar la integridad de la gestión de
espacio de ficheros dentro de los ficheros de espacio de tablas.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 26
En algunos casos, una aparente corrupción de página de base de datos se debe en
realidad a que el sistema operativo está corrompiendo su propio cache de ficheros, y los
datos en el disco podrían estar en buenas condiciones. Lo mejor es, antes que nada,
intentar el reinicio del ordenador. Ello puede eliminar errores que dan la sensación de tener
corrupción en la página de base de datos.
InnoDB
Trasladar una base de datos a otra máquina
9. En Windows, InnoDB siempre almacena internamente en minúsculas los nombres
de bases de datos y tablas. Para mover bases de datos en un formato binario de
Unix a Windows o de Windows a Unix, se deberían tener en minúsculas todos los
nombres de tablas y bases de datos. Una forma apropiada de cumplir con esto es
agregar la siguiente línea a la sección[mysqld] de los
ficheros my.cnf o my.ini antes de crear cualquier base de datos o tablas:
[mysqld]
lower_case_table_names=1
Al igual que los ficheros de datos MyISAM, los ficheros de datos y de registro (log)
de InnoDB son compatibles a nivel binario en todas las plataformas que tengan el mismo
formato de números de coma flotante. Se puede mover una base de
datos InnoDB simplemente copiando todos los ficheros relevantes que se listan
en Sección 8, “Hacer una copia de seguridad y recuperar una base de datos InnoDB”. Si
los formatos de número de coma flotante difieren pero no se han empleado tipos de
datos FLOAT o DOUBLE en las tablas, el procedimiento es el mismo: copiar los ficheros
necesarios. Si los formatos difieren y las tablas contienen datos de coma flotante, se
deberá emplear mysqldump para volcar las tablas en un ordenador e importar los ficheros
de volcado en otro.
Una forma de incrementar el rendimiento es desactivar el modo autocommit (ejecución
automática) al importar datos, asumiendo que el espacio de tablas tiene suficiente sitio
para el extenso segmento de cancelación (rollback) que generará la importación de
transacciones. La confirmación (commit) se hará luego de importar una tabla entera o un
segmento de una tabla.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 27
InnoDB Bloqueo y modelo de transacciones
10. En el modelo de transacciones de InnoDB, la meta es combinar las mejores
propiedades de una base de datos multiversión con el tradicional bloqueo de dos
fases. InnoDB bloquea a nivel de fila y ejecuta consultas por defecto como lecturas
consistentes (consistent reads) no bloqueadas, al estilo de Oracle. La tabla de
bloqueo en InnoDB se almacena en forma tan eficiente que no se necesitan
bloqueos escalables: generalmente varios usuarios están habilitados a bloquear
cada fila de la base de datos, o cualquier subconjunto de filas, sin
que InnoDB incurra en falta de memoria.
InnoDB Consejos de afinamiento del rendimiento
11. Si la utilidad top de Unix o el Administrador de Tareas de Windows muestra que el
porcentaje de uso de CPU durante la carga de trabajo es inferior al 70%,
probablemente se está trabajando directamente sobre el disco. Podría suceder que
se estén produciendo excesivas confirmaciones de transacciones, o que el pool de
buffer sea muy pequeño. Puede ser de ayuda incrementar el tamaño del buffer,
pero no debe alcanzar ni superar el 80% del total de la memoria física del
ordenador.
Incluir varias modificaciones en una sola transacción. InnoDB debe descargar su
registro (log) al disco cada vez que se confirma una transacción, si dicha transacción
realiza modificaciones en la base de datos. Dado que la velocidad de rotación de un
disco es generalmente de 167 revoluciones por segundo, esto restringe el número de
confirmaciones a la misma fracción de segundo si el disco no “engaña” al sistema
operativo.
Si es aceptable la pérdida de alguna de las últimas transacciones confirmadas, se
puede establecer en my.cnf el parámetroinnodb_flush_log_at_trx_commit a un
valor de 0. InnoDB intenta descargar el registro (log) una vez por segundo en cualquier
caso, aunque la descarga no está garantizada.
Incrementar el tamaño de los ficheros de registro (log), incluso hasta equiparar el
tamaño del pool de buffer. Cuando InnoDB ha colmado la capacidad de los ficheros de
log,
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 28
Debe escribir los contenidos modificados desde el pool de buffer al disco en un punto
de verificación. Los ficheros de log pequeños pueden causar escrituras en disco
innecesarias. La desventaja de los ficheros de log grandes es que la recuperación
demanda más tiempo.
También el buffer del log debe ser suficientemente grande (en el orden de los 8MB).
Emplear el tipo de columna VARCHAR en lugar de CHAR si se almacenarán cadenas de
longitud variable o si la columna contendrá muchos valores NULL. Una
columna CHAR(N) siempre utiliza N bytes para almacenar los datos, inclusive si la
cadena es más corta o es NULL. Las tablas más pequeñas aprovechan mejor el espacio
del pool de buffer y reducen las operaciones de E/S en disco.
Cuando se utiliza row_format=compact (el formato de registro predeterminado para
InnoDB en MySQL 5.0) y un conjunto de caracteres de longitud variable
como utf8 o sjis, CHAR(N) ocupará una cantidad variable de espacio, con un mínimo
de N bytes.
En algunas versiones de GNU/Linux y Unix, descargar ficheros a disco con la función
de Unix fsync() (la cual es utilizada en forma predeterminada por InnoDB) y otros
métodos similares, es sorprendentemente lento. Si no se está satisfecho con el
rendimiento de las operaciones de escritura de la base de datos, se puede intentar
establecer el valor de innodb_flush_method en my.cnf a O_DSYNC, si
bien O_DSYNC parece ser más lento en otros sistemas.
Durante el empleo del motor de almacenamiento InnoDB en arquitecturas Solaris 10
para x86_64 (AMD Opteron), es importante usar la opción forcedirectio al montar
cualquier sistema de ficheros usado para almacenar los ficheros relacionados con
InnoDB (el comportamiento predeterminado en Solaris 10/x86_64 es no utilizar esta
opción al montar el sistema de ficheros). Si no se utiliza forcedirectio se producirá
una seria degradación en la velocidad y rendimiento de InnoDB en esta plataforma.
Al importar datos dentro de InnoDB, hay que asegurarse de que MySQL no tiene
habilitado el modo de ejecución automática (autocommit) porque provocaría una
descarga del log a disco en cada inserción. Para desactivar la ejecución automática
durante la operación de importación, hay que encerrarla entre sentencias SET
AUTOCOMMITy COMMIT:
SET AUTOCOMMIT=0;
/* Sentencias de importación SQL ... */
COMMIT;
Si se utiliza la opción --opt con mysqldump, se obtienen ficheros de voclado que son
rápidos de importar en una tabla InnoDB, incluso sin encerrarlos en las sentencias SET
AUTOCOMMIT y COMMIT.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 29
Tener cuidado con las cancelaciones de inserciones masivas: InnoDB emplea el buffer
de inserciones para reducir la cantidad de operaciones de E/S en disco durante las
inserciones, pero ese mecanismo no tiene efecto en la cancelación. Una cancelación
efectuada directamente sobre el disco puede tomar 30 veces el tiempo que insumen las
correspondientes inserciones. Matar el proceso del servidor de bases de datos no es de
ayuda, porque la cancelación recomienza al volver a iniciar el servidor. La única forma
de librarse de una cancelación fuera de control es incrementar el tamaño del pool de
buffer para que la cancelación se haga sobre la CPU y se ejecute más rápidamente, o
utilizar un procedimiento especial. Consulte Sección 15.8.1, “Forzar una recuperación”.
También hay que tener cuidado con las operaciones de gran tamaño realizadas
directamente sobre el disco. Hay que emplear DROP TABLE y CREATE TABLE para
obtener una tabla vacía, no DELETE FROM tbl_name.
Emplear la sintaxis de múltiples filas de INSERT para reducir la carga extra de la
comunicación entre el cliente y el servidor si se necesita insertar muchos registros:
INSERT INTO yourtable VALUES (1,2), (5,5), ...;
Esta sugerencia es válida para las inserciones en cualquier tipo de tabla, no solamente
en InnoDB.
Si se tienen restricciones UNIQUE en claves secundarias, se puede acelerar la
importación desactivando temporalmente, durante la importación, la verificación de
tales restricciones:
SET UNIQUE_CHECKS=0;
En tablas grandes, esto ahorra una gran cantidad de operaciones de E/S en disco
debido a que InnoDB puede emplear su buffer de inserción para escribir de una vez los
registros de indice secundarios.
Si se tienen restricciones FOREIGN KEY en las tablas, se puede acelerar la importación
desactivando la verificación de claves foráneas durante la misma:
SET FOREIGN_KEY_CHECKS=0;
Para tablas grandes, esto puede ahorrar gran cantidad de operaciones sobre el disco.
Si a menudo se realizan consultas sobre tablas que no se actualizan con frecuencia,
utilizar el cache de consultas:
[mysqld]
query_cache_type = ON
query_cache_size = 10M
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 30
Implementación de multiversión
12.Debido a que InnoDB es una base de datos con multiversión, debe llevar
información acerca de las versiones anteriores de una fila en el espacio de tablas.
Esta información se almacena en una estructura de datos llamada Rollback
Segment (Segmento de Cancelación) al igual que una estructura de datos análoga
de Oracle.
Internamente, InnoDB agrega dos campos a cada fila almacenada en la base de datos. Un
campo de 6 bytes indica el identificador de la última transacción que insertó o actualizó la
fila. Además, una eliminación se trata internamente como una actualización en la que un
bit especial en la fila se establece a un valor que la señala como eliminada. Cada registro
también contiene un campo de 7 bytes llamado "roll pointer" que apunta a una entrada del
registro (log) de cancelación de modificaciones (undo) grabado en el segmento de
cancelación (RollBack Segment). Si la fila fue actualizada, la entrada en el registro de
cancelación de modificaciones (undo log) contiene la información necesaria para recrear el
contenido de la fila tal como estaba antes de actualizarse.
InnoDB utiliza la información en el segmento de cancelación para deshacer los cambios
durante la cancelación de una transacción. También la emplea para generar versiones
anteriores de una fila en una lectura consistente.
Los registros de cancelación de modificaciones en el segmento de cancelación se dividen
entre originados por inserciones (insert undo logs) y actualizaciones (update undo logs).
Los insert undo logs se necesitan solamente para la cancelación de transacciones y se
descartan tan pronto como se confirma la transacción. Los update undo logs se emplean
también para lecturas consistentes, y pueden descartarse solamente cuando no quedan
transacciones integrando una captura tomada por InnoDB, que en una lectura consistente
podría necesitar esta información para reconstruir versiones anteriores de una fila.
Se deben confirmar las transacciones regularmente, incluyendo aquellas que solamente
realizan lecturas consistentes. De otro modo, InnoDB no podrá descartar datos de los
update undo logs, y el segmento de cancelación puede crecer en demasía, llenando el
espacio de tablas.
El tamaño físico de una entrada en el registro de cancelación de cambios en el segmento
de cancelación es generalmente menor que el de la correspondiente fila insertada o
actualizada. Se puede emplear esta información para calcular el espacio necesario para el
segmento de cancelación.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 31
En el esquema de multiversión de InnoDB, una fila no es quitada inmediatamente de la
base de datos cuando se la elimina mediante una sentencia SQL. Sólo
cuando InnoDB pueda descartar la entrada en el registro de cancelación de
modificaciones creada para la eliminación, procederá a quitar físicamente de la base de
datos la fila y sus entradas en los índices. Esta operación se llama depuración (purge) y es
bastante rápida, generalmente requiere el mismo tiempo que la sentencia SQL que realizó
la eliminación.
En un escenario donde el usuario inserte y elimine filas aproximadamente en la misma
proporción y en pequeños lotes, es posible que el subproceso de depuración comience a
sufrir retrasos y la tabla crezca contínuamente, haciendo muy lenta cualquier operación
que se realice sobre el disco. Incluso si una tabla contuviera sólo 10 MB de datos útiles,
puede crecer hasta ocupar 10 GB con las filas “muertas”. En tal caso podría ser bueno
limitar las operaciones de filas nuevas y asignar más recursos al subproceso de
depuración. La opción de inicio (y también variable global
configurable) innodb_max_purge_lag existe precisamente para este propósito.
ConsulteSección .4, “Opciones de arranque de InnoDB” para más información.
Estructuras de tabla y de índice
13.MySQL almacena la información de su diccionario de datos de tablas en
ficheros .frm dentro del directorio de cada base de datos. Esto es así para todos
los motores de almacenamiento de MySQL, pero cada tabla InnoDBtambién tiene
su propia entrada en los diccionarios de datos internos deInnoDB dentro del
espacio de tablas. Cuando MySQL elimina una tabla o una base de datos, también
debe eliminar uno o más ficheros .frm, y las correspondientes entradas dentro del
diccionario de datos de InnoDB. Esta es la razón por la cual no se pueden mover
tablas entre bases de datos sencillamente moviendo los ficheros .frm.
Cada tabla InnoDB tiene un índice especial llamado índice agrupado (clustered index)
donde se almacenan los datos de las filas. Si se define unaPRIMARY KEY en una tabla, el
índice de la clave primaria es el índice agrupado.
Si no se define una PRIMARY KEY para la tabla, MySQL toma como clave primaria el
primer índice UNIQUE que tenga solamente columnas NOT NULL, al cual InnoDB utiliza
como índice agrupado. Si no hay en la tabla un índice con esas
características, InnoDB generará internamente un índice agrupado donde las filas estarán
ordenadas por el identificador de fila (row ID) queInnoDB asigna a las columnas en tal
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 32
tabla. El identificador de fila es un campo de 6 bytes que se incrementa automáticamente a
medida que se agregan nuevas filas. Por lo tanto, las filas ordenadas por este identificador
están en el orden físico de inserción.
El acceso a una fila a través del índice agrupado es rápido porque la fila de datos se
encuentra en la misma página a donde el índice dirige su búsqueda. Si una tabla es
grande, la arquitectura del índice agrupado a menudo ahorra operaciones de E/S en disco
en comparación a la solución tradicional. (En muchos servidores de bases de datos, los
datos se suelen almacenar en una página diferente que la entrada del índice).
En InnoDB, las entradas en índices no agrupados (también llamados índices secundarios)
contienen el valor de clave primaria de la fila. InnoDB utiliza este valor de clave primaria
para buscar la fila a partir del índice agrupado. Nótese que si la clave primaria es larga, los
índices secundarios utilizan más espacio.
InnoDB compara las cadenas CHAR y VARCHAR de diferente longitud como si el espacio
sobrante en la cadena más corta estuviera relleno con espacios.
Gestión de espacio de ficheros y de E/S de disco (Disk I/O)
14. E/S de disco (Disk I/O)
InnoDB emplea E/S en disco asíncrona simulada: InnoDB crea un número de procesos
para hacerse cargo de las operaciones de E/S, tal como lectura por adelantado (read-
ahead).
En InnoDB hay dos métodos de lectura por adelantado:
En la lectura por adelantado secuencial, si InnoDB advierte que el patrón de acceso a
un segmento en el espacio de tablas es secuencial, envía por adelantado al sistema de
E/S un lote de lectura de páginas de base de datos.
En la lectura por adelantado aleatoria, si InnoDB advierte que algún sector del espacio
de tablas parece estar en proceso de ser completamente leido dentro del pool de búfer,
envía las lecturas restantes al sistema de E/S.
InnoDB emplea una novedosa técnica de descarga de ficheros llamada doublewrite. La
misma incrementa la seguridad en la recuperación que sigue a una caida del sistema
operativo o una interrupción de energía eléctrica, y mejora el rendimiento en muchas
variedades de Unix al reducir la necesidad de usar operaciones fsync().
Doublewrite (escritura doble) significa que antes de escribir páginas en un fichero de
datos, InnoDB las escribe primero en un área contigua del espacio de tablas llamada el
búfer de doublewrite (o de escritura doble). Solamente luego de que la escritura y
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 33
descarga al búfer de escritura doble se ha completado, InnoDB escribe las páginas en el
sitio apropiado del fichero de datos. Si el sistema operativo colapsa en el transcurso de
una escritura de página, InnoDB, posteriormente, durante la recuperación, podrá hallar
una copia en buen estado en el búfer de escritura doble.
InnoDB
Tratamiento de errores
15. El tratamiento de errores en InnoDB no siempre es como se especifica en el
estándar SQL. De acuerdo a éste, cualquier error durante la ejecución de una sentencia
SQL debería ocasionar su cancelación. InnoDB a veces sólo cancela una parte de la
sentencia, o la transacción completa. Los siguientes puntos describen cómo InnoDB lleva
a cabo el tratamiento de errores:
Si el espacio de tablas agota su espacio disponible en disco, se obtiene el error de
MySQL Table is full (La tabla está llena) e InnoDB cancela la sentencia SQL.
Un interbloqueo (deadlock) en una transacción o un exceso de espera (timeout) en una
espera por bloqueo provocan que InnoDB cancele la transacción completa.
Un error de clave duplicada cancelará la sentencia SQL, si ésta no contiene la
opción IGNORE.
Un error row too long error (registro demasiado largo) cancela la sentencia SQL.
Los demás errores son, en su mayoría, detectados por la capa de código MySQL (por
encima del nivel del motor de almacenamiento InnoDB) y causarán la cancelación de la
correspondiente sentencia SQL. Los bloqueos no se liberan al cancelar una única
sentencia SQL.
Durante una cancelación implícita, así como durante la ejecución de un comando
SQL ROLLBACK explícito, SHOW PROCESSLIST muestra Rolling back en la
columna State de la conexión afectada.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 34
InnoDB Restricciones de las tablas
16. Una tabla no puede contener más de 1000 columnas.
La longitud máxima interna de una clave es 3500 bytes, pero MySQL la restringe a
1024 bytes.
La longitud máxima de fila, excepto para columnas VARCHAR, BLOB y TEXT, es
ligeramente inferior a la mitad de una página de base de datos. Es decir, cerca de 8000
bytes. Las columnas LONGBLOB y LONGTEXT deben ser de menos de 4GB, y la longitud
total de la fila, incluyendo las columnas BLOB y TEXT, debe ser de menos de
4GB. InnoDB almacena los primeros 768 bytes de una columna VARCHAR, BLOB,
o TEXT en la fila, y el resto, en páginas separadas.
En algunos sistemas operativos antiguos, los ficheros de datos deben ser de menos de
2GB.
El tamaño combinado de los ficheros de log de InnoDB debe ser inferior a 4GB.
El tamaño mínimo del espacio de tablas es de 10MB. El tamaño máximo es de
cuatrocientos mil millones de páginas de base de datos (64TB). Este es también el
tamaño máximo para una tabla.
Las tablas InnoDB no admiten índices FULLTEXT.
Las tablas InnoDB no admiten tipos de columna espaciales.
ANALYZE TABLE determina la cardinalidad efectuando 10 accesos al azar en cada
uno de los árboles de índices y actualizando la cardinalidad del índice con una
estimación acorde. Dado que son solamente estimaciones, distintas ejecuciones
de ANALYZE TABLE pueden producir resultados diferentes. Esto convierte a ANALYZE
TABLE en una herramienta rápida sobre tablas InnoDB, pero no con el mismo nivel de
exactitud que si considerara todas las filas al hacer el recuento.
MySQL emplea las estimaciones de cardinalidad de los índices solamente para la
optimización de uniones. Si una unión no se optimiza en la manera adecuada, se puede
intentar el uso de ANALYZE TABLE. En los pocos casso en que ANALYZE TABLE no
produce valores suficientemente buenos para las tablas, se puede emplear FORCE
INDEX en las consultas para forzar el uso de un índice en particular, o establecer el
valor demax_seeks_for_key para asegurarse de que MySQL dará preferencia a las
búsquedas en índices por sobre el examen de las tablas.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 35
En Windows, InnoDB siempre almacena internamente en minúsculas los nombres de
tablas y bases de datos. Para mover bases de datos en formato binario desde Unix a
Windows o a la inversa, se deberán haber escrito en minúsculas todos los nombres de
tablas y bases de datos.
Advertencia: ¡No deben convertirse las tablas de sistema de MySQL de la base de
datos mysql desde su formato original MyISAM a InnoDB! Esta es una operación no
admitida. Si se lleva a cabo, MySQL no se podrá ejecutar hasta que se recuperen las
tablas de sistema anteriores desde una copia de respaldo o se las regenere con el
script mysql_install_db.
InnoDB no lleva una cuenta interna de las filas en una tabla. (Esto sería realmente
complicado a causa de la multiversión). Para procesar una sentencia SELECT
COUNT(*) FROM T, InnoDB debe examinar un índice de la tabla, lo cual lleva algún
tiempo si el índice no está completamente dentro del pool de buffer. Para disponer de
un recuento más rápido, se debe crear una tabla de recuento y hacer que la aplicación
la actualice a medida que se producen inserciones y eliminaciones. Si una tabla no se
modifica a menudo, utilizar el cache de consultas (query cache) de MySQL es una
buena solución. También puede emplearse SHOW TABLE STATUS si es suficiente un
recuento aproximado de filas. Consulte Sección 11, “Consejos de afinamiento del
rendimiento de InnoDB”.
Para una columna AUTO_INCREMENT, siempre se debe definir un índice para la tabla, el
cual debe contener solamente a la columna AUTO_INCREMENT. En tablas MyISAM, la
columna AUTO_INCREMENT puede formar parte de un índice junto a otras columnas.
InnoDB no admite la opción AUTO_INCREMENT en sentencias CREATE TABLE o ALTER
TABLE, la cual sirve para establecer el valor inicial de la secuencia. Para especificar
este valor en InnoDB, debe insertarse una fila con un valor que sea uno menos que el
deseado, y luego borrarla, o insertar la primera fila especificando un valor determinado.
Luego de reiniciar el servidor MySQL, InnoDB puede reutilizar un valor antiguo para
una columnaAUTO_INCREMENT (esto es, un valor que se hubiese asignado a una
transacción finalmente cancelada).
Cuando una columna AUTO_INCREMENT sobrepasa el máximo valor que es capaz de
almacenar, InnoDB coloca la columna en -9223372036854775808 (si es BIGINT) o
en 1 (si es BIGINT UNSIGNED). Sin embargo, como los valores BIGINT tienen 64 bits,
hay que notar que si se insertara un millón de filas por segundo, se demoraría cerca de
trescientos mil años en agotar los números disponibles. Con otros tipos de columnas
enteros, ocurre un error de clave duplicada. Esto es similar al funcionamiento
de MyISAM, ya que es en mayor medida el comportamiento general de MySQL y no
pertenece a ningún motor de almacenamiento en particular.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 36
DELETE FROM nom_tabla no regenera la tabla sino que elimina todas sus filas, una
por una.
TRUNCATE tbl_name se implementa en InnoDB como DELETE FROM tbl_name y no
inicializa el contador deAUTO_INCREMENT.
SHOW TABLE STATUS no proporciona estadísticas precisas en tablas InnoDB, excepto
para el tamaño físico reservado por la tabla. El recuento de filas es solamente una
estimación utilizada para la optimización SQL.
En MySQL 5.0, la operación LOCK TABLES establece dos bloqueos en cada tabla
si innodb_table_locks=1, que es el valor por defecto. Adicionalmente al bloqueo de
tabla en la capa MySQL, también se establece un bloqueo de tabla en InnoDB. En
versiones antiguas de MySQL no se establecía el bloqueo en InnoDB, para volver a
este comportamiento debe especificarse innodb_table_locks=0. Si no se establece
el bloqueoInnoDB, LOCK TABLES se completa aún cuando algunos registros de las
tablas estén bloqueados por otras transacciones.
Todos los bloqueos InnoDB efectuados por una transacción se liberan cuando la
transacción se confirma o se cancela. Por lo tanto, no tiene mucho sentido
invocar LOCK TABLES en tablas InnoDB cuando se está en el modoAUTOCOMMIT=1,
porque los bloqueos establecidos sobre una tabla InnoDB se liberarán inmediatamente.
Algunas veces sería útil bloquear tablas extensas en el curso de una trasacción.
Desafortunadamente, LOCK TABLES, en MySQL, emite implícitamente un COMMIT y
un UNLOCK TABLES. Está planeada una variante para InnoDB de LOCK TABLES que
puede ejecutarse dentro de una transacción.
La sentencia LOAD TABLE FROM MASTER empleada para la replicación de servidores
esclavos no funciona aún con tablas InnoDB. Una solución temporal es cambiar
a MyISAMla tabla en el servidor amo (master), efectuar la carga, y volver a cambiar la
tabla en el amo (master) a su motor original InnoDB.
El tamaño por defecto de cada página de base de datos en InnoDB es de 16KB. Se
puede establecer en valores entre 8KB y 64KB recompilando el código. Se deben
modificar los valores de UNIV_PAGE_SIZE yUNIV_PAGE_SIZE_SHIFT en el fichero
fuente univ.i.
En MySQL 5.0, los disparadores (triggers) aún no son activados por modificaciones
efectuadas en cascada a través de claves foráneas.
Universidad Católica Los Ángeles de Chimbote Base de Datos II -- InnoDB
1
Hernández Bruno Brayan A. Página 37
InnoDB Resolver problemas relacionados
17. Por regla general, cuando una operación falla o se tienen sospechas de un error,
se debe inspeccionar el log de errores del servidor MySQL, que normalmente tiene un
nombre como nombre_host.err, o posiblementemysql.err en Windows.
Durante la resolución de problemas, usualmente es mejor ejecutar el servidor MySQL
desde la línea de comandos, en lugar de utilizarmysqld_safe o como servicio de
Windows. Ejecutándolo como se indica, se podrán ver los mensajes
que mysqld imprime en la pantalla, y hacerse una mejor idea de lo que está
sucediendo. En Windows, el servidor debe iniciarse con la opción --console para que
la salida se dirija a la ventana de DOS utilizada.
Pueden utilizarse los Monitores InnoDB para obtener información sobre un problema. Si
el problema está relacionado con el rendimiento, o el servidor parece estar congelado,
se debería utilizar innodb_monitorpara ver información acerca del estado interno
de InnoDB. Si el problema es con bloqueos, debe utilizarse innodb_lock_monitor. Si
el problema es en la creación de tablas u otra operación del diccionario de datos, debe
emplearse innodb_table_monitor para imprimir los contenidos del diccionario de
datos interno de InnoDB.
Si se sospecha que una tabla está corrupta, hay que ejecutar CHECK TABLE sobre ella.