Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

Configuración de la base de datos en tiempo de ejecución para implementaciones autogestionadas

La Las interfaces de línea de comandos y archivo de configuración proporcionan a los administradores de MongoDB una gran cantidad de opciones y configuraciones para controlar la operación del sistema de base de datos. Este documento proporciona una visión general de las configuraciones comunes y ejemplos de configuraciones de mejores prácticas para casos de uso comunes.

Si bien ambas interfaces brindan acceso a la misma colección de opciones y configuraciones, este documento usa principalmente la interfaz del archivo de configuración.

  • Si instalaste MongoDB con un administrador de paquetes como yum o apt en Linux o brew en macOS, o con el instalador MSI en Windows, se ha proporcionado un archivo de configuración por defecto como parte de la instalación:

    Plataforma
    Método
    archivo de configuración

    Linux

    aptAdministrador de paquetes yum o zypper.

    /etc/mongod.conf

    macOS

    brew Gestor de paquetes

    /usr/local/etc/mongod.conf (en procesadores Intel), o

    /opt/homebrew/etc/mongod.conf (en Procesadores Apple M1)

    Windows

    Instalador MSI

    <install directory>\bin\mongod.cfg

  • Si ha instalado MongoDB a través de un TGZ o ZIP archivo descargado, debe crear su propio archivo de configuración. La configuración de ejemplo básica es un buen lugar para empezar.

Para instalaciones de paquetes de MongoDB en Linux o macOS, también se proporciona un script de inicialización que utiliza este archivo de configuración por defecto. Este script de inicialización puede ser utilizado para iniciar el mongod en estas plataformas de la siguiente manera:

  • En los sistemas Linux que utilizan el sistema de inicialización systemd (el comando systemctl):

    sudo systemctl start mongod
  • En los sistemas Linux que utilizan el sistema de inicialización SystemV init (el comando service):

    sudo service mongod start
  • En macOS, utiliza el gestor de paquetes brew:

    brew services start mongodb-community@7.0

Si instalaste MongoDB usando un archivo TGZ o ZIP, deberás crear tu propio archivo de configuración. Una configuración de ejemplo básica puede encontrarse más adelante en este documento. Una vez que se haya creado un archivo de configuración, se puede iniciar una instancia de MongoDB con ese archivo de configuración utilizando las opciones --config o -f de mongod. Por ejemplo, en Linux:

mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf

Modifica los valores en el archivo mongod.conf de tu sistema para controlar la configuración de tu instancia de base de datos.

Considera la siguiente configuración básica:

processManagement:
fork: true
net:
bindIp: localhost
port: 27017
storage:
dbPath: /var/lib/mongo
systemLog:
destination: file
path: "/var/log/mongodb/mongod.log"
logAppend: true

