¿Es malo tener un disco duro muy lleno en un servidor de base de datos de alto tráfico?

Ejecutar un servidor Ubuntu con MySQL para un servidor de base de datos de producción de alto tráfico. Nada más se está ejecutando en la máquina, excepto la instancia de MySQL.

Almacenamos copias de seguridad diarias de la base de datos en el servidor de base de datos, ¿hay algún impacto en el rendimiento o razón por la que deberíamos mantener el disco duro relativamente vacío? Si el disco se llena hasta 86% + con la base de datos y todas las copias de seguridad, ¿perjudica el rendimiento?

Entonces, ¿el servidor de base de datos que se ejecuta con 86-90% o más de capacidad total funcionaría menos que el servidor que se ejecuta con solo un 10% de disco lleno?

El tamaño total del disco en el servidor es superior a 1 TB, por lo que incluso el 10% del disco debería ser suficiente para el intercambio básico de O / S y demás.

En primer lugar, NO desea mantener las copias de seguridad de su base de datos en la misma unidad física o grupo RAID que su base de datos. La razón de esto es que una falla de disco (si está ejecutando sin protección RAID) o una falla RAID catastrófica (si está usando RAID-1 o RAID-5) hará que pierda su base de datos y sus copias de seguridad de la base de datos.

Su pregunta sobre el rendimiento del disco se relaciona con cuán llena está una unidad de disco depende de cómo se accede a los datos en el disco. Para los discos giratorios hay dos factores físicos que afectan el rendimiento de E / S. Son:

• tiempo de búsqueda: que es el tiempo que le lleva a la unidad de disco mover el cabezal del disco desde su posición de pista actual a la pista que contiene los datos solicitados

• latencia rotacional, que es el tiempo promedio que tardan los datos deseados en llegar al cabezal de lectura a medida que gira la unidad, para una unidad de 15K RPM, esto es 2 ms (milisegundos)

Qué tan llena esté su unidad puede afectar el tiempo promedio de búsqueda que experimentan las E / S de su servidor. Por ejemplo, si su unidad está llena y tiene tablas de base de datos que se encuentran físicamente en la unidad en los extremos opuestos de las bandejas del disco, a medida que realiza E / S accediendo a los datos de cada una de estas tablas, esas E / S experimentarán El tiempo máximo de búsqueda de la unidad.

Dicho esto, sin embargo, si su unidad está llena y su aplicación accede solo a una pequeña fracción de los datos almacenados en la unidad y toda esta información se encuentra contiguamente en la unidad, entonces estas E / S se verán mínimamente afectadas por el tiempo de búsqueda .

Desafortunadamente, la respuesta a esta pregunta es que "su millaje variará", lo que significa que la forma en que su aplicación acceda a los datos y dónde se encuentran esos datos determinará cuál será su rendimiento de E / S.

Además, como lo menciona @gravyface, sería una "mejor práctica" separar los requisitos de almacenamiento de su sistema operativo de su base de datos. Nuevamente, esto sería para ayudar a minimizar el movimiento de la cabeza en la superficie del disco, ya que tener ambos en la misma unidad podría causar una búsqueda constante entre el sistema operativo y las áreas de la base de datos de la unidad, ya que tanto el sistema operativo como el software de la base de datos realizan solicitudes de E / S.

Aquí hay dos ángulos a considerar: rendimiento y robustez.

En términos de rendimiento, generalmente se recomienda tener ejes de disco separados (o grupos RAID / conjuntos de unidades) para:

1. El material del sistema operativo (binarios, registros, directorios de inicio, etc.)
2. Espacio de intercambio (que puede combinarse con (1) si no espera usar el intercambio)
3. El DB de producción
4. Los registros de transacciones del DB de producción (si se usan)
5. Bases de datos / copias de seguridad

El razonamiento detrás de esto es bastante sencillo: no desea que el rendimiento de la base de datos se vea afectado por "otras cosas" que exigen el disco (por ejemplo, si la máquina comienza a intercambiar mucho y la partición de intercambio está en el otro lado del disco de los datos de la base de datos que usted tiene un disco largo con el que lidiar).

Desde el punto de vista de la robustez, desea el mismo tipo de avería, pero por una razón diferente: como otros han señalado, no desea que un disco fallido elimine tanto su base de datos como sus copias de seguridad (aunque en realidad debería copiar las copias de seguridad) el servidor de todos modos en caso de una falla catastrófica).

