Los fabricantes de servidores y los proveedores de la nube ofrecen diferentes tipos de soluciones de almacenamiento para satisfacer las necesidades de su base de datos. Cuando compramos un nuevo servidor o elegimos una instancia en la nube para ejecutar nuestra base de datos, a menudo nos preguntamos:¿cuánto espacio en disco debemos asignar? Como veremos, la respuesta no es trivial ya que hay una serie de aspectos a considerar. El espacio en disco es algo en lo que debe pensarse por adelantado, porque reducir y expandir el espacio en disco puede ser una operación riesgosa para una base de datos basada en disco.
En esta publicación de blog, veremos cómo dimensionar inicialmente su espacio de almacenamiento y luego planificar la capacidad para respaldar el crecimiento de su base de datos MySQL o MariaDB.
Cómo utiliza MySQL el espacio en disco
MySQL almacena datos en archivos en el disco duro en un directorio específico que tiene la variable de sistema "datadir". El contenido del datadir dependerá de la versión del servidor MySQL y de los parámetros de configuración cargados y las variables del servidor (por ejemplo, general_log, slow_query_log, binary log).
La información real de almacenamiento y recuperación depende de los motores de almacenamiento. Para el motor MyISAM, los índices de una tabla se almacenan en el archivo .MYI, en el directorio de datos, junto con los archivos .MYD y .frm de la tabla. Para el motor InnoDB, los índices se almacenan en el tablespace, junto con la tabla. Si innodb_file_per_table está establecida, los índices estarán en el archivo .ibd de la tabla junto con el archivo .frm. Para el motor de memoria, los datos se almacenan en la memoria (montón), mientras que la estructura se almacena en el archivo .frm en el disco. En el próximo MySQL 8.0, los archivos de metadatos (.frm, .par, dp.opt) se eliminan con la introducción del nuevo esquema de diccionario de datos.
Es importante tener en cuenta que si está utilizando el espacio de tablas compartido de InnoDB para almacenar datos de tablas (innodb_file_per_table=OFF ), se espera que el tamaño de los datos físicos de MySQL crezca continuamente incluso después de truncar o eliminar grandes filas de datos. La única forma de recuperar el espacio libre en esta configuración es exportar, eliminar las bases de datos actuales y volver a importarlas a través de mysqldump. Por lo tanto, es importante configurar innodb_file_per_table=ON si le preocupa el espacio en disco, de modo que al truncar una tabla, se puede recuperar el espacio. Además, con esta configuración, una gran operación DELETE no liberará espacio en disco a menos que se ejecute OPTIMIZE TABLE después.
MySQL almacena cada base de datos en su propio directorio bajo la ruta "datadir". Además, los archivos de registro y otros archivos MySQL relacionados, como los archivos de socket y PID, también se crearán de forma predeterminada en datadir. Por motivos de rendimiento y confiabilidad, se recomienda almacenar los archivos de registro de MySQL en un disco o partición separados, especialmente el registro de errores de MySQL y los registros binarios.
Estimación del tamaño de la base de datos
La forma básica de estimar el tamaño es encontrar la relación de crecimiento entre dos puntos diferentes en el tiempo y luego multiplicarla por el tamaño actual de la base de datos. Medir el tráfico de la base de datos en las horas pico para este propósito no es la mejor práctica y no representa el uso de la base de datos en su totalidad. Piense en una operación por lotes o un procedimiento almacenado que se ejecuta a medianoche o una vez a la semana. Tu base de datos podría crecer significativamente por la mañana, antes de que una operación de mantenimiento la redujera a medianoche.
Una forma posible es utilizar nuestras copias de seguridad como elemento base para esta medición. La copia de seguridad física como Percona Xtrabackup, MariaDB Backup y la instantánea del sistema de archivos produciría una representación más precisa del tamaño de su base de datos en comparación con la copia de seguridad lógica, ya que contiene la copia binaria de la base de datos y los índices. La copia de seguridad lógica como mysqldump solo almacena instrucciones SQL que se pueden ejecutar para reproducir las definiciones de objetos de la base de datos original y los datos de la tabla. Sin embargo, aún puede obtener una buena tasa de crecimiento comparando las copias de seguridad de mysqldump.
Podemos usar la siguiente fórmula para estimar el tamaño de la base de datos:
donde,
- B - Tamaño de la copia de seguridad completa de la semana actual,
- B - Tamaño completo de la copia de seguridad de la semana anterior,
- BDdatos - Tamaño total de datos de la base de datos,
- BDíndice - Tamaño total del índice de la base de datos,
- 52 - Número de semanas en un año,
- Y - Año.
El tamaño total de la base de datos (datos e índices) en MB se puede calcular utilizando las siguientes declaraciones:
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+La ecuación anterior se puede modificar si desea utilizar las copias de seguridad mensuales en su lugar. Cambia el valor constante de 52 a 12 (12 meses en un año) y listo.
Además, no olvide tener en cuenta innodb_log_file_size x 2, innodb_data_file_path y para Galera Cluster, agregue gcache.size valor.
Estimación del tamaño de los registros binarios
Los registros binarios son generados por el maestro MySQL para fines de replicación y recuperación en un momento dado. Es un conjunto de archivos de registro que contienen información sobre las modificaciones de datos realizadas en el servidor MySQL. El tamaño de los registros binarios depende del número de operaciones de escritura y del formato del registro binario:DECLARACIÓN, FILA o MIXTO. El registro binario basado en declaraciones suele ser mucho más pequeño en comparación con el registro binario basado en filas, porque solo consta de declaraciones de escritura, mientras que el basado en filas consiste en información de filas modificadas.
La mejor manera de estimar el uso máximo de disco de los registros binarios es medir el tamaño del registro binario para un día y multiplicarlo por expire_logs_days valor (el valor predeterminado es 0 - sin eliminación automática). Es importante establecer expire_logs_days para que pueda estimar el tamaño correctamente. De forma predeterminada, cada registro binario tiene un límite de alrededor de 1 GB antes de que MySQL rote el archivo de registro binario. Podemos usar un evento de MySQL para simplemente vaciar el registro binario con el propósito de esta estimación.
En primer lugar, asegúrese de que la variable event_scheduler esté habilitada:
mysql> SET GLOBAL event_scheduler = ON;Luego, como usuario privilegiado (con privilegios de EVENTO y RECARGA), cree el siguiente evento:
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Para una carga de trabajo de escritura intensiva, probablemente necesite acortar el intervalo a 30 minutos o 10 minutos antes de que el registro binario alcance el tamaño máximo de 1 GB, luego redondee la salida hasta una hora. Luego verifique el estado del evento usando la siguiente declaración y mire la columna LAST_EXECUTED:
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Luego, eche un vistazo a los registros binarios que tenemos ahora:
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Luego podemos calcular el promedio de crecimiento de nuestros registros binarios, que es de alrededor de ~562 MB por hora. durante las horas pico. Multiplique este valor por 24 horas y los expire_logs_days valor:
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Obtendremos 94416 MB, que es alrededor de ~95 GB de espacio en disco para nuestros registros binarios. Los registros de retransmisión del esclavo son básicamente los mismos que los registros binarios del maestro, excepto que se almacenan en el lado del esclavo. Por lo tanto, este cálculo también se aplica a los registros del relé esclavo.
¿Disco de husillo o estado sólido?
Hay dos tipos de operaciones de E/S en archivos MySQL:
- Archivos orientados a E/S secuencial:
- espacio de tablas del sistema InnoDB (ibdata)
- Archivos de registro de MySQL:
- Registros binarios (binlog.xxxx)
- Registros REDO (ib_logfile*)
- Registros generales
- Registros de consultas lentas
- Registro de errores
- Archivos orientados a E/S aleatorias:
- Archivo de datos de archivo por tabla de InnoDB (*.ibd) con innodb_file_per_table=ON (predeterminado).
Considere colocar archivos aleatorios orientados a E/S en un subsistema de disco de alto rendimiento para obtener el mejor rendimiento. Esto podría ser una unidad flash, ya sea SSD o tarjeta NVRAM, o discos de eje de altas RPM como SAS 15K o 10K, con controlador RAID de hardware y unidad respaldada por batería. Para archivos orientados a E/S secuenciales, el almacenamiento en HDD con caché de escritura respaldado por batería debería ser lo suficientemente bueno para MySQL. Tenga en cuenta que es probable que se degrade el rendimiento si la batería está agotada.
Cubriremos esta área (estimación del rendimiento del disco y asignación de archivos) en una publicación separada.
Planificación y dimensionamiento de capacidad
La planificación de la capacidad puede ayudarnos a construir un servidor de base de datos de producción con suficientes recursos para sobrevivir a las operaciones diarias. También debemos prever necesidades inesperadas, tener en cuenta las necesidades futuras de almacenamiento y rendimiento del disco. Por lo tanto, la planificación de la capacidad es importante para garantizar que la base de datos tenga suficiente espacio para respirar hasta el próximo ciclo de actualización del hardware.
Es mejor ilustrar esto con un ejemplo. Considerando el siguiente escenario:
- Próximo ciclo de hardware:3 años
- Tamaño actual de la base de datos:2013 MB
- Tamaño actual de la copia de seguridad completa (semana N):1177 MB
- Tamaño de la copia de seguridad completa anterior (semana N-1):936 MB
- Tamaño delta:241 MB por semana
- Relación delta:incremento del 25,7 % por semana
- Total de semanas en 3 años:156 semanas
- Estimación del tamaño total de la base de datos:((1177 - 936) x 2013 x 156)/936 =80856 MB ~ 81 GB después de 3 años
Si está utilizando registros binarios, resúmalo del valor que obtuvimos en la sección anterior:
- 81 + 95 =176 GB de almacenamiento para bases de datos y registros binarios.
Agregue al menos un 100 % más de espacio para tareas operativas y de mantenimiento (copia de seguridad local, preparación de datos, registro de errores, archivos del sistema operativo, etc.):
- 176 + 176 =352 GB de espacio total en disco.
En base a esta estimación, podemos concluir que necesitaríamos al menos 352 GB de espacio en disco para nuestra base de datos durante 3 años. Puede utilizar este valor para justificar la compra de su nuevo hardware. Por ejemplo, si desea comprar un nuevo servidor dedicado, puede optar por 6 x 128 SSD RAID 10 con controlador RAID respaldado por batería que le brindará alrededor de 384 GB de espacio total en disco. O, si prefiere la nube, puede obtener 100 GB de almacenamiento en bloque con IOPS aprovisionadas para el uso de nuestra base de datos de 81 GB y usar el almacenamiento en bloque persistente estándar para nuestros registros binarios de 95 GB y otros usos operativos.
¡Feliz dimensionamiento!
