Solución:
Solución 1:
Tengo la respuesta completa para este.
Una vez innodb_file_per_table se pone en su lugar, y las nuevas tablas InnoDB se pueden reducir utilizando ALTER TABLE <innodb-table-name> ENGINE=InnoDB'; Esto se encogerá de nuevo .ibd archivos GARANTIZADOS.
Si tu corres ALTER TABLE <innodb-table-name> ENGINE=InnoDB'; en una tabla InnoDB creada antes de usar innodb_file_per_table, extraerá los datos y los índices de esa tabla del archivo ibdata1 y los almacenará en un .ibd file, Esto dejará una paloma entera permanente en el ibdata1 que nunca se podrá reutilizar.
los ibdata1 el archivo normalmente contiene cuatro tipos de información
- Datos de la tabla
- Índices de tabla
- Datos MVCC (control de simultaneidad de múltiples versiones)
- Segmentos de reversión
- Deshacer espacio
- Metadatos de tabla (diccionario de datos)
- Búfer de escritura doble (escritura en segundo plano para evitar la dependencia del almacenamiento en caché del sistema operativo)
- Insertar búfer (administrar cambios en índices secundarios no únicos)
- Ver el
Pictorial Representation of ibdata1
Aquí está la forma garantizada de reducir el archivo ibdata1 prácticamente para siempre …
PASO 01) MySQL Vierta todas las bases de datos en un archivo de texto SQL (llámelo SQLData.sql)
PASO 02) Elimine todas las bases de datos (excepto los esquemas mysql, information_schema y performance_schema)
PASO 03) Apague mysql
PASO 04) Agregue las siguientes líneas a /etc/my.cnf
[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend
Nota al margen: cualquiera que sea su conjunto para innodb_buffer_pool_size, asegúrese de que innodb_log_file_size sea el 25% de innodb_buffer_pool_size.
- PASO 05) Elimine ibdata1, ib_logfile0 e ib_logfile1 (¡vea la actualización a continuación antes de eliminar!)
En este punto, solo debería haber el esquema de mysql en / var / lib / mysql
- PASO 06) Reinicie mysql
Esto volverá a crear ibdata1 a 10 MB (no configure la opción), ib_logfile0 e ib_logfile1 a 1G cada uno
- PASO 07) Vuelva a cargar SQLData.sql en mysql
ibdata1 crecerá pero solo contendrá metadatos de tabla y datos MVCC intermitentes.
Cada tabla InnoDB existirá fuera de ibdata1
Suponga que tiene una tabla InnoDB llamada mydb.mytable. Si entras en /var/lib/mysql/mydb, verá dos archivos que representan la tabla
-
mytable.frm(Encabezado del motor de almacenamiento) -
mytable.ibd(Inicio de datos de tabla e índices de tabla paramydb.mytable)
ibdata1 nunca más contendrá datos e índices InnoDB.
Con el innodb_file_per_table opción en /etc/my.cnf, Tu puedes correr OPTIMIZE TABLE mydb.mytable O ALTER TABLE mydb.mytable ENGINE=InnoDB; y el archivo /var/lib/mysql/mydb/mytable.ibd realmente se encogerá.
Lo he hecho varias veces en mi carrera como DBA de MySQL sin un solo problema a partir de entonces. De hecho, la primera vez que hice esto, comprimí un archivo ibdata1 de 50 GB en 50 MB.
Darle una oportunidad. Si tiene más preguntas sobre esto, envíeme un correo electrónico. Confía en mí. Esto funcionará a corto y largo plazo.
ACTUALIZACIÓN 2013-07-02 15:08 EDT
Hay una advertencia que tengo al respecto que actualicé en otras publicaciones mías, pero me perdí esto: estoy actualizando mi respuesta un poco más con innodb_fast_shutdown porque solía reiniciar mysql y detener mysql para hacer esto. Ahora, este paso es vital porque cada transacción no comprometida puede tener otras partes móviles dentro y fuera de los registros de transacciones de InnoDB (Ver Infraestructura InnoDB).
Tenga en cuenta que establecer innodb_fast_shutdown en 2 también limpiaría los registros, pero aún existen más partes móviles y se eligen en Crash Recovery durante el inicio de mysqld. El ajuste de 0 es el mejor.
Solucion 2:
Ver error.
¿Hay inconvenientes en usarlo?
- más archivos abiertos
- abrir / reabrir arriba
- El archivo .ibd no se encoge (consulte 1, 2)
Siempre uso innodb_file_per_table en grandes bases de datos.
Solución 3:
innodb_file_per_table está habilitado de forma predeterminada en MariaDB.
Solución 4:
La razón por la que opté por no usar innodb_file_per_table, se debe a que cada tabla se coloca en su propio archivo, lo que significa que cada tabla tiene su propia sobrecarga separada (firmas de archivos, etc.) que causa el tamaño total y general del MySQL directorio para ser más grande que si se utiliza un espacio de tabla compartido. Además, hay más espacio desperdiciado debido a la holgura del clúster cuando se tienen varios archivos pequeños en lugar de uno solo grande.
Por supuesto, la sobrecarga adicional no es un masivo cantidad en el gran esquema de las cosas, especialmente si estás usando un disco grande o tienes una base de datos gigante, pero para mí (y probablemente muchos “usuarios domésticos”), todo sumaba y todavía era demasiado para el pequeño disco con grandes grupos donde guardaba mi tienda MySQL.
Por ejemplo, mi base de datos se almacena con mis bases de datos de WordPress y algunas otras bases de datos pequeñas (phpBB, dev, algunas pruebas de AMP, etc.), la conversión a por tabla la cambió de 32 MB a 50 MB, y eso ni siquiera incluye el ibdata1 que todavía requiere a mínimo de 10 MB, para un total de por lo menos 60 MB.
Como dije, esto puede no ser un gran problema para algunas personas, especialmente las empresas, pero si usted es un usuario doméstico que solo aloja su sitio, blog, etc., entonces puede ser un factor en cosas como elegir un proveedor de host porque muchos hosts limitan el tamaño de su base de datos además del uso total del disco.
Solución 5:
Solo para agregar un poco más de información
Desde mysql 5.6.6 está habilitado por defecto