También desea evitar cualquier configuración con una /partición monolítica que lo contenga todo; este es un error desafortunado, trágico y alarmantemente común cometido en el mundo Linux que no es compartido por los otros sistemas similares a Unix.
Como Gravyface mencionó en su comentario, si de alguna manera logras llenar /tu sistema, seguramente se bloqueará, y la limpieza / recuperación puede llevar mucho tiempo y ser costoso si el sistema tiene una sola /partición en lugar de una jerarquía bien estructurada de puntos de montaje.

Recomiendo mover la base de datos y las copias de seguridad temporales (ver a continuación) a una partición diferente a la raíz (/).

Además, elabore un esquema de rotación / retención razonable para sus copias de seguridad de volcado de bases de datos comprimidas (supuestas). (Por lo general) no hay razón para mantener tantas copias de las copias de seguridad en el disco local. No hace nada para la recuperación ante desastres y cuando se mueve fuera del sitio, debe eliminarse del disco.

Eso es prácticamente un procedimiento operativo estándar.

Esto me recordó un error en NetApp donde los sistemas de archivos que están casi llenos tuvieron un rendimiento significativamente menor (como la mitad). (Es cierto que fue hace unos años).

La respuesta como todos dijeron es que depende, pero vale la pena pensarlo detenidamente.

La desventaja principal de los sistemas de archivos completos es la lista de inodos libres que probablemente estén fragmentados y en todas partes.

Hay tres tipos de datos que se encuentran en el disco duro para una base de datos.

1. Su archivo de base de datos real. Este será un gran archivo preasignado que generalmente crece en grandes fragmentos (10%, por ejemplo).
2. Registros, su registro de transacciones que se escribe, borra, escribe, etc. de forma continua ...
3. Archivos temporales para consultas grandes que no se pueden ejecutar en la memoria.

(1) solo necesita espacio libre al asignar más espacio para su conjunto de archivos. Si su base de datos no está creciendo, no debería verse afectada por un sistema de archivos con poco espacio en disco. Sin embargo, si está asignando, podría pedir una porción muy grande que no cabe en ninguna lista gratuita que fragmente inmediatamente su base de datos y provoque la búsqueda cuando necesite datos listos en la memoria.

(2) una ingenua impelementación de registros donde utiliza el sistema operativo para gestionar la asignación de espacio y eliminarlo sufrirá. Suponiendo que su base de datos no sea de solo lectura, habrá un flujo constante de registros, con frecuencia se fragmentarán en un espacio bajo en el disco duro. En última instancia, esto dañará su rendimiento de escritura.

(3) tempDB, si el DB lo necesita para consultas escritas de mala calidad, o no tiene suficiente RAM, entonces tiene problemas más grandes que un espacio en disco bajo, lo que causa problemas de rendimiento, ya que incluso su rendimiento de lectura podría quedar vinculado al disco. También corre el riesgo de una interrupción si MySql necesita asignar espacio en disco para tempDB y el disco duro se agota.

Acerca de las copias de seguridad ...

1. Todas las empresas en las que he trabajado mantienen copias de seguridad en la misma máquina. Cuando se trata de una restauración (a quién le importan las copias de seguridad, son las restauraciones las que cuentan). Nada va a superar la velocidad de tener el archivo db allí mismo en el mismo disco.
2. Con suerte obvio, asegúrese de que las copias de seguridad no sean solo locales.

En resumen, diría que sobrevivirás siempre que tu base de datos no escriba mucho. Si es así, entonces el bajo espacio en disco es un problema. Pero si fuera usted, trabajaría en lo siguiente más temprano que tarde.

1. Confirmando que tengo suficiente RAM
2. Segregación de registros y todos los datos transitorios de su base de datos.
3. Segregando su sistema operativo, su instalación de MySql del resto.

Use husos y controladores separados si puede para 1.

Seguido por husillos separados

Seguido por las particiones separadas de un pobre.

Recientemente tuve un problema similar cuando utilicé todo el espacio en disco en uno de mis servidores de replicación. El efecto inmediato fue que la replicación se bloqueara y luego no pude iniciar sesión en MySQL porque el archivo mysqld.sock no se pudo abrir.