Nota
La
noPaddingyusePowerOf2Sizesopciones MMAPv1 para elcollModlos comandos se eliminan.Debe actualizar a WiredTiger. MongoDB eliminó el motor de almacenamiento obsoleto MMAPv1 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é.
La procedimiento a continuación deshabilita la "majority" nivel de consistencia de lectura para la arquitectura PSA al incluir --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 de PSA y leer la inquietud,consulte Conjuntos "majority"de réplicas de árbitro primario-secundario.
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 exclusivas de 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 espacio de nombres no pueden tener más de 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 no puede administrar un conjunto de datos que exceda el espacio máximo de direcciones de memoria virtual proporcionado por el sistema operativo |
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.
Actualice los miembros secundarios uno a la vez:
Apaga el miembro secundario.
mongoshEn, apague 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 vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar 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 --dbpath en,mongod realizará una sincronización inicial. La duración de esta sincronización inicial depende del tamaño de la base de datos y de la conexión de red entre los miembros del conjunto 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 actualiza todos los miembros del conjunto de réplicas para usar WiredTiger, asegúrese de que todos los miembros secundarios se hayan actualizado primero antes de actualizar el principal.
Una vez que todos los miembros secundarios se hayan actualizado a WiredTiger, conecte al mongosh rs.stepDown() primario y use para reducir el primario 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.
mongoshEn, apague 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 vincular la instancia a una dirección IP de acceso público, se debe asegurar el clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, se debe consultar Checklist de seguridad para implementaciones autogestionadas. Como mínimo, se debe considerar habilitar la autenticación y reforzar 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 --dbpath en,mongod realizará una sincronización inicial. La duración de esta sincronización inicial depende del tamaño de la base de datos y de la conexión de red entre los miembros del conjunto 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.