/ /

Implementar y gestionar Sets de réplicas autogestionados

Referencia

Docs Home

Manual de base de datos

Implementaciones autogestionadas

Implementar y gestionar Sets de réplicas autogestionados

Referencia

Configuración de Set de réplicas autogestionado

Esta versión de la documentación está archivada y ya no recibe soporte. Para actualizar su implementación 6.0, consulte Procedimientos de actualización de MongoDB.7.0

Puede acceder a la configuración de un conjunto de réplicas utilizando el rs.conf()Método o el replSetGetConfig comando.

Para modificar la configuración de un Set de réplicas, utiliza el método rs.reconfig(), pasando un documento de configuración al método. Consulta rs.reconfig() para más información.

Advertencia

Evitar reconfigurar sets de réplicas que contengan miembros de diferentes versiones de MongoDB, ya que las reglas de validación pueden diferir entre versiones de MongoDB.

Ejemplo de documento de configuración de Set de réplicas

El siguiente documento proporciona una representación de un documento de configuración del set de réplicas. La configuración del set de réplicas puede incluir solo un subconjunto de estos ajustes:

{
  _id: <string>,
  version: <int>,
  term: <int>,
  protocolVersion: <number>,
  writeConcernMajorityJournalDefault: <boolean>,
  configsvr: <boolean>,
  members: [
    {
      _id: <int>,
      host: <string>,
      arbiterOnly: <boolean>,
      buildIndexes: <boolean>,
      hidden: <boolean>,
      priority: <number>,
      tags: <document>,
      secondaryDelaySecs: <int>,
      votes: <number>
    },
    ...
  ],
  settings: {
    chainingAllowed : <boolean>,
    heartbeatIntervalMillis : <int>,
    heartbeatTimeoutSecs: <int>,
    electionTimeoutMillis : <int>,
    catchUpTimeoutMillis : <int>,
    getLastErrorModes : <document>,
    getLastErrorDefaults : <document>,
    replicaSetId: <ObjectId>
  }
}

Configuración de los campos de set de réplicas

_id

Tipo: string

El nombre del set de réplicas.

_id debe ser idéntico al replication.replSetName o al valor de --replSet especificado para mongod en la línea de comandos.

Tip

Consulte:

version

Tipo: int

Un número incremental utilizado para distinguir las revisiones del Set de réplicas de la configuración de las iteraciones anteriores de la configuración.

Los miembros del Set de réplicas utilizan term y version para lograr un consenso sobre la configuración de réplica "más reciente". Cuando los miembros comparan documentos de configuración de réplicas, el documento de configuración con un term mayor se considera el "más reciente". Si term es el mismo o está ausente, el documento de configuración con el version mayor se considera "el más reciente".

term

Tipo: int

Solo disponible con featureCompatibilityVersion (compatibilidad de características entre versiones) "4.4" o posterior.

Un número incremental utilizado para distinguir las revisiones del documento de configuración del Set de réplicas de las iteraciones anteriores de la configuración. La term de un documento de configuración coincide con el término del Set de réplicas primario que realizó la reconfiguración. El Primario incrementa su término cada vez que asume el control después de ganar una elección. El primario ignora el campo term si se establece explícitamente en la operación replSetReconfig.

Emitir una reconfiguración forzada remueve el campo term. Cuando el primario siguiente emite replSetReconfig sin fuerza, establece el term a su propio término.

configsvr

Tipo: booleano

Por defecto: false

Se indica si el set de réplicas se utiliza para los servidores de configuración de un clúster. Establecer en true si el set de réplicas es para los servidores de configuración de un clúster.

protocolVersion

Tipo: número

Por defecto: 1

MongoDB solo admite protocolVersion: 1 y ya no admite protocolVersion: 0.

Tip

Versión del protocolo del set de réplicas autogestionado

writeConcernMajorityJournalDefault

Tipo: booleano

Por defecto: true

Se determina el comportamiento del { w: "majority" } nivel de confirmación de escritura si el nivel de confirmación de escritura no especifica explícitamente la opción de diario j.

La siguiente tabla enumera los valores de writeConcernMajorityJournalDefault y el comportamiento { w: "majority" } asociado:

