Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

servidor de configuración

Los servidores de configuración almacenan los metadatos de un clúster particionado. Los metadatos reflejan el estado y la organización de todos los datos y componentes dentro del clúster dividido. Los metadatos incluyen la lista de fragmentos en cada partición y los rangos que definen los fragmentos.

La Las instancias mongos almacenan en caché estos datos y los utilizan para dirigir las operaciones de lectura y escritura a las particiones correctas. mongos actualiza la caché cuando hay cambios de metadatos para el clúster, como cuando se agrega una partición. Las particiones también leen los metadatos de los fragmentos de los servidores de configuración.

Los servidores de configuración también almacenan información de configuración de autenticación en implementaciones autoadministradas, como control de acceso basado en roles o configuraciones de autenticación interna para el clúster.

MongoDB también utiliza los servidores de configuración para gestionar bloqueos distribuidos.

Cada clúster fragmentado debe tener sus propios servidores de configuración. No utilices los mismos servidores de configuración para diferentes clústeres.

Advertencia

Las operaciones administrativas realizadas en los servidores de configuración pueden tener un impacto significativo en el rendimiento y la disponibilidad del clúster fragmentado. Según la cantidad de servidores de configuración afectados, el clúster puede estar en modo de solo lectura o sin conexión durante un tiempo.

A partir de MongoDB,8.0 puede configurar un servidor de configuración para almacenar datos de la aplicación, además de los metadatos habituales del clúster fragmentado. El servidor de configuración se conoce como fragmento de configuración. Encontrará más información más adelante en esta página, en el... La sección Particiones de configuración.

Las siguientes restricciones se aplican a una configuración de conjunto de réplicas cuando se utiliza para servidores de configuración:

  • Debe tener cero árbitros.

  • No debe tener miembros retrasados.

  • Deben crear índices (i.e. ningún nodo debería tener el ajuste members[n].buildIndexes ajustado en falso).

La base de datos admin y la base de datos config existen en los servidores de configuración.

La base de datos admin contiene las colecciones relacionadas con la autenticación y la autorización, así como las otras colecciones del sistema.* para uso interno.

La base de datos de config contiene las colecciones que contienen los metadatos del clúster compartido. MongoDB escribe datos en la base de datos config cuando cambian los metadatos, como después de una migración de fragmento o una división de fragmento.

Los usuarios deben evitar escribir directamente en la base de datos de configuración durante el funcionamiento o mantenimiento normal.

Al escribir en los servidores de configuración, MongoDB utiliza una preocupación de escritura "majority"de.

MongoDB lee de la base de datos admin para datos de autenticación y autorización y otros usos internos.

MongoDB lee de la base de datos config cuando se inicia un mongos o después de un cambio en los metadatos, como después de la migración de un fragmento. Las particiones también leen los metadatos de los fragmentos de los servidores de configuración.

Al leer desde los servidores de configuración del conjunto de réplicas, MongoDB utiliza un nivel de preocupación de "majority" lectura de.

Para que una operación tenga éxito, la visualización de los metadatos en el nodo específico de la partición debe estar actualizada. La partición y el router que emite la solicitud deben tener la misma versión de metadatos de los fragmentos.

Si los metadatos no están actualizados, la operación falla con el error StaleConfig y se activa el proceso de actualización de metadatos. Actualizar los metadatos puede introducir una latencia operativa adicional.

En un secundario, una actualización de metadatos puede tardar mucho tiempo si hay un atraso de la replicación significativo. Para lecturas secundarias, configure maxStalenessSeconds para minimizar el impacto del atraso de la replicación.

Si el conjunto de réplicas del servidor de configuración pierde su servidor principal y no puede elegir uno, los metadatos del clúster pasan a ser de solo lectura. Aún se pueden leer y escribir datos desde los fragmentos, pero no se realizarán migraciones ni divisiones de fragmentos hasta que el conjunto de réplicas pueda elegir uno principal.

En un clúster fragmentado, mongod las mongos instancias y monitorean los conjuntos de réplicas en el clúster fragmentado (por ejemplo, conjuntos de réplicas de fragmentos, conjunto de réplicas del servidor de configuración).

Si todos los servidores de configuración dejan de estar disponibles, el clúster puede quedar inoperativo. Para garantizar que los servidores de configuración permanezcan disponibles e intactos, es fundamental realizar copias de seguridad de los mismos. Los datos del servidor de configuración son pequeños en comparación con los datos almacenados en un clúster, y su carga de actividad es relativamente baja.

Ver Un miembro del set de réplicas del servidor de configuración se volvió no disponible para más información.

Los servidores de configuración almacenan metadatos en la base de datos config.

Importante

Realice siempre una copia de seguridad de la base de datos config antes de realizar cualquier tarea de mantenimiento en el servidor de configuración.

Para acceder a la config base de datos, emita el siguiente comando mongosh en:

use config

En general, nunca debe editar directamente el contenido de la base de datos config. La base de datos config contiene las siguientes colecciones:

Para obtener más información sobre estas colecciones y su rol en clústeres particionados, consulta Base de datos de configuración. Consulta Operaciones de lectura y escritura en los servidores de configuración para obtener más información sobre las lecturas y actualizaciones de los metadatos.

