ApsaraDB for MongoDB:Alta utilización de espacio en disco en instancias de MongoDB

Arquitectura de conjunto de réplicas

Si su instancia de ApsaraDB for MongoDB utiliza una arquitectura de conjunto de réplicas, inicie sesión en la consola de ApsaraDB for MongoDB y utilice los siguientes métodos para comprobar su uso de espacio:

• Descripción general

  En la página Basic Information, vaya a la sección Specification Information para consultar el Disk space y el Usage de la instancia.

• Análisis de gráficos de monitoreo

  En el panel de navegación izquierdo, haga clic en Monitoring Information. Seleccione un nodo objetivo para consultar su Disk Usage (Bytes) y Disk Usage (%).

  Una instancia de conjunto de réplicas de ApsaraDB for MongoDB consta de un nodo primario para operaciones de lectura y escritura, uno o más nodos secundarios para alta disponibilidad, un nodo oculto y nodos de solo lectura opcionales. El uso de espacio de cada nodo se compone de data_size y log_size, donde ins_size = data_size + log_size:

  • data_size: Espacio en disco utilizado por los datos, excluyendo la base de datos local. Esto incluye archivos de datos (con prefijo collection), archivos de índice (con prefijo index) y archivos de metadatos como WiredTiger.wt.

  • log_size: Tamaño físico de la base de datos local, tamaño de los registros de tiempo de ejecución de MongoDB y tamaño de algunos registros de auditoría.

• Análisis detallado

  Utilice los siguientes métodos para realizar un análisis detallado del uso de espacio:

  • Use los comandos nativos de MongoDB db.stats() y db.$collection_name.stats().

    Para obtener más información sobre estos comandos, consulte la siguiente documentación de MongoDB:

    • db.stats()

    • db.collection.stats()

    • db.collection.storageSize()

    • db.collection.totalIndexSize()

    • db.collection.totalSize()

  • Utilice la página CloudDBA > Storage Analysis.

    En la página CloudDBA > Storage Analysis, puede consultar la siguiente información:

    • Resumen del uso de espacio para bases de datos y colecciones, su crecimiento diario promedio y la predicción de días restantes hasta que se llene el almacenamiento.

    • Uso de espacio de bases de datos y tablas anómalas.

    • Uso detallado de espacio para colecciones de negocio, incluido el tamaño de archivos de índice, tamaño de archivos de datos, análisis de relación de compresión y tamaño promedio de documento.

Arquitectura de clúster fragmentado

Si su instancia de ApsaraDB for MongoDB utiliza una arquitectura de clúster fragmentado, inicie sesión en la consola de ApsaraDB for MongoDB y utilice los siguientes métodos para comprobar su uso de espacio:

• Análisis de gráficos de monitoreo

  En la página Monitoring Information, seleccione un nodo objetivo para consultar su Disk Usage (Bytes) y Disk Usage (%).

• Análisis detallado

  Analice secuencialmente el uso de espacio de cada nodo mediante los comandos nativos de MongoDB db.stats() y db.$collection_name.stats().

Impacto en la instancia durante la compactación

La operación compact puede consumir mucho tiempo porque su duración es proporcional al tamaño de la colección. Para evitar afectar las operaciones de lectura y escritura, ejecute compact fuera del horario pico.

El método compact

Para minimizar el impacto en su negocio, ejecute primero el comando db.runCommand({compact:"collectionName"}) en un nodo secundario y luego realice un cambio de rol entre primario y secundario. Reemplace collectionName con el nombre de su colección.

Para obtener más información sobre cómo usar el comando compact, consulte Defragment disks to improve disk utilization.

Brecha de espacio por registros de journal grandes

En versiones de ApsaraDB for MongoDB anteriores a la 4.0, si el número de archivos abiertos en el host alcanza su límite, el hilo de limpieza del servidor de registros interno se interrumpe y el registro de journal crece indefinidamente. Si observa entradas de registro similares a las siguientes en los registros de tiempo de ejecución de MongoDB, actualice el kernel a ApsaraDB for MongoDB 4.0 o posterior. Como solución temporal, reinicie el proceso mongod. Para más detalles, consulte log-server thread exit quietly on error while the mongodb process still running.

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system 
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.

Crecimiento de registros por retraso de replicación y copias de seguridad