Valor	`{ w: "majority" }` Comportamiento
true	MongoDB reconoce la operación de escritura después de que la mayoría de los miembros votantes hayan escrito en la bitácora en disco. IMPORTANTE: todos los miembros votantes del set de réplicas deben ejecutar con registro en la bitácora cuando `writeConcernMajorityJournalDefault` sea `true`. Si algún nodo votante de un set de réplicas utiliza el motor de almacenamiento en memoria, debe establecer `writeConcernMajorityJournalDefault` en `false`. Si algún nodo votante de un Set de réplicas utiliza el motor de almacenamiento en memoria y `writeConcernMajorityJournalDefault` es `true`, las operaciones de `"majority"` guardar pueden fallar. Estas incluyen operaciones que utilizan inherentemente el nivel de confirmación de escritura `"majority"`, como el comando `replSetStepDown`, o varios métodos `mongosh` que por defecto utilizan el nivel de confirmación de escritura `"majority"`, como los métodos de gestión de usuarios y los métodos de gestión de roles. A partir de la versión 4.2 (y 4.0.13 y 3.6.14 ), si un miembro del set de réplicas utiliza el motor de almacenamiento en memoria (votante o no votante) pero el set de réplicas tiene `writeConcernMajorityJournalDefault` establecido en true, el miembro del set de réplicas registra una advertencia de inicio.
false	MongoDB reconoce la operación de guardar después de que la mayoría de los miembros votantes hayan aplicado la operación en memoria. ADVERTENCIA: Si algún nodo votante de un set de réplicas utiliza el motor de almacenamiento en memoria, debe establecer `writeConcernMajorityJournalDefault` en `false`. A partir de la versión 4.2 (y 4.0.13 y 3.6.14 ), si un miembro del set de réplicas utiliza el motor de almacenamiento en memoria (votante o no votante) pero el set de réplicas tiene `writeConcernMajorityJournalDefault` establecido en true, el miembro del set de réplicas registra una advertencia de inicio. No puedes ejecutar transacciones en un clúster que tenga una partición con `writeConcernMajorityJournalDefault` configurado en `false` (como una partición con un nodo votante que utiliza el motor de almacenamiento en memoria).

Valor

{ w: "majority" } Comportamiento

true

MongoDB reconoce la operación de escritura después de que la mayoría de los miembros votantes hayan escrito en la bitácora en disco.

IMPORTANTE: todos los miembros votantes del set de réplicas deben ejecutar con registro en la bitácora cuando writeConcernMajorityJournalDefault sea true.

Si algún nodo votante de un set de réplicas utiliza el motor de almacenamiento en memoria, debe establecer writeConcernMajorityJournalDefault en false.

Si algún nodo votante de un Set de réplicas utiliza el motor de almacenamiento en memoria y writeConcernMajorityJournalDefault es true, las operaciones de "majority" guardar pueden fallar. Estas incluyen operaciones que utilizan inherentemente el nivel de confirmación de escritura "majority", como el comando replSetStepDown, o varios métodos mongosh que por defecto utilizan el nivel de confirmación de escritura "majority", como los métodos de gestión de usuarios y los métodos de gestión de roles.

A partir de la versión 4.2 (y 4.0.13 y 3.6.14 ), si un miembro del set de réplicas utiliza el motor de almacenamiento en memoria (votante o no votante) pero el set de réplicas tiene writeConcernMajorityJournalDefault establecido en true, el miembro del set de réplicas registra una advertencia de inicio.

false

MongoDB reconoce la operación de guardar después de que la mayoría de los miembros votantes hayan aplicado la operación en memoria.

ADVERTENCIA:

Si algún nodo votante de un set de réplicas utiliza el motor de almacenamiento en memoria, debe establecer writeConcernMajorityJournalDefault en false.

No puedes ejecutar transacciones en un clúster que tenga una partición con writeConcernMajorityJournalDefault configurado en false (como una partición con un nodo votante que utiliza el motor de almacenamiento en memoria).

Tip

`members`

members

Tipo: arreglo

Un arreglo de documentos de configuración de nodos, uno por cada nodo del Set de réplicas. El members arreglo es un arreglo de índice cero.

Cada documento de configuración específico del nodo puede contener los siguientes campos:

members[n]._id

Tipo: entero

Un identificador entero para el nodo en el Set de réplicas, único entre todos los nodos.

A partir de MongoDB 5.0, los valores pueden ser cualquier número entero mayor o igual a 0. Anteriormente, este valor estaba limitado a un número entero entre 0 y 255, inclusive.