Para la mayoría de los servidores independientes, esta es una configuración base suficiente. Hace varias suposiciones, pero considera la siguiente explicación:

  • fork es true, lo que habilita un modo demonio para mongod, esto separa (es decir, "... "hace fork") la base de datos MongoDB de la sesión actual y permite que ejecutes la base de datos como un servidor convencional.

  • bindIp es localhost, lo que obliga al servidor a escuchar solo las solicitudes en la IP de localhost. Ligar solo a interfaces seguras a las que los sistemas a nivel de aplicación puedan acceder con control de acceso proporcionado por el filtrado de red del sistema (es decir, "cortafuegos").

  • port es 27017, que es el puerto por defecto de MongoDB para instancias de bases de datos. MongoDB puede vincularse a cualquier puerto. También puede filtrar el acceso según el puerto mediante herramientas de filtrado de red.

    Nota

    Los sistemas similares a UNIX requieren privilegios de superusuario para conectar procesos a puertos inferiores a 1024.

  • quiet es true. Esto deshabilita todas las entradas más críticas en el archivo de salida/entrada de registro y no se recomienda para sistemas de producción. Si seleccionas esta opción, puedes usar setParameter para modificar esta configuración durante la ejecución.

  • dbPath es /var/lib/mongo, que especifica en dónde MongoDB almacenará sus archivos de datos.

    Si se instaló MongoDB en Linux mediante un gestor de paquetes, como yum o apt, el archivo /etc/mongod.conf incluido con la instalación de MongoDB establece los siguientes valores dbPath predeterminados, según la distribución de Linux:

    Plataforma
    Gestor de paquetes
    predeterminado dbPath

    RHEL / CentOS y Amazon

    yum

    /var/lib/mongo

    SUSE

    zypper

    /var/lib/mongo

    Ubuntu y Debian

    apt

    /var/lib/mongodb

    macOS

    brew

    /usr/local/var/mongodb

    La cuenta de usuario bajo la que se ejecuta mongod necesitará acceso de lectura y escritura a este directorio.

  • systemLog.path es /var/log/mongodb/mongod.log que es donde mongod guardará su salida. Si no configura este valor, mongod guarda toda la salida en la salida estándar (por ejemplo, stdout.)

  • logAppend es true, lo que garantiza que mongod no sobrescriba un archivo de registro existente después de iniciar el servidor.

Dada la configuración por defecto, algunos de estos valores pueden ser redundantes. Sin embargo, en muchas situaciones, el hecho de expresar la configuración explícitamente incrementa la inteligibilidad general del sistema.

Las siguientes opciones de configuración son útiles para limitar el acceso a una instancia de mongod:

net:
bindIp: localhost,10.8.0.10,192.168.4.24,/tmp/mongod.sock
security:
authorization: enabled
net.bindIp

Este ejemplo proporciona cuatro valores en la opción bindIp:

  • localhostla interfaz localhost;

  • 10.8.0.10un dirección IP privada que normalmente se utiliza para redes locales e interfaces de VPN;

  • 192.168.4.24una interfaz de red privada que se utiliza normalmente para redes locales; y

  • /tmp/mongod.sock, una ruta de socket de dominio Unix.

Debido a que las instancias de producción de MongoDB necesitan ser accesibles desde varios servidores de bases de datos, es importante vincular MongoDB a múltiples interfaces a las que se pueda acceder desde sus servidores de aplicaciones. Al mismo tiempo es importante limitar estas interfaces a interfaces controladas y protegidas en la capa de red.

security.authorization
Configurar esta opción en true activa el sistema de autorización dentro de MongoDB. Si está habilitado, deberá iniciar sesión conectándose por primera vez a través de la interfaz localhost para crear credenciales de usuario.

Tip

La configuración del set de réplicas es sencilla y solo requiere que el replSetName tenga un valor que sea coherente entre todos los nodos del conjunto. Considere lo siguiente:

replication:
replSetName: set0

Utiliza nombres descriptivos para los conjuntos. Una vez configurado, utilice mongosh para agregar hosts al set de réplicas.

Para habilitar la autenticación del set de réplicas usando archivos clave , agrega la siguiente opción keyFile [1]:

security:
keyFile: /srv/mongodb/keyfile

Configurar keyFile habilita la autenticación y especifica un keyfile para que el miembro del set de réplicas lo use cuando se autentiquen entre ellos.

Tip

La sección Replica Set seguridad para obtener información sobre cómo configurar la autenticación con conjuntos de réplicas.

El documento de replicación para obtener más información sobre la replicación en MongoDB y la configuración general del set de réplicas.

[1] Los clústeres sharded y los sets de réplicas pueden usar X.509 para verificación de membresía en lugar de keyfiles. Para obtener más detalles, consulte X.509.

El particionado requiere mongod instancias con diferentes mongod configuraciones para los servidores de configuración y las particiones. Los servidores de configuración almacenan los metadatos del clúster, mientras que las particiones almacenan los datos.

Para configurar las instancias del servidor de configuración mongod, en el archivo de configuración, especifica configsvr para la configuración de sharding.clusterRole.

Nota

Los servidores de configuración deben implementarse como un set de réplicas.

sharding:
clusterRole: configsvr
net:
bindIp: 10.8.0.12
port: 27001
replication:
replSetName: csRS

Para implementar servidores de configuración como un set de réplicas, los servidores de configuración deben ejecutar el motor de almacenamiento WiredTiger. Initiate el set de réplicas y agregar miembros.

Para configurar las instancias de mongod partición, especifica shardsvr para la setting de sharding.clusterRole y, si ejecutas como un set de réplicas, el nombre del set de réplicas:

sharding:
clusterRole: shardsvr
replication:
replSetName: shardA

Si se ejecuta como un set de réplicas, initiate el set de réplicas de la partición y añade miembros.

Para el router (es decir, mongos), configura al menos un mongos proceso con la siguiente configuración:

sharding:
configDB: csRS/10.8.0.12:27001

Puedes especificar miembros adicionales del set de réplicas de servidores de configuración especificando los nombres de host y los puertos en forma de una lista separada por comas después del nombre del set de réplicas.

Tip

La sección Particionado del manual para obtener más información sobre particionado y configuración de clústeres.

En muchos casos, no se recomienda ejecutar varias instancias de mongod en un solo sistema. En algunos tipos de implementaciones [2] y por motivos de prueba, puede que necesites ejecutar más de un mongod en un solo sistema.

En estos casos, use una Configuración base para cada instancia, pero tenga en cuenta los siguientes valores de configuración:

storage:
dbPath: /var/lib/mongo/db0/
processManagement:
pidFilePath: /var/lib/mongo/db0.pid

El valor dbPath controla la ubicación del directorio de datos de la instancia mongod. Asegúrate de que cada base de datos tenga un directorio de datos distinto y bien etiquetado. El pidFilePath controla donde el proceso mongod coloca su archivo de ID de proceso (PID). Como este rastrea el archivo específico mongod, es crucial que el archivo sea único y esté bien etiquetado para facilitar el inicio y la detención de estos procesos.

Cree scripts de inicio adicionales y/o ajuste su configuración de MongoDB existente y el script de inicio según sea necesario para controlar estos procesos.

[2] Los sistemas single-tenant con SSD u otros discos de alto rendimiento pueden ofrecer niveles aceptables de rendimiento para múltiples instancias mongod. Además, es posible que se encuentre con que varias bases de datos con conjuntos de trabajo pequeños pueden funcionar de manera aceptable en un solo sistema.

Las siguientes opciones de configuración controlan varios comportamientos de mongod con fines de diagnóstico:

  • operationProfiling.mode establece el nivel de perfilador de base de datos. El perfilador no está activo por defecto debido al posible impacto del propio perfilador en el rendimiento. A menos que esta configuración esté activada, las consultas no se perfilan.

  • operationProfiling.slowOpThresholdMs configures the threshold which determines whether a query is "slow" for the purpose of the logging system and the profiler. The default value is 100 milliseconds. Set to a lower value if the logging system and the database profiler do not return useful results or set to a higher value to only log the longest running queries.

    Los miembros secundarios de un set de réplicas ahora registran entradas de oplog que tardan más que el umbral de una operación lenta en aplicarse. Estos mensajes lentos del oplog:

    • Se registran para los secundarios en el diagnostic log.

    • Se documentan en el registro bajo el componente REPL con el texto applied op: <oplog entry> took <num>ms.

    • No depende de los niveles de registro (ya sea a nivel del sistema o del componente)

    • No depende del nivel de perfil.

    • Se ven afectados por slowOpSampleRate.

    El perfilador no captura entradas lentas del oplog.

  • systemLog.verbosity controla la cantidad de registros que mongod escribe en el registro. Utiliza esta opción solo si tienes un problema que no se refleja en el nivel de registro normal.

    También puede especificar el nivel de verbosidad para componentes específicos utilizando el ajuste systemLog.component.<name>.verbosity. Para los componentes disponibles, consulte component verbosity settings.

Para obtener más información, consulte también perfilador de base de datos y MongoDB Performance.

Volver

Configuración y Mantenimiento

En esta página