Tengo un servidor Spring Boot que está conectado a un servidor MySQL que se ejecuta en una imagen acoplable separada. Como tal, no puedo hacer algo tan simple como un df ya que la imagen está conectada a través de un URI en la configuración de la ventana acoplable y puede cambiar en las implementaciones de producción. Por ejemplo, podríamos cambiar la base de datos para usar agrupamiento, etc.
Sin embargo, es posible que nos quedemos sin espacio en la base de datos y necesitemos detectarlo. Dado que hay una gran cantidad de datos que podemos eliminar cuando nos quedamos sin espacio, esto es bastante crucial.
Hay muchas respuestas relacionadas con el cálculo de la cantidad de espacio utilizado por la base de datos, eso no es lo que quiero ya que:
Encontré la consulta data_free aquí , pero parece problemática según la siguiente respuesta .
¿Hay otra forma de calcular el tamaño del disco, ya sea a través de una consulta mySQL o mediante una API similar expuesta a través del arranque de primavera?
Parece que necesita esto para ver el espacio libre dentro de una imagen acoplable:
docker system dfhttps://docs.docker.com/engine/reference/commandline/system_df/ https://www.percona.com/blog/2019/08/21/cleaning-docker-disk-space-usage/
Y se puede ejecutar independientemente de MySQL. Por lo tanto, no veo un problema de CPU.
Debido a todas las molestias relacionadas con Data_free de MySQL y la predicción del uso del disco para una tabla activa, no es posible traducir con precisión el espacio libre en la cantidad de filas que puede agregar antes de quedarse sin espacio.
Si su uso es bastante consistente, ejecute docker system df todos los días (o cada hora) y registre los resultados. Luego, calcule cuándo llegará a cero. Sea pesimista al trazar la línea a través del gráfico.
Dices que puedes "eliminar datos" para liberar espacio. Tenga en cuenta que MySQL, en muchos casos, no devuelve el espacio liberado al sistema operativo (es decir, Docker). En cambio, deja la mesa fragmentada. Es decir, DELETEing filas deja espacio para nuevos INSERTs en la misma tabla. (Hay variaciones sobre esto; podemos discutir más si se vuelve más específico sobre "eliminar datos").
Si el tamaño de los datos no crece o se reduce de forma "regular", ¿al menos sabe cuándo esperar "ráfagas"? Mastique un poco de CPU en la pausa entre ráfagas.
Si puede "eliminar algunos datos" siempre que lo necesite, ¿por qué no mantener los datos podados? Esto distribuiría los gastos generales y (con suerte) mantendría el espacio libre de problemas.
Si está hablando de tablas 'enormes', tengo varios consejos para hacer eliminaciones grandes de manera eficiente .
Plan B
Docker puede llegar al sistema de archivos principal para directorios. Coloque el árbol de datos de MySQL allí. Entonces no estás preguntando por el espacio en Docker, sino por el espacio en el sistema principal. (¿Supongo que tienes mucho más espacio libre allí?)