Cada miembro del conjunto de réplicas debe tener un _id único. Evitar reutilizar los valores _id incluso si ninguna entrada members[n] está utilizando ese _id en la configuración actual.

Una vez establecido, no se puede cambiar el _id de un nodo.

Nota

Al actualizar el objeto de configuración de la réplica, acceda a los miembros del set de réplicas en el members arreglo con el índice del arreglo. El índice del arreglo comienza con 0. No confundir este valor de índice con el valor del campo members[n]._id en cada documento del arreglo members.

members[n].host

Tipo: string

El nombre de host y, si se especifica, el número de puerto, del nodo del conjunto.

El nombre del host debe ser resoluble para cada host en el set de réplicas.

Advertencia

members[n].host no puede contener un valor que se resuelva a localhost o a la interfaz local a menos que todos los miembros del conjunto estén en hosts que se resuelvan a localhost.

members[n].arbiterOnly

Opcional.

Tipo: booleano

Por defecto: false

Un valor booleano que identifica a un árbitro. Un valor de true indica que el Nodo es un árbitro.

Al utilizar el método rs.addArb() para añadir un árbitro, el método establece automáticamente members[n].arbiterOnly a true para el nodo añadido.

members[n].buildIndexes

Opcional.

Tipo: booleano

Por defecto: true

Un valor booleano que indica si el mongod crea índices en este nodo. Solo se puede establecer este valor al añadir un nodo a un set de réplicas. No se puede cambiar el campo members[n].buildIndexes después de que el nodo haya sido añadido al conjunto. Para añadir un nodo, consultar rs.add() y rs.reconfig().

No configurar false para las instancias de mongod que reciben queries de clientes.

Configurar buildIndexes a false puede ser útil si todas las siguientes condiciones son verdaderas:

solo está utilizando esta instancia para realizar copias de seguridad usando mongodump, y
este miembro no recibirá consultas, y
La creación y el mantenimiento de índices sobrecargan el sistema host.

Incluso si se establece en false, las secundarias crearán índices en el campo _id para facilitar las operaciones necesarias para la replicación.

Advertencia

Si se configura members[n].buildIndexes a false, también se debe configurar members[n].priority a 0. Si members[n].priority no es 0, MongoDB devolverá un error al intentar añadir un nodo con members[n].buildIndexes igual a false.

Para asegurarse de que el nodo no reciba queries, debe ocultar todas las instancias que no creen índices.

Otros secundarios no pueden replicarse desde un nodo donde members[n].buildIndexes es falso.

members[n].hidden

Opcional.

Tipo: booleano

Por defecto: false

Cuando este valor es true, el set de réplicas oculta esta instancia y no incluye al nodo en la salida de db.hello() o hello. Esto impide las operaciones de lectura (es decir, queries) para que nunca lleguen a este host mediante una preferencia de lectura secundaria.

