archivo de datos MySQL InnoDB directamente en un segmento de disco (de tamaño fijo)?

Question

Parece que ibdata1 es como un segmento de disco. En los sistemas de archivos Solaris (UNIX) UFS (el común antes de ZFS), se podría separar su disco c0t0d0 en rodajas, dicen que una unidad de 10 GB sería cortado en tres secciones, 4 GB, 1 GB y 5 GB. Estos serían los sistemas de ficheros de tamaño fijo. El 4 GB para, por ejemplo, el sistema operativo. 1 GB de swap y 5 GB para el software y los datos.

swap puede ser almacenada en un archivo en un sistema de archivos, pero para un rendimiento por lo general almacena en su propia sección del disco.

Can ibdata1 estar vinculado a su propio segmento de aumento de rendimiento? Por supuesto, uno tendría que pensar cuidadosamente antes de decidir lo que fija el tamaño es ideal y que también tendría que saber cómo controlar los niveles de uso.

Un enlace simbólico se puede colocar de .../mysql/data/ibdata1 a /dev/rdsk/c0t0d0s3. MySQL entonces verlo como un archivo, pero podría funcionar mejor, ya que no tiene que ir a través de la capa del sistema de archivos, sería escribir directamente a una sección designada del disco.

• ¿Alguien ha probado esto?
• ¿Alguien piensa que esto es una mala idea? (Tenga en cuenta que esta idea es para InnoDB-sólo los servidores de bases de datos de sólo lectura. No servidores de usos múltiples.)
• ¿funcionaría (no innodb necesidad de comprobar la longitud del archivo? Si no es así, debería funcionar.)
• ¿Se puede comprobar el uso?

Answer 1

En primer lugar, ¿cuáles son los tipos de entrada que residen en ibdata1? Cuatro (4) tipos de entrada:

• tabla de metadatos
• tabla de páginas de datos
• Índice de páginas de datos
• MVCC de datos

Siempre que una tabla InnoDB experimenta DDL, DML, o ser utilizado en una transacción, los cuatro de estos tipos de entradas se leen o escriben bien. Mientras tanto, si innodb_file_per_table está desactivada, todas ellas tipos de entradas viven en ibdata1. Si está habilitada, sólo la tabla de metadatos y los datos MVCC residirían en ibdata1 mientras que las páginas de índice y las páginas de datos de la tabla de datos podría residir en la subcarpeta base de datos como un archivo .ibd.

Que siendo considerado, lo que sucedería si ibdata1 se colocaron en otro volumen y un enlace simbólico?

Para empezar, ¿Qué representa una tabla de MySQL sin tener en cuenta el motor de almacenamiento? Como un archivo .frm. Cuando lo hacen .frm en vivo? En el datadir. ¿Qué hay de malo en eso?

Este es un ejemplo:

Uso de la datadir por defecto / var / lib / mysql, vamos a utilizar una tabla InnoDB llamada mydb.mytable.

Con innodb_file_per_table discapacitados, todo se sentaba en ibdata1 (que usted propone enlazar simbólicamente y enviar a otro volumen de datos). Para el mydb.mytable mesa, esto es lo que tendría que:

• /var/lib/mysql/mydb/mytable.frm
• Todo lo demás en la mesa vidas en ibdata1

Imagen esto ahora: Se accede a la tabla, MySQL golpearía primero /var/lib/mysql/mydb/mytable.frm y después haga clic en los datos y las páginas de índice en ibdata1 para mydb.mytable. Esta constante estaría sucediendo con cada acceso de mydb.mytable. Esta cascada hacia atrás y hacia adelante de alguna manera hacer las cosas un poco más lento y no pueden obtener el rendimiento que se esperaba moviendo ibdata1 a algún otro volumen de datos. De hecho, el efecto en cascada ahora sería un factor del número de tablas InnoDB multiplicado por dos (2).

Imagine tener activado innodb_file_per_table. Ahora usted tendría una configuración ligeramente diferente:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• Los datos MVCC y tabla de metadatos residiría en ibdata1

Esta cascada sería un poco peor, porque la cascada de acceso a la tabla sería ahora ocurrir entre los tres archivos en lugar de dos.

Este es un escenario más que algunos han pensado: En lugar de mover el ibdata1 a un volumen diferente, ¿qué tal que permite innodb_file_per_table y mover los archivos .ibd a uno o más volúmenes de datos diferente? El efecto en cascada ahora sería un factor del número de tablas InnoDB multiplicado por tres (3). Percona tiene expresados ??muy buenas razones para no hacer esto que usted encontrará útil .