Utiliza Autenticación interna/membresía autogestionada para aplicar la seguridad entre clústeres y evitar que componentes de clúster no autorizados accedan al clúster. Debes iniciar cada mongod en el clúster con la configuración de seguridad adecuada para aplicar la autenticación interna.

A partir de MongoDB 5.3, SCRAM-SHA-1 no se puede usar para la autenticación intraclúster. Solo se admite SCRAM-SHA-256.

En versiones anteriores de MongoDB, se pueden usar tanto SCRAM-SHA-1 como SCRAM-SHA-256 para la autenticación intra-clúster, incluso si SCRAM no está explícitamente habilitado.

Consulta Implementar clúster fragmentado autogestionado con autenticación de clave para aprender cómo implementar un clúster fragmentado seguro.

Nuevo en la versión 8.0.

A partir de MongoDB 8.0, puedes:

  • Configura un servidor de configuración para almacenar tus datos de la aplicación además de los metadatos habituales del clúster particionado. Un servidor de configuración que almacena datos de la aplicación se denomina partición de configuración.

  • Transicionar un servidor de configuración entre una partición de configuración y un servidor de configuración dedicado.

Un clúster requiere un servidor de configuración, pero puede ser una partición de configuración en lugar de un servidor de configuración dedicado. El uso de una partición de configuración reduce el número de nodos requeridos y puede simplificar su implementación.

Si su aplicación tiene requisitos exigentes de disponibilidad y resiliencia, considere implementar un servidor de configuración dedicado. Un servidor de configuración dedicado proporciona aislamiento, recursos dedicados y un rendimiento coherente para operaciones críticas del clúster.

No se puede utilizar el mismo fragmento de configuración para varios clústeres fragmentados.

Para configurar un servidor de configuración dedicado para que funcione como un fragmento de configuración, ejecute el comando transitionFromDedicatedConfigServer.

Para configurar un fragmento de configuración para que funcione como un servidor de configuración dedicado, ejecute el comando transitionToDedicatedConfigServer.

Un usuario creado en una partición de configuración tiene el mismo comportamiento que un usuario creado en un servidor de configuración dedicado.

Usted puede confirmar que un clúster particionado utiliza una partición de configuración mediante uno de los siguientes métodos:

  • Ejecuta el método sh.isConfigShardEnabled() en mongosh. Si la salida de sh.isConfigShardEnabled() contiene enabled: true, el clúster utiliza una partición de configuración. Si la salida contiene enabled: false, el clúster no utiliza una partición de configuración.

  • Ejecútate el comando listShards contra la base de datos admin mientras estés conectada a un mongos e inspecciona la salida para encontrar un documento donde _id esté configurado en "config". Si la salida de listShards no contiene un documento donde _id esté configurado en "config", el clúster no utiliza una partición de configuración.

El siguiente ejemplo ejecuta el comando listShards e intenta encontrar un documento donde _id esté establecido en "config".

db.adminCommand({ listShards: 1 })["shards"].find(element => element._id === "config")

En este ejemplo, el documento devuelto tiene _id asignado a "config", lo que confirma que este clúster utiliza una partición de configuración.

{
_id: "config",
host: "configRepl/localhost:27018",
state: 1,
topologyTime: Timestamp({ t: 1732218671, i: 13 }),
replSetConfigVersion: Long('-1')
}

Si su clúster tiene un fragmento de configuración y necesita degradar la versión de compatibilidad de funciones a una anterior 8.0 a, conéctese a mongos y realice este procedimiento:

1

Para comenzar a configurar un shard de configuración para que funcione como un servidor dedicado de configuración, ejecuta transitionToDedicatedConfigServer:

db.adminCommand( {
transitionToDedicatedConfigServer: 1
} )
2
  1. Para listar todas las bases de datos en el clúster, ejecute listDatabases:

    db.adminCommand( { listDatabases: 1, nameOnly: true } )

    Excluye las bases de datos admin y config.

  2. Para cada base de datos, enumere todas las colecciones en la base de datos.

    Para listar todas las colecciones de la base de datos, ejecuta listCollections.

    db.adminCommand(
    {
    listCollections: 1,
    nameOnly: true,
    filter: { type: { $ne: "view" } }
    }
    )

    Excluir colecciones que comiencen con system.

3

Para mover la colección a una nueva partición, ejecute moveCollection:

db.adminCommand(
{
moveCollection: "<database>.<collection>",
toShard: "<new shard>",
}
)
4

Para verificar que el balanceador haya movido los datos de recopilación fragmentados fuera del servidor de configuración, ejecute transitionToDedicatedConfigServer nuevamente:

db.adminCommand( {
transitionToDedicatedConfigServer: 1
} )

La respuesta después de un movimiento de datos exitoso contiene state: "completed". Si la respuesta contiene state: "pendingDataCleanup", espera un momento y luego sigue llamando a transitionToDedicatedConfigServer hasta que la respuesta del comando contenga state: "completed". Para obtener detalles completos de la respuesta, consulte removeShard.

5

Para configurar la compatibilidad de características entre versiones, ejecute setFeatureCompatibilityVersion:

db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )

Volver

Fragmentos

En esta página