¿Por qué mis "bytes de volumen utilizados" siempre aumentan en mi clúster de Amazon Aurora?


11

Tengo un clúster Aurora DB de Amazon (AWS) , y cada día [Billed] Volume Bytes Usedaumenta.

VolumeBytes: métrica de CloudWatch utilizada en el tiempo

He verificado el tamaño de todas mis tablas (en todas mis bases de datos en ese clúster) usando la INFORMATION_SCHEMA.TABLEStabla:

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

Total: 53 GB

Entonces, ¿por qué me cobran casi 75 GB en este momento?

Entiendo que el espacio aprovisionado nunca se puede liberar, de la misma manera que los archivos ibdata en un servidor MySQL normal nunca pueden reducirse; Estoy bien con eso. Esto está documentado y es aceptable.

Mi problema es que cada día aumenta el espacio que me facturan. Y estoy seguro de que NO estoy usando 75GB de espacio temporalmente. Si tuviera que hacer algo así, lo entendería. Es como si el espacio de almacenamiento que estoy liberando, eliminando filas de mis tablas, o soltando tablas, o incluso soltando bases de datos, nunca se reutilice.

Me he puesto en contacto con el soporte de AWS (premium) varias veces, y nunca pude obtener una buena explicación de por qué.
He recibido sugerencias para ejecutar OPTIMIZE TABLEen las tablas en las que hay mucho free_space(según la INFORMATION_SCHEMA.TABLEStabla), o para verificar la longitud del historial de InnoDB, para asegurarme de que los datos eliminados no se mantengan en el segmento de reversión (ref: MVCC ) y reinicie las instancias para asegurarse de que el segmento de reversión esté vacío.
Ninguno de esos ayudó.

Respuestas:


18

Aquí hay muchas cosas en juego ...

  1. Cada tabla se almacena en su propio espacio de tabla.

    De manera predeterminada, el grupo de parámetros para los grupos de Aurora (con nombre default.aurora5.6) define innodb_file_per_table = ON. Eso significa que cada tabla se almacena en un archivo separado, en el clúster de almacenamiento Aurora. Puede ver qué espacio de tabla se utiliza para cada una de sus tablas con esta consulta:

    SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

    Nota: no he intentado cambiar innodb_file_per_tablea OFF. Tal vez eso ayudaría ...?

  2. El espacio de almacenamiento liberado al eliminar espacios de tabla NO se reutiliza

    Citando el soporte premium de AWS:

    Debido al diseño único del motor Aurora Storage para aumentar su rendimiento y tolerancia a fallas, Aurora no tiene una funcionalidad para desfragmentar espacios de tabla de archivo por tabla de la misma manera que MySQL estándar.

    Actualmente, Aurora desafortunadamente no tiene una forma de reducir los espacios de tabla como lo hace MySQL estándar y todo el espacio fragmentado se cobra porque está incluido en VolumeBytesUsed.
    La razón por la que Aurora no puede reclamar el espacio de una tabla descartada de la misma manera que MySQL estándar es que los datos de la tabla se almacenan de una manera completamente diferente a una base de datos MySQL estándar con un solo volumen de almacenamiento.

    Si suelta una tabla o fila en Aurora, el espacio no se recupera en el volumen del clúster de Auroras debido a este diseño complicado.
    Esta incapacidad para recuperar pequeñas cantidades de espacio de almacenamiento es un sacrificio hecho para obtener las ganancias de rendimiento adicionales del volumen de almacenamiento del clúster de Auroras y la tolerancia a las fallas mejorada de Aurora.

    Pero hay una forma oscura de reutilizar parte de ese espacio desperdiciado ...
    Nuevamente, cite el soporte premium de AWS:

    Una vez que su conjunto de datos excede un cierto tamaño (aproximadamente 160 GB), puede comenzar a reclamar espacio en bloques de 160 GB para su reutilización, por ejemplo, si tiene 400 GB en su volumen de clúster Aurora y DROP 160 GB o más de tablas que Aurora puede reutilice automáticamente 160 GB de datos. Sin embargo, puede ser lento recuperar este espacio.
    La razón de la gran cantidad de datos que se deben liberar de una vez se debe al diseño único de Auroras como un motor de base de datos a escala empresarial, a diferencia del MySQL estándar que no se puede usar en esta escala.

  3. ¡OPTIMIZAR TABLA es malo!

    Debido a que Aurora se basa en MySQL 5.6, OPTIMIZE TABLEse asigna a ALTER TABLE ... FORCE, que reconstruye la tabla para actualizar las estadísticas del índice y liberar espacio no utilizado en el índice agrupado. Efectivamente, junto con innodb_file_per_table = ONeso, significa ejecutar un OPTIMIZE TABLEcrea un nuevo archivo de espacio de tabla y elimina el antiguo. Dado que eliminar un archivo de espacio de tabla no libera el almacenamiento que estaba utilizando, eso significa OPTIMIZE TABLEque siempre se aprovisionará más almacenamiento. ¡Ay!

    Ref: https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

  4. Usando tablas temporales

    De manera predeterminada, el grupo de parámetros para las instancias de Aurora (con nombre default.aurora5.6) define default_tmp_storage_engine = InnoDB. Eso significa que cada vez que voy a crear una TEMPORARYtabla, se almacena, junto con todos mis regulares tablas, en el clúster de almacenamiento Aurora. Eso significa que se proporciona un nuevo espacio para contener esas tablas, lo que aumenta el volumen total de Bytes utilizados.
    La solución para esto es bastante simple: cambie el default_tmp_storage_enginevalor del parámetro a MyISAM. Esto obligará a Aurora a crear las TEMPORARYtablas en el almacenamiento local de la instancia.
    De nota: el almacenamiento local de las instancias es limitado; vea la Free Local Storagemétrica en CloudWatch para ver cuánto almacenamiento tienen sus instancias. Las instancias más grandes (más costosas) tienen más almacenamiento local.

    Ref: ninguno todavía; La documentación actual de Amazon Aurora no menciona esto. Le pedí al equipo de soporte de AWS que actualizara la documentación, y actualizaré mi respuesta si / una vez que lo hagan.


1
Esta es una gran respuesta, y vaya , esas son algunas advertencias importantes. Me alegro de haber visto esto.
ceejayoz

Ídem. Noté que un servidor de base de datos tenía hasta 300 GB, para una base de datos con un tamaño informado por MySQL de 54 GB ... si el espacio nunca se reclama, ese es un buen ejemplo de lo que sucede cuando se tienen muchas tablas escritas con frecuencia ( por ejemplo, tablas de registro, tablas de índice, etc.).
geerlingguy

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.