Configuración de Set de réplicas autogestionado

Se puede acceder a la configuración de un Set de réplicas utilizando el método rs.conf() o el comando replSetGetConfig.

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.

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

replSetName o --replSet para obtener información sobre cómo establecer el nombre del set de réplicas.

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 conjunto de réplicas utilizan term y version para lograr un consenso sobre la configuración de réplica "más reciente". Al comparar los documentos de configuración de réplicas, el documento con un mayor term se considera el "más reciente". Si term es igual o no está presente, el documento con el mayor se version considera el "más reciente".

term

Tipo: int

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

Número incremental utilizado para distinguir las revisiones del documento de configuración del conjunto de réplicas de las iteraciones anteriores de la configuración. El term de un documento de configuración coincide con el período del nodo primario del conjunto de réplicas que realizó la reconfiguración. El nodo primario incrementa su período cada vez que asciende tras ganar una elección. El nodo primario ignora el term campo si se establece explícitamente en la replSetReconfig operación.

Al emitir una reconfiguración forzada, se elimina el term campo. Cuando el siguiente proceso principal emite replSetReconfig sin forzar, 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 miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria, debe `writeConcernMajorityJournalDefault` establecer `false` en. Si algún miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria y`writeConcernMajorityJournalDefault`es `true`, `"majority"`las operaciones de escritura pueden fallar. Estas incluyen operaciones que inherentemente utilizan`"majority"`la preocupación de escritura, como el comando`replSetStepDown`, o varios métodos`mongosh`que por defecto utilizan`"majority"`la preocupación de escritura, como los métodos de administración de usuarios y los métodos de administración de roles. A partir de la versión 4.2 (y 4.0.13 3.6.14y), si un miembro del conjunto de réplicas utiliza el motor de almacenamiento en memoria (con o sin votación) pero el conjunto de réplicas tiene `writeConcernMajorityJournalDefault` establecido en verdadero, el miembro del conjunto 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 miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria, debe `writeConcernMajorityJournalDefault` establecer `false` en. A partir de la versión 4.2 (y 4.0.13 3.6.14y), si un miembro del conjunto de réplicas utiliza el motor de almacenamiento en memoria (con o sin votación) pero el conjunto de réplicas tiene `writeConcernMajorityJournalDefault` establecido en verdadero, el miembro del conjunto de réplicas registra una advertencia de inicio. No se pueden ejecutar transacciones en un clúster fragmentado que tenga un fragmento con establecido `writeConcernMajorityJournalDefault` en `false` (como un fragmento con un miembro 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 miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria, debe writeConcernMajorityJournalDefault establecer false en.

Si algún miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria ywriteConcernMajorityJournalDefaultes true, "majority"las operaciones de escritura pueden fallar. Estas incluyen operaciones que inherentemente utilizan"majority"la preocupación de escritura, como el comandoreplSetStepDown, o varios métodosmongoshque por defecto utilizan"majority"la preocupación de escritura, como los métodos de administración de usuarios y los métodos de administración de roles.

A partir de la versión 4.2 (y 4.0.13 3.6.14y), si un miembro del conjunto de réplicas utiliza el motor de almacenamiento en memoria (con o sin votación) pero el conjunto de réplicas tiene writeConcernMajorityJournalDefault establecido en verdadero, el miembro del conjunto 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 miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria, debe writeConcernMajorityJournalDefault establecer false en.

No se pueden ejecutar transacciones en un clúster fragmentado que tenga un fragmento con establecido writeConcernMajorityJournalDefault en false (como un fragmento con un miembro votante que utiliza el motor de almacenamiento en memoria).

Tip

`members`

members

Tipo: arreglo

Un conjunto de documentos de configuración de miembros, uno para cada miembro del conjunto de réplicas. El conjunto es un conjunto indexado desde members 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 _id de _id réplicas debe tener un único. Evite reutilizar valores incluso si ninguna members[n] entrada está utilizando ese _id en la configuración actual.

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

Nota

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

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 en localhost o en la interfaz local a menos que todos los miembros del conjunto estén en hosts que se resuelvan localhost en.

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étodors.addArb()para agregar un árbitro, el método establece automáticamentemembers[n].arbiterOnlya true para el miembro agregado.

members[n].buildIndexes

Opcional.

Tipo: booleano

Por defecto: true

Un valor booleano que indica si crea mongod índices en este miembro. Solo se puede establecer este valor al agregar un miembro a un conjunto de réplicas. No se puede modificar el campo después de que el miembro se haya agregado al conjunto. Para agregar un miembro,members[n].buildIndexes consulte rs.add() rs.reconfig()y.

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:

Usted solo está utilizando esta instancia para realizar copias de seguridad mongodump utilizando, 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 members[n].buildIndexes establece false en, también debe members[n].priority establecer 0 en. Si members[n].priority no 0 es, MongoDB devolverá un error al intentar agregar un miembro con members[n].buildIndexes igual false a.

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

Otros miembros secundarios no pueden replicarse desde un miembro donde es members[n].buildIndexes 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 evita que las operaciones de lectura (es decir, query) lleguen a este host mediante una preferencia de lectura secundaria.

Los miembros ocultos pueden confirmar las operaciones de escritura emitidas con Write Concern. Para las operaciones de escritura emitidas "majority" con write concern, el miembro también debe ser un miembro con derecho a voto (es decir, esvotes mayor 0 que).

Tip

Miembros ocultos del set de réplicas

members[n].priority

Opcional.

Tipo: número entre 0 y 1000 para nodos primarios/secundarios, o 0 o 1 para árbitros.

Por defecto: 1.0 para los nodos primario/secundario, o 0 para los á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 sin derecho a voto (es decir, los miembros que tienen votes establecido 0 en) deben tener una prioridad 0 de.

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 operaciones de escritura, puede crear una preocupación de escritura personalizada utilizando settings.getLastErrorModes settings.getLastErrorDefaultsy.

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 con retardo pueden contribuir a confirmar las operaciones de escritura emitidas con Write Concern. Sin embargo, no devuelven la confirmación de escritura antes del valor de retardo configurado. Para las operaciones de escritura emitidas "majority" con write concern, el miembro también debe ser un miembro con derecho a voto (es decir, esvotes mayor 0 que).

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 mayor priority que 0 no pueden 0 votes tener.

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

Los miembros sin derecho a voto (esvotes decir,0 es) deben tener priority 0de.

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 documento contiene los siguientes settings 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 conjunto de réplicas pueden replicar datos de otros miembros secundarios incluso settings.chainingAllowed si false es.
Para anular y permitir la replicación desde settings.chainingAllowed enableOverrideClusterChainingSetting un miembro secundario,true establezca el parámetro del servidor en.
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 puede especificar una preocupación de escritura predeterminada con que no sea la settings.getLastErrorDefaults predeterminada { w: 1, wtimeout: 0 } de. En su lugar, utilice el comando para establecer la configuración setDefaultRWConcern de preocupación de lectura o escritura predeterminada para un conjunto de réplicas o un clúster fragmentado.

settings.getLastErrorModes

Opcional.

Tipo: documento

Un documento utilizado para definir una preocupación de escritura personalizada mediante el uso de. La preocupación de escritura personalizada puede members[n].tags proporcionar conocimiento del centro de datos.

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

El <number> se refiere al número de valores de etiqueta diferentes necesarios para satisfacer la condición de escritura. Por ejemplo, el siguiente define una condición de escritura settings.getLastErrorModes denominada datacenter que requiere que la escritura se propague a dos miembros cuyos dc valores de etiqueta sean diferentes.

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

Para usar el nivel de confirmación de escritura (write concern) personalizado, pase el nombre del nivel de confirmación de escritura (write concern) 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)

Límite de tiempo en milisegundos para detectar cuándo el nodo principal de un conjunto de réplicas no está disponible. Esta configuración controla la sensibilidad de la conmutación por error al protocolVersion: 1 usar. Se espera que el tiempo de espera de la conmutación por error no supere el valor electionTimeoutMillis de.

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.

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

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.

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

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

Establecer catchUpTakeoverDelayMillis a -1 desactiva la toma de control de recuperación. Establecer catchUpTimeoutMillis a 0 desactiva la recuperación primaria y, por consiguiente, también la toma de control de recuperació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 conjunto de réplicas y creado automáticamente durante o. No puede rs.initiate() replSetInitiatecambiar replicaSetId el.

Volver

Mitigar problemas de rendimiento en el set de réplicas de PSA

Versión del protocolo de set de réplicas