Overview
Este tutorial describe el proceso para implementar un Conjunto de réplicas con miembros en varias ubicaciones. El tutorial aborda conjuntos de réplicas de tres y cinco miembros. Si tiene un número par de miembros en el conjunto de réplicas, agregue otro miembro con datos, si es posible, para implementar un número impar de miembros con derechoa voto.1 []
Para obtener más información sobre conjuntos de réplicas distribuidas, consulte Conjuntos de réplicas distribuidos en dos o más centros de datos. Consulte también Arquitecturas de implementación de conjuntos de réplicas y la Referencia de replicación autoadministrada.
| [1] | (1, 2) Si las circunstancias prohíben otro nodo portador de datos y tienes un número par de nodos votantes, puedes agregar un árbitro. Para consideraciones al usar un árbitro, consulta Árbitro de set de réplicas. |
Considerations
Arquitectura
En producción, implemente cada miembro del conjunto de réplicas en su propia máquina. Si es posible, asegúrese de que MongoDB escuche en el puerto predeterminado de
27017.
Nota
Fuera de una actualización con sustitución gradual, todos los mongod miembros de un set de réplicas deben usar la misma versión principal de MongoDB.
Para obtener más información, consulta Arquitecturas de implementación de sets de réplicas.
Nombres de host
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Asociación de IP
Utiliza la opción --bind_ip para asegurarte de que MongoDB escuche las conexiones de las aplicaciones en las direcciones configuradas.
Advertencia
Antes de vincular una dirección IP que no sea local (por ejemplo, de acceso público), asegúrese de proteger su clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulte la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considere habilitar la autenticación y reforzar la infraestructura de red.
Los binarios de MongoDB, mongod y mongos, se enlazan a localhost por defecto. Si se establece el ajuste del archivo de configuración net.ipv6 o la opción de línea de comandos --ipv6 para el binario, el binario se vincula además a la dirección IPv6 de localhost.
Por defecto, mongod y mongos que están vinculados a localhost solo aceptan conexiones de clientes que se ejecutan en el mismo ordenador. Este comportamiento de vinculación incluye mongosh y otros nodos del set de réplicas o clúster. Los clientes remotos no pueden conectarse a binarios que están vinculados únicamente a localhost.
Para anular la vinculación por defecto y enlazar a otras direcciones IP, utiliza la configuración del archivo de configuración net.bindIp o la opción de línea de comandos --bind_ip para especificar una lista de nombres de host o direcciones IP.
Advertencia
Por ejemplo, la siguiente instancia de mongod se vincula tanto al localhost como al nombre de host My-Example-Associated-Hostname, que está asociado con la dirección IP 198.51.100.1:
mongod --bind_ip localhost,My-Example-Associated-Hostname
Para conectarse a esta instancia, los clientes remotos deben especificar el nombre de host o su dirección IP asociada 198.51.100.1:
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
Conectividad
Asegúrate de que el tráfico de red pueda pasar de manera segura entre todos los nodos del set y todos los clientes de la red.
Considere lo siguiente:
Se debe establecer una red privada virtual. Es necesario garantizar que la topología de la red dirija todo el tráfico entre los nodos dentro de un solo sitio a través de la red de área local.
Configura el control de acceso para evitar conexiones desde clientes desconocidos al set de réplicas.
Se deben configurar las reglas de red y del firewall de manera que los paquetes entrantes y salientes solo se permitan en el puerto por defecto de MongoDB y únicamente desde la implementación. Se debe consultar las consideraciones sobre la vinculación de IP.
Se debe garantizar que se pueda acceder a cada nodo de un set de réplicas mediante DNS o nombres de host que se puedan resolver. Se deben configurar los nombres de DNS adecuadamente o establecer el archivo /etc/hosts del sistema para que refleje esta configuración.
Cada nodo debe poder conectarse con todos los demás nodos. Para obtener instrucciones sobre cómo verificar la conexión, se debe consultar Probar conexiones entre todos los nodos.
Configuración
Crea el directorio donde MongoDB almacena los archivos de datos antes de implementar MongoDB.
Especifica la configuraciónmongod en un archivo de configuración almacenado en /etc/mongod.conf o en una ubicación relacionada.
Para obtener más información sobre las opciones de configuración, se debe consultar Opciones de archivo de configuración autogestionado.
Distribución de los Miembros
Si es posible, utiliza un número impar de centros de datos y elige una distribución de nodos que maximice la probabilidad de que, incluso con la pérdida de un centro de datos, los nodos restantes del set de réplicas puedan formar una mayoría o, como mínimo, proporcionen una copia de tus datos.
Miembros con derecho a voto
Nunca despliegue más de siete miembros con derecho a voto.
Requisitos previos
Para todas las configuraciones de este tutorial, implemente cada miembro del conjunto de réplicas en un sistema independiente. Aunque puede implementar más de un miembro del conjunto de réplicas en un solo sistema, esto reduce la redundancia y la capacidad del conjunto. Estas implementaciones suelen utilizarse para realizar pruebas.
Este tutorial asume que ha instalado MongoDB en cada sistema que formará parte de su conjunto de réplicas. Si aún no lo ha hecho, consulte los tutoriales de instalación.
Procedimientos
Implementar un set de réplicas de tres nodos geográficamente redundantes
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Para una implementación geográficamente redundante de un set de réplicas de tres nodos, debe decidir cómo distribuir su sistema. Algunas distribuciones posibles para los tres miembros son:
En tres centros de datos: un miembro por cada sitio.
En dos centros de datos: dos miembros en el sitio A y un miembro en el sitio B. Si uno de los miembros del conjunto de réplicas es un árbitro [],1 distribuya el árbitro al sitio A con un miembro que contenga datos.
Nota
Para las implementaciones de producción, recomendamos desplegar el servidor de configuración y los Sets de réplicas de fragmentos en al menos tres centros de datos. Esta configuración proporciona alta disponibilidad en caso de que un solo centro de datos falle.
Inicia cada nodo del set de réplicas con las opciones adecuadas.
Para cada nodo, inicia una instancia mongod con los siguientes ajustes:
Se debe establecer la opción
replication.replSetNameen el nombre del set de réplicas. Si la aplicación se conecta a más de un set de réplicas, cada set debe tener un nombre distinto.Configura la opción
net.bindIpal nombre de host/IP o a una lista separada por comas de nombres de host/IPs.Configure cualquier otra configuración según sea apropiado para su implementación.
En este tutorial, las tres instancias mongod están asociadas con los siguientes hosts:
Set de réplicas | Nombre del host |
|---|---|
Miembro 0 |
|
Miembro 1 |
|
Miembro 2 |
|
El siguiente ejemplo especifica el nombre del set de réplicas y la vinculación de ip mediante las opciones de línea de comandos --replSet y --bind_ip:
Advertencia
Antes de vincular una dirección IP que no sea local (por ejemplo, de acceso público), asegúrese de proteger su clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulte la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considere habilitar la autenticación y reforzar la infraestructura de red.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
Para <hostname(s)|ip address(es)>, se deben especificar los nombres de host y/o las direcciones IP para la instancia de mongod que los clientes remotos (incluidos los demás miembros del set de réplicas) pueden utilizar para conectarse a la instancia.
Alternativamente, también puedes especificar el replica set name y el ip addresses en un archivo de configuración:
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
Para iniciar mongod con un archivo de configuración, especifica la ruta del archivo de configuración con la opción --config:
mongod --config <path-to-config>
En las implementaciones de producción, puedes configurar un script de inicio para administrar este proceso. Los scripts de inicio están fuera del alcance de este documento.
Conéctate con mongosh a una de las instancias mongod.
Desde la misma máquina en la que se ejecuta uno de los mongod (en este tutorial, mongodb0.example.net), inicia mongosh. Para conectarte al mongod que escucha en localhost por el puerto predeterminado 27017, simplemente ejecuta:
mongosh
Dependiendo de la ruta, es posible que debas especificar la ruta al binario mongosh.
Si tu mongod no se está ejecutando en el puerto por defecto, especifica la opción --port para mongosh.
Inicia el set de réplicas.
Desde mongosh, ejecuta rs.initiate() en el miembro del set de réplicas 0.
Importante
Ejecute rs.initiate() en una sola instancia para el conjunto de mongod réplicas.
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" } ] })
MongoDB inicia un set de réplicas, utilizando la configuración del set de réplicas por defecto.
Consulta la configuración del set de réplicas.
Utiliza rs.conf() para mostrar el Objeto de configuración del set de réplicas:
rs.conf()
El objeto de configuración del set de réplicas se asemeja al siguiente:
{ "_id" : "rs0", "version" : 1, "protocolVersion" : Long(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("585ab9df685f726db2c6a840") } }
Opcional. Configure la elegibilidad del miembro para convertirse en principal.
En algunos casos, puede preferir que los miembros de un centro de datos sean elegidos como principales antes que los de los demás. Puede modificar el priority de los miembros para que los de un centro de datos tengan un mayor priority que los de los demás.
Algunos miembros del conjunto de réplicas, como aquellos con restricciones de red o recursos limitados, no deberían poder convertirse en principales en una conmutación por error. Configure los miembros que no deberían convertirse en principales para que tengan 0prioridad.
Por ejemplo, para reducir la elegibilidad relativa del miembro ubicado en uno de los sitios (en este ejemplo, mongodb2.example.net), establezca la prioridad del miembro en 0.5.
Vea la configuración del conjunto de réplicas para determinar la
membersposición de la matriz para el miembro.Nota
La posición de la matriz no es la misma que
_id.rs.conf() Copie el objeto de configuración del conjunto de réplicas a una variable (a
cfgen el ejemplo siguiente). Luego, en la variable, establezca la prioridad correcta para el miembro. Pase la variable a para actualizar la configuración del conjunto ders.reconfig()réplicas.Por ejemplo, para establecer la prioridad del tercer miembro de la matriz (es decir, el miembro en la posición 2), emita la siguiente secuencia de comandos:
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) Nota
El
rs.reconfig()método de shell puede forzar la retirada del servidor principal actual, lo que provoca una elección. Cuando el servidor principal se retira, todos los clientes se desconectan. Este es el comportamiento previsto. Si bien el tiempo medio para elegir un nuevo servidor principal no suele superar los 12 segundos, asegúrese de que cualquier cambio en la configuración de la réplica se realice durante los periodos de mantenimiento programados.
Una vez que estos comandos regresen, tendrás un conjunto de réplicas de tres miembros geográficamente redundante.
Asegúrate de que el set de réplicas tenga un primario.
Utiliza rs.status() para identificar el primario en el set de réplicas.
Implementar un conjunto de réplicas de cinco miembros geográficamente redundantes
Importante
Para evitar actualizaciones de configuración debido a cambios en las direcciones IP, utilice nombres de host DNS en lugar de direcciones IP. Es particularmente importante usar un nombre de host DNS en lugar de una dirección IP al configurar miembros de set de réplicas o miembros de clústeres particionados.
Utiliza nombres de host en lugar de direcciones IP para configurar clústeres en un horizonte de red dividido. A partir de MongoDB 5.0, los nodos que solo están configurados con una dirección IP no pasan la validación de inicio y no se inician.
Para implementar un conjunto de réplicas de cinco miembros con redundancia geográfica, debe decidir cómo distribuir su sistema. Algunas distribuciones posibles para los cinco miembros son:
En tres centros de datos: dos miembros en el sitio A, dos miembros en el sitio B, un miembro en el sitio C.
En cuatro centros de datos: dos miembros en un sitio y un miembro en los otros tres sitios.
En cinco centros de datos: un miembro en cada sitio.
En dos centros de datos: tres miembros en el sitio A y dos miembros en el sitio B. Si es posible, evite distribuir el conjunto de réplicas del servidor de configuración en solo dos centros de datos.
Nota
Para las implementaciones de producción, recomendamos desplegar el servidor de configuración y los Sets de réplicas de fragmentos en al menos tres centros de datos. Esta configuración proporciona alta disponibilidad en caso de que un solo centro de datos falle.
Inicia cada nodo del set de réplicas con las opciones adecuadas.
Para cada nodo, inicia una instancia mongod con los siguientes ajustes:
Configura la opción
replication.replSetNamecon el nombre del set de réplicas,Si la aplicación se conecta a más de un set de réplicas, cada set debe tener un nombre distinto. Algunos drivers agrupan las conexiones del set de réplicas por nombre del set de réplicas.
Establezca la opción en el nombre de host/dirección IP o en una lista delimitada por comas de nombres de host/direcciones IP
net.bindIpyConfigure cualquier otra configuración según sea apropiado para su implementación.
En este tutorial, las cinco instancias están asociadas con los siguientes mongod hosts:
Set de réplicas | Nombre del host |
|---|---|
Miembro 0 |
|
Miembro 1 |
|
Miembro 2 |
|
Miembro 3 |
|
Miembro 4 |
|
El siguiente ejemplo especifica el nombre del set de réplicas y la vinculación de ip mediante las opciones de línea de comandos --replSet y --bind_ip:
Advertencia
Antes de vincular una dirección IP que no sea local (por ejemplo, de acceso público), asegúrese de proteger su clúster contra accesos no autorizados. Para obtener una lista completa de recomendaciones de seguridad, consulte la Lista de verificación de seguridad para implementaciones autogestionadas. Como mínimo, considere habilitar la autenticación y reforzar la infraestructura de red.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
Para <hostname(s)|ip address(es)>, se deben especificar los nombres de host y/o las direcciones IP para la instancia de mongod que los clientes remotos (incluidos los demás miembros del set de réplicas) pueden utilizar para conectarse a la instancia.
Alternativamente, también puedes especificar el replica set name y el hostnames/ip
addresses en un archivo de configuración:
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
Para iniciar mongod con un archivo de configuración, especifica la ruta del archivo de configuración con la opción --config:
mongod --config <path-to-config>
En las implementaciones de producción, puedes configurar un script de inicio para administrar este proceso. Los scripts de inicio están fuera del alcance de este documento.
Conéctate con mongosh a una de las instancias mongod.
Desde la misma máquina en la que se ejecuta uno de los mongod (en este tutorial, mongodb0.example.net), inicia mongosh. Para conectarte al mongod que escucha en localhost por el puerto predeterminado 27017, simplemente ejecuta:
mongosh
Dependiendo de la ruta, es posible que debas especificar la ruta al binario mongosh.
Si tu mongod no se está ejecutando en el puerto por defecto, especifica la opción --port para mongosh.
Inicia el set de réplicas.
Desde mongosh, ejecuta rs.initiate() en el miembro del set de réplicas 0.
Importante
Ejecute rs.initiate() en una sola instancia para el conjunto de mongod réplicas.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" }, { _id: 3, host: "mongodb3.example.net:27017" }, { _id: 4, host: "mongodb4.example.net:27017" } ] })
Consulta la configuración del set de réplicas.
Utiliza rs.conf() para mostrar el Objeto de configuración del set de réplicas:
rs.conf()
El objeto de configuración del set de réplicas se asemeja al siguiente:
{ "_id" : "rs0", "version" : 1, "protocolVersion" : Long(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 3, "host" : "mongodb3.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 4, "host" : "mongodb4.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : Long(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("5df2c9ccc21c478b838b98d6") } }
Opcional. Configure la elegibilidad del miembro para convertirse en principal.
En algunos casos, puede preferir que los miembros de un centro de datos sean elegidos como principales antes que los de los demás. Puede modificar el priority de los miembros para que los de un centro de datos tengan un mayor priority que los de los demás.
Algunos miembros del conjunto de réplicas, como aquellos con restricciones de red o recursos limitados, no deberían poder convertirse en principales en una conmutación por error. Configure los miembros que no deberían convertirse en principales para que tengan 0prioridad.
Por ejemplo, para reducir la elegibilidad relativa del miembro ubicado en uno de los sitios (en este ejemplo, mongodb2.example.net), establezca la prioridad del miembro en 0.5.
Vea la configuración del conjunto de réplicas para determinar la
membersposición de la matriz para el miembro.Nota
La posición de la matriz no es la misma que
_id.rs.conf() Copie el objeto de configuración del conjunto de réplicas a una variable (a
cfgen el ejemplo siguiente). Luego, en la variable, establezca la prioridad correcta para el miembro. Pase la variable a para actualizar la configuración del conjunto ders.reconfig()réplicas.Por ejemplo, para establecer la prioridad del tercer miembro de la matriz (es decir, el miembro en la posición 2), emita la siguiente secuencia de comandos:
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) Nota
El
rs.reconfig()método de shell puede forzar la retirada del servidor principal actual, lo que provoca una elección. Cuando el servidor principal se retira, todos los clientes se desconectan. Este es el comportamiento previsto. Si bien el tiempo medio para elegir un nuevo servidor principal no suele superar los 12 segundos, asegúrese de que cualquier cambio en la configuración de la réplica se realice durante los periodos de mantenimiento programados.
Después de que estos comandos regresen, tendrás un conjunto de réplicas de cinco miembros geográficamente redundante.
Asegúrate de que el set de réplicas tenga un primario.
Utiliza rs.status() para identificar el primario en el set de réplicas.