Los miembros ocultos pueden reconocer operaciones de escritura emitidas con nivel de confirmación de escritura. Para las operaciones de escritura emitidas con "majority" nivel de confirmación de escritura, el nodo también debe ser un nodo con derecho a voto (es decir, votes es mayor que 0.

Tip

Miembros ocultos del set de réplicas

members[n].priority

Opcional.

Tipo: número entre 0 y 1000 para primario/secundario; 0 o 1 para árbitros.

Por defecto: 1.0 para primario/secundario; 0 para árbitros.

Un número que indica la probabilidad relativa de que un miembro de un set de réplicas se convierta en el primario.

Para aumentar la probabilidad de que un nodo se convierta en el primario, especificar un valor priority más alto para ese nodo.
Para disminuir la probabilidad de que un Nodo se convierta en el primario, especifica un valor de priority menor para ese Nodo.

Cambiar la prioridad de un nodo activa una o más elecciones. El algoritmo de elección hace un esfuerzo máximo para elegir al nodo de mayor prioridad como primario. Sin embargo, un nodo de menor prioridad puede convertirse en el primario incluso si hay disponible un secundario de mayor Prioridad.

Si un nodo de menor prioridad se convierte en el primario, el servidor continúa convocando elecciones periódicamente hasta que el nodo del set de réplicas de mayor prioridad sea el primario. La frecuencia con la que ocurren las elecciones depende de la diferencia de prioridad entre el nodo elegido y el nodo con la prioridad más alta.

Un nodo con una prioridad de 0 no puede convertirse en el primario.

Los miembros no votantes (es decir, los miembros que tienen votes configurado en 0) deben tener una prioridad de 0.

Tip

members[n].tags

Opcional.

Tipo: documento

Por defecto: ninguno

Un documento tags contiene pares de campo de etiqueta y valor definidos por el usuario para el set de réplicas.

{ "<tag1>": "<string1>", "<tag2>": "<string2>",... }

Para las operaciones de lectura, se puede especificar un conjunto de etiquetas en la preferencia de lectura para dirigir las operaciones a los miembros del set de réplicas con las etiquetas especificadas.
Para las operaciones de escritura, se puede crear un nivel de confirmación de escritura personalizado utilizando settings.getLastErrorModes y settings.getLastErrorDefaults.

Para obtener más información, consultar Configurar conjuntos de etiquetas del set de réplicas.

members[n].secondaryDelaySecs

Opcional.

Tipo: entero

Por defecto: 0

El número de segundos "de retraso" respecto al primario que este nodo del set de réplicas debe tener.

Utilizar esta opción para crear miembros atrasados. Los miembros atrasados mantienen una copia de los datos que refleja el estado de los datos en algún momento del pasado.

Los miembros atrasados pueden contribuir al reconocimiento de operaciones de escritura emitidas con nivel de confirmación de escritura. Sin embargo, devuelven el reconocimiento de guardado no antes del valor de retraso configurado. Para las operaciones de escritura emitidas con "majority" nivel de confirmación de escritura, el nodo también debe ser un nodo con derecho a voto (es decir, votes es mayor que 0).

Tip

Miembros del Set de réplicas retrasadas

members[n].votes

Opcional.

Tipo: entero

Por defecto: 1

El número de votos que un servidor emitirá en una elección de set de réplicas. El número de votos que tienen cada nodo es 1 o 0, y árbitros siempre tienen exactamente 1 voto.

Los miembros con priority mayor que 0 no pueden tener 0 votes.

Un Set de réplicas puede tener hasta50 miembros, pero solo 7 miembros con derecho a voto. Si necesita más de 7 miembros en un Set de réplicas, configure members[n].votes a 0 para los miembros adicionales sin derecho a voto.

No votantes (es decir, votes es 0) los miembros deben tener priority sobre 0.

A partir de MongoDB 5.0, un secundario recién agregado no cuenta como nodo votante y no puede ser elegido hasta que alcance el estado SECONDARY.

Los miembros no votantes no pueden reconocer las operaciones de escritura emitidas con un nivel de confirmación de escritura "majority".

Tip

`settings`

settings

Opcional.

Tipo: documento

Un documento que contiene opciones de configuración que se aplican a todo el set de réplicas.

El settings documento contiene los siguientes campos:

settings.chainingAllowed

Opcional.

Tipo: booleano

Por defecto: true

En MongoDB 5.0.1 y versiones anteriores, si settings.chainingAllowed es:

true, los miembros secundarios del set de réplicas pueden replicar datos de otros miembros secundarios.
false, los miembros secundarios solo pueden replicar datos desde el nodo primario.

A partir de MongoDB 5.0.2:

Con una anulación habilitada, los miembros secundarios del Set de réplicas pueden replicar datos de otros miembros secundarios incluso si settings.chainingAllowed está false.
Para anular settings.chainingAllowed y permitir la replicación desde un miembro secundario, establezca el parámetro de servidor enableOverrideClusterChainingSetting a true.
El valor por defecto para enableOverrideClusterChainingSetting es false.

Tip

Replicación en cadena autogestionada

settings.getLastErrorDefaults

Opcional.

Tipo: documento

No disponible a partir de MongoDB 5.0.

Importante

A partir de MongoDB 5.0, no se podrá especificar un nivel de confirmación de escritura por defecto con settings.getLastErrorDefaults que no sea el por defecto de { w: 1, wtimeout: 0 } . En su lugar, se utiliza el comando setDefaultRWConcern para establecer la configuración por defecto de nivel de confirmación de escritura para un set de réplicas o un clúster particionado.

settings.getLastErrorModes

Opcional.

Tipo: documento

Un documento utilizado para definir un nivel de confirmación de escritura personalizado mediante el uso de members[n].tags. El nivel de confirmación de escritura personalizado puede proporcionar conciencia del centro de datos.

{ getLastErrorModes: {
   <name of write concern> : { <tag1>: <number>, .... },
   ...
} }

El <number> se refiere al número de valores de etiquetas diferentes necesarios para cumplir con el nivel de confirmación de escritura. Por ejemplo, el siguiente settings.getLastErrorModes define un nivel de confirmación de escritura llamado datacenter que requiere que la escritura se propague a dos miembros cuyos valores de etiqueta dc sean diferentes.

{ getLastErrorModes: { datacenter: { "dc": 2 } } }

Para utilizar el nivel de confirmación de escritura personalizado, pase el nombre del nivel de confirmación de escritura a la w opción, por ejemplo.

{ w: "datacenter" }

Consultar Configurar conjuntos de etiquetas de sets de réplicas para obtener más información y un ejemplo.

settings.heartbeatTimeoutSecs

Opcional.

Tipo: int

Por defecto: 10

Número de segundos que los miembros del set de réplicas esperan para recibir un latido exitoso entre sí. Si un nodo no responde a tiempo, otros nodos marcan al nodo moroso como inaccesible.

settings.electionTimeoutMillis

Opcional.

Tipo: int

Por defecto: 10000 (10 segundos)

El límite de tiempo en milisegundos para detectar cuándo el primario de un set de réplicas es inalcanzable. Esta configuración controla la sensibilidad de la conmutación por error al utilizar protocolVersion: 1. Se puede esperar que el tiempo de espera de conmutación por error no supere el valor de electionTimeoutMillis.

Considere lo siguiente al seleccionar un valor:

Valores más altos resultan en conmutaciones por error más lentas, pero disminuyen la sensibilidad a la lentitud o irregularidad del nodo primario o de la red.
Valores más bajos resultan en una conmutación por error más rápida, pero aumentan la sensibilidad a la lentitud o irregularidad del nodo primario o de la red.

La configuración solo se aplica al usar protocolVersion: 1.

Nota

Cuando se desciende un primario usando rs.stepDown() o replSetStepDown sin establecer el campo force a true, el primario descendido nomina a un secundario elegible para llamar a una elección inmediatamente.

settings.catchUpTimeoutMillis

Opcional.

Tipo: int

Por defecto: -1, tiempo de sincronización infinito.

Límite de tiempo en milisegundos para que un primario recién elegido se sincronice (se ponga al día) con los otros miembros del Set de réplicas que puedan tener guardados más recientes. Los límites de tiempo infinitos o altos pueden reducir la cantidad de datos que los demás miembros necesitarían revertir tras una elección, pero pueden aumentar el tiempo de conmutación por error.

El nuevo primario elegido termina el período de sincronización antes de tiempo una vez que se ha sincronizado completamente con los demás miembros del conjunto. Durante el periodo de sincronización, el nodo primario recién elegido no está disponible para que los clientes guarden. Utilizar replSetAbortPrimaryCatchUp para abortar la sincronización y luego completar la transición a primaria.

La configuración solo se aplica al usar protocolVersion: 1.

settings.catchUpTakeoverDelayMillis

Opcional.

Tipo: int

Por defecto: 30000 (30 segundos)

Tiempo en milisegundos que un nodo espera para iniciar una toma de control de recuperación después de determinar que está por delante del primario actual. Durante una toma de control de recuperación, el nodo que está por delante de la primaria actual inicia una elección para convertirse en la nueva primaria del set de réplicas.

Después de que el nodo que inicia la toma de control determina que está por delante del primario actual, espera el número especificado de milisegundos y luego verifica lo siguiente:

Todavía está por delante del primario actual,
Es el nodo más actualizado entre todos los nodos disponibles,
El primario actual está alcanzándolo.

Una vez que se determina que se cumplen todas estas condiciones, el nodo que inicia la toma de control se ejecuta inmediatamente para la elección.

Para obtener más información sobre las elecciones de set de réplicas, consulta elecciones de set de réplicas.

Nota

Configurar catchUpTakeoverDelayMillis en -1 desactiva la toma de control de recuperación. Establecer catchUpTimeoutMillis a 0 desactiva la sincronización primaria y, en consecuencia, también la toma de control de la sincronización.

settings.heartbeatIntervalMillis

Solo para uso interno.

La frecuencia en milisegundos de los latidos cardíacos.

settings.replicaSetId

Tipo: ObjectId

El ObjectId asociado con el Set de réplicas y creado automáticamente durante rs.initiate() o replSetInitiate. No puedes cambiar el replicaSetId.

Volver

Referencia

Versión del protocolo