Cuando una instancia de ApsaraDB for MongoDB experimenta un retraso de replicación, el tamaño utilizable del oplog ya no está limitado por la colección de tamaño fijo definida en el archivo de configuración. En teoría, puede crecer hasta el 20% de la capacidad de disco aprovisionada. Una vez resuelto el retraso, el espacio adicional ocupado por el oplog no se recupera automáticamente.

Durante una copia de seguridad física, una instancia de ApsaraDB for MongoDB en un nodo oculto genera numerosos puntos de control, lo que consume más espacio de datos y de registros.

db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
use local
db.runCommand({ compact: "oplog.rs", force: true })

Tipo de clave de fragmentación inapropiado

En un clúster fragmentado, la elección del tipo de clave de fragmentación es crítica. Los dos tipos principales son fragmentación por hash y fragmentación por rangos. Para el equilibrio de disco, la fragmentación por hash suele ser una mejor estrategia que la fragmentación por rangos, ya que ApsaraDB for MongoDB utiliza una función hash interna para distribuir uniformemente los datos entre los fragmentos según los valores de clave. Por el contrario, la fragmentación por rangos distribuye los datos basándose en intervalos de valores de clave, lo que puede concentrar los nuevos datos en un chunk "caliente", provocando una alta E/S de disco en ese fragmento y un desequilibrio de datos a corto plazo.

Campo de clave de fragmentación inapropiado

Aunque el número de chunks en cada fragmento sea similar, la mayor parte de los datos se concentra en unos pocos chunks. Como resultado, los fragmentos que contienen estos chunks "calientes" almacenan significativamente más datos que los demás. Al ejecutar el comando sh.status() y revisar los registros de tiempo de ejecución de ApsaraDB for MongoDB, es posible que vea mensajes de advertencia similares a los siguientes:

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }

El equilibrador de mongos considera principalmente el recuento de chunks en cada fragmento para determinar si los datos están equilibrados. Esto puede llevar a un escenario donde los recuentos de chunks están equilibrados, pero la distribución real de datos está muy sesgada. Esto ocurre porque los valores de la clave de fragmentación dentro de un chunk son casi idénticos. Cuando el chunk alcanza el umbral de división de 64 MB, MongoDB lo divide y crea un chunk vacío. Con el tiempo, aunque aumentan los recuentos de chunks y se producen migraciones, los chunks migrados suelen estar vacíos, lo que resulta en recuentos de chunks equilibrados pero datos desequilibrados. Para solucionar esto, rediseñe su estrategia de fragmentación para utilizar un campo de alta cardinalidad como clave de fragmentación.

Bases de datos no fragmentadas en un clúster fragmentado

Una instancia de clúster fragmentado de ApsaraDB for MongoDB admite tanto bases de datos fragmentadas como no fragmentadas. Todos los datos de una base de datos no fragmentada residen en un único fragmento primario, por lo que si esa base de datos es grande, su fragmento primario puede almacenar significativamente más datos que otros fragmentos.

Este problema también puede ocurrir cuando importa datos de un clúster mongos de origen a uno nuevo, pero olvida configurar la fragmentación en el clúster de destino antes de la importación.

Para abordar estos problemas, se recomienda lo siguiente:

• Si va a inicializar un clúster de destino con una importación, diseñe y habilite la fragmentación antes de comenzar.

• Si tiene muchas bases de datos no fragmentadas de tamaño aproximadamente igual, utilice el comando movePrimary para mover bases de datos específicas a diferentes fragmentos.

• Si existe una base de datos no fragmentada muy grande, se recomienda fragmentarla o migrarla a una instancia independiente de conjunto de réplicas.

• Si se presenta esta situación pero cuenta con suficiente espacio en disco, puede optar por ignorar el problema.

Uso desigual de disco por operaciones moveChunk

Una operación moveChunk escribe datos en un fragmento de destino y luego los elimina del fragmento de origen. De forma predeterminada, la operación de eliminación no libera espacio en disco. En el motor WiredTiger, cada colección tiene archivos de datos e índice separados, y el espacio total en disco no se reduce a menos que se eliminen estos archivos. Este problema es más común cuando se habilita la fragmentación en un clúster que ha estado funcionando durante algún tiempo sin un diseño de fragmentación.

Por lo tanto, después de muchas operaciones moveChunk o de eliminación de documentos, ejecute una operación compact en el fragmento afectado para recuperar el espacio fragmentado.