Nota
La
noPaddingyusePowerOf2Sizesopciones MMAPv1 para elcollModlos comandos se eliminan.Debes actualizar a WiredTiger. MongoDB eliminó el motor de almacenamiento MMAPv1 obsoleto en la versión 4.2.
Usa este tutorial para actualizar un set de réplicas y utilizar WiredTiger. El procedimiento actualiza el set de réplicas de forma incremental para evitar el tiempo de inactividad.
Considerations
Los sets de réplicas pueden tener nodos con diferentes motores de almacenamiento. Por lo tanto, puedes actualizar los nodos para usar el motor de almacenamiento WiredTiger de manera escalonada.
Arquitectura de 3nodos de PSA
La "majority" nivel de consistencia de lectura, disponible para WiredTiger, se activa por defecto. Sin embargo, en sets de réplicas de tres nodos con una arquitectura primario-secundario-árbitro (PSA), se puede deshabilitar el "majority" nivel de consistencia de lectura. Deshabilitar el "majority" nivel de consistencia de lectura para una arquitectura PSA de tres nodos evita posibles acumulaciones de presión de caché.
El procedimiento a continuación deshabilita "majority" el nivel de consistencia de lectura para la arquitectura PSA incluyendo --enableMajorityReadConcern false.
Nota
Desactivar "majority" el nivel de consistencia de lectura no afecta la disponibilidad de los change streams.
Para obtener más información sobre la arquitectura PSA y el nivel de consistencia de lectura "majority", consulta Conjuntos de réplicas primario-secundario-árbitro.
Enlace por defecto a localhost
Los binarios de MongoDB, mongod y mongos, se enlazan a localhost por defecto.
XFS y WiredTiger
Con el motor de almacenamiento WiredTiger, se recomienda utilizar XFS para los nodos que contienen datos en Linux. Para obtener más información, consulta Kernels y sistemas de archivos.
Restricciones solo para MMAPv1
Una vez actualizado a WiredTiger, su implementación en WiredTiger no estará sujeto a las siguientes restricciones exclusivas de MMAPv1:
Restricciones de MMAPv1 | Descripción corta |
|---|---|
Número de espacios de nombres | Para MMAPv1, el número de espacios de nombres está limitado al tamaño del archivo de espacio de nombres dividido por 628. |
Tamaño del archivo del espacio de nombres | Para MMAPv1, los archivos de namespace no pueden superar los 2047 megabytes. |
Tamaño de la base de datos | El motor de almacenamiento MMAPv1 limita cada base de datos a no más de 16000 archivos de datos. |
dataSize | Para MMAPv1, una sola instancia de |
Número de colecciones en una base de datos | Para el motor de almacenamiento MMAPv1, el número máximo de colecciones en una base de datos depende del tamaño del archivo de namespace y del número de índices de colecciones en la base de datos. |
Procedimiento
El siguiente procedimiento actualiza el set de réplicas de forma progresiva. El procedimiento actualiza primero los nodos secundarios, luego reduce los nodos primarios y actualiza el nodo degradado.
Para actualizar un nodo a WiredTiger, el procedimiento remueve los datos de un nodo, inicia mongod con WiredTiger y realiza una sincronización inicial.
A. Actualiza los miembros secundarios a WiredTiger.
Actualiza los miembros secundarios uno a la vez:
Apaga el miembro secundario.
En mongosh, cerrar el secundario.
use admin db.shutdownServer()
Prepare un directorio de datos para el nuevo mongod ejecutándose con WiredTiger.
Prepare un directorio de datos para la nueva instancia de mongod que funcionará con el motor de almacenamiento WiredTiger. mongod debe tener permisos de lectura y escritura para este directorio. Puedes borrar el contenido del directorio de datos actual del miembro secundario detenido o crear un directorio completamente nuevo.
mongod con WiredTiger no se iniciará con archivos de datos creados con un motor de almacenamiento diferente.
Actualizar la configuración de WiredTiger.
Elimine cualquier opción de configuración de MMAPv1 de la configuración de la instancia mongod.
Inicia mongod con WiredTiger.
Inicia mongod, especificando wiredTiger como el --storageEngine y el directorio de datos preparado para WiredTiger como el --dbpath.
Especifica opciones adicionales según corresponda, como --bind_ip.
Advertencia
Antes de enlazar a un host que no sea localhost (por ejemplo, Públicamente accesible) dirección IP, asegúrese de que ha protegido su clúster de accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulta la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considera activar la autenticación y fortalecer la infraestructura de red.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
Importante
Si está ejecutando una arquitectura PSA de tres nodos, incluya --enableMajorityReadConcern false para desactivar el nivel de consistencia de lectura majority. Consulte Arquitectura de nodo PSA 3.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)> --enableMajorityReadConcern false
Dado que no existen datos en el --dbpath, el mongod realizará una sincronización inicial. La duración del proceso de sincronización inicial depende del tamaño de la base de datos y de la conexión de red entre los nodos del set de réplicas.
También puedes especificar las opciones en un archivo de configuración. Para especificar el motor de almacenamiento, utiliza el ajuste storage.engine.
Repita los pasos para los miembros secundarios restantes, actualizándolos uno a la vez.
B. Bajar el primario.
Importante
Si actualizas todos los miembros del set de réplicas para usar WiredTiger, asegúrate de que todos los miembros secundarios hayan sido actualizados primero antes de actualizar al primario.
Una vez que todos los miembros secundarios se hayan actualizado a WiredTiger, conecta mongosh al primario y usa rs.stepDown() para hacer que el primario ceda su puesto y forzar la elección de un nuevo primario.
rs.stepDown()
C. Actualizar el primario reducido.
Cuando el principal haya renunciado y se haya convertido en secundario, actualice el secundario para usar WiredTiger como antes:
Apaga el miembro secundario.
En mongosh, cerrar el secundario.
use admin db.shutdownServer()
Prepare un directorio de datos para el nuevo mongod ejecutándose con WiredTiger.
Prepare un directorio de datos para la nueva instancia de mongod que funcionará con el motor de almacenamiento WiredTiger. mongod debe tener permisos de lectura y escritura para este directorio. Puedes borrar el contenido del directorio de datos actual del miembro secundario detenido o crear un directorio completamente nuevo.
mongod con WiredTiger no se iniciará con archivos de datos creados con un motor de almacenamiento diferente.
Actualizar la configuración de WiredTiger.
Elimine cualquier opción de configuración de MMAPv1 de la configuración de la instancia mongod.
Inicia mongod con WiredTiger.
Inicia mongod, especificando wiredTiger como el --storageEngine y el directorio de datos preparado para WiredTiger como el --dbpath.
Especifica opciones adicionales según corresponda, como --bind_ip.
Advertencia
Antes de enlazar a un host que no sea localhost (por ejemplo, Públicamente accesible) dirección IP, asegúrese de que ha protegido su clúster de accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulta la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considera activar la autenticación y fortalecer la infraestructura de red.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
Importante
Si está ejecutando una arquitectura PSA de tres nodos, incluya --enableMajorityReadConcern false para desactivar el nivel de consistencia de lectura majority. Consulte Arquitectura de nodo PSA 3.
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath> --replSet <replSetName> --bind_ip localhost,<hostname(s)|ip address(es)> --enableMajorityReadConcern false
Dado que no existen datos en el --dbpath, el mongod realizará una sincronización inicial. La duración del proceso de sincronización inicial depende del tamaño de la base de datos y de la conexión de red entre los nodos del set de réplicas.
También puedes especificar las opciones en un archivo de configuración. Para especificar el motor de almacenamiento, utiliza el ajuste storage.engine.