Una guía para desarrolladores de conjuntos de réplicas de MongoDB

MongoDB a menudo implica trabajar con un gran conjunto de datos, incluidas matrices incrustadas y objetos de matriz. Por lo tanto, siempre es importante asegurarse de que la tasa de procesamiento de su base de datos sea lo más rápida posible para mejorar las operaciones de lectura y escritura. Además, para evitar anomalías en los datos que puedan surgir debido a la inconsistencia de los datos, debe asegurarse de que sus datos tengan una mayor disponibilidad en caso de que desee recuperarse de un evento de falla del hardware o de algunas interrupciones del servicio. MongoDB proporciona algunos conceptos de 2 para ese propósito:ReplicaSets y Sharding.

Replicación en MongoDB

Replicación maestro-esclavo

Esta es una de las técnicas más antiguas utilizadas para garantizar que los datos estén siempre disponibles para los usuarios, incluso cuando falla un sistema. Sin embargo, la replicación maestro-esclavo está obsoleta en las últimas versiones de MongoDB a partir de la 3.2 y, por lo tanto, se reemplazó con conjuntos de réplicas.

Para hacer esta configuración, uno inicia 2 instancias de mongod considerando que una está en modo maestro y la otra en modo esclavo.

Para iniciar una instancia en modo maestro, ejecute:

mongod --master --port portNumber

Las opciones --master indican a mongod que cree una colección local.oplog.$main con la que se pone en cola una lista de operaciones para que los esclavos las apliquen en la replicación de los datos.

Para iniciar una instancia de mongod en modo esclavo, simplemente ejecute:

mongod --slave --source <masterhostname><:<port>>

Aquí debe especificar el nombre de host y el puerto de la instancia maestra en el argumento --source. Esta es una descripción general resumida del uso de la replicación de maestro esclavo y, dado que está en desuso, nuestro interés estará en los conjuntos de réplicas.

Conjuntos de réplicas

Este es un grupo de procesos MongoDB conocidos como instancias mongod que básicamente alojan el mismo conjunto de datos. Se caracteriza por un nodo primario y varios nodos secundarios para llevar datos. El nodo principal recibe todas las operaciones de escritura y registra todos los demás cambios en su conjunto de datos en su registro de operaciones. Los nodos secundarios, en el otro extremo, replican el registro de operaciones del principal y aplican las operaciones a su conjunto de datos de modo que sus conjuntos de datos reflejen el conjunto de datos del principal. En palabras simples, podemos decir que tenemos la máquina A como nodo principal y las máquinas B y C como nodos secundarios. La máquina A recibe una operación de escritura y realiza cambios en sus datos y luego hace una lista de los cambios que se han realizado. Las máquinas B y C luego copiarán las operaciones de la lista provista, en este caso el registro de operaciones, y las ejecutarán para que los datos resultantes sean los mismos que en la máquina A.

Como se mencionó anteriormente, siempre es importante garantizar una alta disponibilidad de datos, especialmente en el entorno de producción. La replicación viene a ayudar al proporcionar redundancia de datos en diferentes instancias de Mongod. En caso de pérdida de datos, dado que se almacenan copias de los mismos datos en diferentes bases de datos en múltiples ubicaciones, es fácil recuperarlos en la existente.

Con muchas instancias en ejecución, las operaciones de lectura y escritura de los clientes se envían a diferentes servidores y, por lo tanto, aumenta la tasa de procesamiento. La estructura básica del proceso de replicación se muestra a continuación.

A veces, el principal puede no estar disponible, por ejemplo, debido a una desconexión de Internet o una interrupción del servicio. En este caso, el conjunto de réplicas designará un nodo secundario para que sea el nodo principal. Si bien las solicitudes de lectura se realizan básicamente al principal, en algunas ocasiones las solicitudes de lectura se pueden enviar a los secundarios, pero tenga cuidado, ya que los datos devueltos pueden no reflejar lo que hay en el principal o, más bien, los datos pueden no estar actualizados.

Árbitros

En el caso de la elección de una primaria, necesitará una instancia de mongod adicional al conjunto de réplicas para agregar un voto en el proceso de elección. Esta instancia se conoce como árbitro y sus características más destacadas son:

No tiene una copia del conjunto de datos, por lo tanto, no requiere un hardware tan potente como los nodos que contienen datos.
No se puede promover para convertirse en el principal.
Siempre tienen 1 voto electoral para permitir que el conjunto de réplicas tenga un número impar de miembros con derecho a voto sin la sobrecarga de un miembro adicional que replique los datos. Su función crucial es, por lo tanto, seleccionar un nodo principal cuando no está disponible.
Permanece sin cambios.

A diferencia del árbitro, otros conjuntos de réplicas se pueden convertir en primarios desde secundarios y viceversa.

Replicación asíncrona

El proceso de replicación tiene lugar en dos formas de sincronización de datos. En primer lugar, los miembros del conjunto se rellenan con datos completos en la sincronización inicial. La replicación posterior tiene lugar para aplicar cambios avanzados a todo el conjunto de datos.

En la sincronización inicial, los datos se copian de un miembro del conjunto de réplicas a otro. Cuando se completa el proceso, el miembro pasa al nodo secundario.

Conmutación por error automática de MongoDB

Puede haber una interrupción del servicio como la desconexión de la red que tiene como consecuencia la terminación de la comunicación entre el primario y los secundarios. Si la desconexión dura más de 10 segundos o falla por completo, el conjunto de réplicas restante votará para que un miembro se convierta en el nuevo principal. El nodo secundario que obtiene la mayoría de los votos se convierte en el nuevo primario.

En la versión 3.0 de MongoDB, un conjunto de réplicas puede tener hasta 50 miembros con 7 miembros con derecho a voto.

Miembros del conjunto de réplicas de prioridad cero

Estos son miembros secundarios que no pueden transitar para ser nodos primarios ni pueden desencadenar una elección. Los roles cruciales en el conjunto de datos son:mantener copias del conjunto de datos, elegir un nodo principal y realizar operaciones de lectura. Actúan como una copia de seguridad donde un nuevo miembro puede no agregarse inmediatamente. Por lo tanto, almacenará los datos actualizados y puede reemplazar inmediatamente a un miembro no disponible.

Miembros del conjunto de réplicas ocultas de MongoDB

Estos son miembros sin conexión con las aplicaciones cliente. Se usan para cargas de trabajo con diferentes requisitos de uso de otros miembros secundarios. Solo reciben el tráfico de replicación básico que se encuentra durante la sincronización inicial.

Miembros del conjunto de réplicas retrasadas de MongoDB

Estos copian datos del archivo oplog del nodo principal dentro de una duración específica. Siempre reflejan el estado retrasado o una forma previa del conjunto. Por lo tanto, son importantes para detectar errores y dan una pista sobre cómo uno puede recuperarse de esos errores, por ejemplo, si hay una base de datos que se ha descartado. Al elegir la cantidad de retraso, esto debe tenerse en cuenta:

La duración debe ser inferior a la capacidad del registro de operaciones, que para los motores de almacenamiento WiredTiger, MMAPv1 e In-Memory es de 50 GB. De lo contrario, el miembro retrasado no podrá replicar operaciones con éxito.
La duración del retraso debe ser igual o ligeramente mayor que la duración esperada de la ventana de mantenimiento.

Configuración

Este es un miembro de prioridad cero, está oculto, por lo tanto, no es visible para las aplicaciones y, por último, puede participar en el proceso de elección. Por lo tanto, para configurar una prioridad, supongamos que tiene 10 miembros en su conjunto de réplicas, puede seleccionar un miembro en la posición n como miembro[n] y establecer sus propiedades como:

{
    “_id”: <num>, 
    “Host”: <hostname: port>,
    “Priority”: 0,
    “slaveDelay”: <seconds>,
    “Hidden”: true
}

O usando el mongo Shell conectado al principal, puede ejecutar estos comandos para configurar el primer miembro del conjunto de réplicas como retrasado:

cfg = rs.conf()
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)

Después de establecer esta configuración, el secundario retrasado no puede convertirse en principal y, por lo tanto, ocultarse de las aplicaciones. El miembro se retrasará 1 hora (3600 segundos) desde las operaciones de registro de operaciones.

Varios nueves Conviértase en un administrador de bases de datos de MongoDB - Llevando MongoDB a la producción Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar MongoDBDescargar gratis

Cómo iniciar un conjunto de réplicas

En esta guía, veremos paso a paso cómo podemos configurar un conjunto de réplicas en MongoDB.

Digamos que tiene 3 mongodb que desea replicar y están configurados de la siguiente manera:
1. Mongod1.conf ejecutándose en el puerto 27017
2. Mongod2.conf ejecutándose en el puerto 27018
3. Mongod3.conf ejecutándose en el puerto 27019
Asegúrese de agregar el nombre del conjunto de réplicas que no cambiará en cada archivo. Puede hacerlo agregando o cambiando el valor de la opción replSet a un nombre de su elección.
Podemos iniciar la primera instancia ejecutando
```
sudo mongod --config /etc/mongo/mongod1.conf
```
Esto es si no tiene una instancia de ejecución de mongod. Luego haz lo mismo para las otras instancias. Para verificar si hay instancias en ejecución en su máquina, ejecute
```
ps -ax | grep mongo
```
Obtendrá una lista como esta:
```
4328 ttys000    0:06.15 mongod
4950 ttys001    0:00.00 grep mongo
```
Esto significa que la primera instancia en MongoDB se ejecuta de forma predeterminada en el puerto 27017, por lo que la tenemos como la primera en la lista. Si inició los otros, también se destacarán en la lista con sus URL de ruta correspondientes. Para conectarse a una instancia en el shell de mongo, ejecute este comando:
```
mongo  --port port_number i.e mongo  --port 27017.
```
Sin embargo, en nuestro caso, necesitamos conectarnos con un nombre de conjunto de réplicas, por lo que debemos agregar el nombre al comando:
```
mongod --replSet replicaSetName --dbpath /usr/local/var/mongo/mongod --port 27017
```
En este caso nuestro replicaSetName =“testrep”

Verifiquemos si hay algún conjunto de réplicas habilitado ejecutando rs.status()

Si obtiene un resultado como:

{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}

Entonces significa que no hay un conjunto de réplicas habilitado. De lo contrario, si obtiene el resultado como

{
    "operationTime" : Timestamp(0, 0),
    "ok" : 0,
    "errmsg" : "no replset config has been received",
    "code" : 94,
    "codeName" : "NotYetInitialized",
    "$clusterTime" : {
        "clusterTime" : Timestamp(0, 0),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

entonces significa que la réplica aún no se ha iniciado.

El método rs.initiate() nos ayudará a iniciar un nuevo conjunto de réplicas y la instancia dentro de la cual se inicia se convierte en nuestro nodo principal. Entonces podemos iniciar uno en nuestra instancia ejecutando el método de inicio. rs.initiate().

Vuelva a comprobar el estado del conjunto de réplicas ejecutando rs.status().members. Ahora deberías ver algo como

"members" : [
        {
            "_id" : 0,
            "name" : "localhost:27018",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 577,
            "optime" : {
                "ts" : Timestamp(1535301271, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2018-08-26T16:34:31Z"),
            "syncingTo" : "",
            "syncSourceHost" : "",
            "syncSourceId" : -1,
            "infoMessage" : "could not find member to sync from",
            "electionTime" : Timestamp(1535301265, 1),
            "electionDate" : ISODate("2018-08-26T16:34:25Z"),
            "configVersion" : 1,
            "self" : true,
            "lastHeartbeatMessage" : ""
        }
    ]

Bueno, bueno para ir. Nuestro interés será la opción de miembros, como podemos ver, es una matriz con 1 miembro. Al marcar la opción stateStr del primer miembro, en este caso se establece en Principal, lo que significa que actuará como nuestro nodo principal.

Agregue un nuevo miembro al conjunto de réplicas utilizando su nombre de host. Para verificar el nombre de host de la instancia conectada que desea agregar, ejecute
```
db.serverStatus().host
```
Obtendrás algo como
```
ervername.local:27019
```
Entonces, desde PRIMARIO, puede agregar otro miembro ejecutando este comando en el shell de mongo:
```
rs.add("servername.local:27019");
```

Ejecute el comando de estado

rs.status().members

Para comprobar si se han realizado los cambios.

Ahora debería tener algo parecido a esto:

[
    {
        "_id" : 0,
        "name" : "localhost:27018",
        "health" : 1,
        "state" : 1,
        "stateStr" : "PRIMARY",
        "uptime" : 11479,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "syncingTo" : "",
        "syncSourceHost" : "",
        "syncSourceId" : -1,
        "infoMessage" : "",
        "electionTime" : Timestamp(1535301265, 1),
        "electionDate" : ISODate("2018-08-26T16:34:25Z"),
        "configVersion" : 2,
        "self" : true,
        "lastHeartbeatMessage" : ""
    },
    {
        "_id" : 1,
        "name" : "127.0.0.1:27019",
        "health" : 1,
        "state" : 2,
        "stateStr" : "SECONDARY",
        "uptime" : 15,
        "optime" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDurable" : {
            "ts" : Timestamp(1535312183, 1),
            "t" : NumberLong(1)
        },
        "optimeDate" : ISODate("2018-08-26T19:36:23Z"),
        "optimeDurableDate" : ISODate("2018-08-26T19:36:23Z"),
        "lastHeartbeat" : ISODate("2018-08-26T19:36:26.302Z"),
        "lastHeartbeatRecv" : ISODate("2018-08-26T19:36:27.936Z"),
        "pingMs" : NumberLong(0),
        "lastHeartbeatMessage" : "",
        "syncingTo" : "localhost:27018",
        "syncSourceHost" : "localhost:27018",
        "syncSourceId" : 0,
        "infoMessage" : "",
        "configVersion" : 2
    }
]

Ahora tenemos 2 miembros, uno es un nodo PRIMARIO y el otro es un nodo SECUNDARIO. Puede agregar más miembros, pero no más de 50. Ahora vamos a crear una base de datos en la instancia del puerto 27018 como principal.

Si desconectamos el principal, se producirá una conmutación por error y, dado que solo tenemos 1 principal, pasará automáticamente a un secundario. Ahora, si nos conectamos al del puerto 27019, debería obtener las mismas bases de datos y colecciones con sus documentos.

Ahora, si el nodo principal desconectado se vuelve a conectar, se agregará como secundario, ya que copia las operaciones del registro de operaciones del principal existente.

Preocupación de escritura del conjunto de réplicas de MongoDB

Si MongoDB devuelve un problema de escritura registrado con éxito, los datos se almacenarán en el disco y, por lo tanto, estarán disponibles después de que mongod se reinicie. Sin embargo, para las operaciones de escritura, los datos son duraderos solo después de que se repliquen y se confirmen en el diario a favor de la mayoría de los miembros votantes del conjunto de réplicas.

Algunos datos pueden ser demasiado grandes para actualizarlos o insertarlos, por lo que la replicación de los datos en otros miembros puede demorar más de lo esperado. Por esta razón, es recomendable editar las configuraciones de writeConcern para tener en cuenta la duración dentro de la cual se ejecutará una operación. Las configuraciones predeterminadas de writeConcern dictan que el conjunto de réplicas solo requiere el reconocimiento del miembro principal. Un problema de escritura predeterminado confirma las operaciones de escritura solo para el principal, pero se puede anular para verificar las operaciones de escritura en algunos miembros del conjunto de réplicas especificando el problema de escritura para una operación de escritura específica. Por ejemplo:

db.books.insert({name: “James”,place: “Beijing”},{writeConcern: {w: 3, wtimeout: 3600}})

La opción de escritura en este caso dicta que la operación debe devolver una respuesta solo después de que se haya extendido al primario y al menos a 2 secundarios o si se agota el tiempo de espera después de 3,6 segundos.

Configuración de la preocupación de escritura para MongoDB

La opción getLastErrorDefaults de MongoDB nos brinda los parámetros para modificar la configuración predeterminada de preocupación de escritura en la configuración del conjunto de réplicas. Esto implica que la operación tiene que estar completa en la mayoría de los miembros votantes antes de devolver el resultado.

cfg = rs.conf()
cfg.settings = {},
cfg.settings.getLastErrorDefaults = {w: “majority”, wtimeout: 3600}
rs.reconfig(cfg)

El valor de tiempo de espera evitará el bloqueo de las operaciones de escritura, es decir, si se supone que hay 5 miembros para confirmar el problema de escritura, pero lamentablemente hay 4 miembros o menos en el conjunto de réplicas, la operación se bloqueará hasta que todos los miembros estén disponibles. Al agregar el umbral de tiempo de espera, el bloqueo de la operación se descartará después de esta duración.

Bloqueo de replicación

El bloqueo de una operación, especialmente cuando todos los miembros se han replicado, garantiza que no se perderá más tiempo esperando que otro miembro del conjunto de réplicas esté disponible para devolver una respuesta. La opción del comando getLastError de MongoDB dicta cómo se realiza la actualización de la replicación utilizando el atributo "w" opcional.

Por ejemplo, esta consulta

db.runCommand({getLastError: 1, w: N, “wtimeout”: 5000});

requiere que el bloqueo ocurra hasta que un número N de miembros haya replicado la última operación de escritura. Si N está disponible o es menor que 2, se devolverá la consulta. De lo contrario, si el valor de N es igual a 2, el maestro equivalente al primario responderá solo después de que 1 de sus esclavos haya sido replicado en la última operación.

El wtimeout El parámetro es básicamente para establecer el tiempo en milisegundos después del cual el comando getLastError expirará y devolverá un error antes de que se haya replicado la última opción.

Por mucho que el bloqueo sea de alguna manera ventajoso, a veces tiene una limitación. Ralentiza significativamente las operaciones de lectura, especialmente si configura el valor "w" para que sea demasiado grande. Le recomendaría que establezca el valor "w" en 2 o 3 para mejorar la seguridad y la eficiencia.

Preferencia de lectura en MongoDB

Esta es básicamente la ruta adyacente con la que se realizan las operaciones de lectura del cliente al conjunto de réplicas. La configuración predeterminada de MongoDB configura las operaciones de lectura en el principal porque es el que tiene la última versión del documento que está recuperando. Como se mencionó anteriormente, la ventaja suprema de explotar el conjunto de réplicas es mejorar el rendimiento de nuestro sistema de base de datos. Por lo tanto, es recomendable distribuir las operaciones de lectura a muchos miembros secundarios para reducir la latencia de las aplicaciones que no necesariamente requieren datos actualizados. Sin embargo, hay razones más cruciales por las que también debe usar el principal como su preferencia básica:

Mantener la disponibilidad de datos durante la conmutación por error.
Para aplicaciones distribuidas geográficamente, la primaria proporcionará lecturas locales para clientes en el mismo centro de datos.
No afectar las aplicaciones front-end, especialmente aquellas que ejecutan operaciones del sistema.

Mongo.setReadPref() Método

Este método es básicamente para definir cómo el cliente enrutará todas las consultas a los miembros del conjunto de réplicas. Toma 2 argumentos, modo y conjunto de etiquetas.

El argumento de modo especifica la preferencia de lectura que puede ser primaria, primaria preferida, secundaria, secundaria preferida o la más cercana.

El modo tagSet especifica la preferencia de lectura personalizada. También puede especificarlos como una matriz de objetos. Un ejemplo de la configuración será:

db.getMongo().setReadPref('primaryPreferred',
                          [ { "dc": "east", "use": "production" },
                            { "dc": "east", "use": "reporting" },
                            { "dc": "east" },
                            {}
                          ] )

Lo que sucede aquí es que, si el cliente intenta acceder a la primera etiqueta y la solicitud no se realiza, optará por la segunda preferencia de lectura.

Modos de preferencia de lectura

Principal:esto define que todas las operaciones de lectura leídas de un conjunto de réplicas determinado son primarias y es el modo de lectura de preferencia predeterminado.
PrimaryPreferred:si solo el principal no está disponible, las operaciones de lectura se pueden realizar desde los secundarios.
Secundario:todas las operaciones de lectura se realizan desde los miembros secundarios del conjunto de réplicas.
SecondaryPreferred:si solo no hay una secundaria disponible, las operaciones de lectura se pueden realizar desde la primaria.
Más cercano:se selecciona el miembro con menor latencia de red para la operación de lectura, independientemente de su tipo.

Conjuntos de etiquetas y su configuración

Estas son opciones que le permiten modelar la forma en que desea que se vea su inquietud de escritura y preferencia de lectura. Se almacenan dentro del objeto de configuración del conjunto de réplicas. Si ejecuta rs.conf().members, obtendrá este objeto devuelto:

[
    {
        "_id" : 0,
        "host" : "localhost:27018",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    },
    {
        "_id" : 1,
        "host" : "127.0.0.1:27019",
        "arbiterOnly" : false,
        "buildIndexes" : true,
        "hidden" : false,
        "priority" : 1,
        "tags" : {
            
        },
        "slaveDelay" : NumberLong(0),
        "votes" : 1
    }
]

Como puede ver, cada miembro tiene un atributo de etiquetas.

La principal diferencia entre Preferencias de lectura y Preocupación de escritura es que, la primera considera el valor de una etiqueta al seleccionar un miembro para leer, mientras que la segunda no lo hace.

Digamos que una etiqueta establecida para una operación de lectura se establece en:

{ "disk": "ssd", "use": "reporting" }

Un miembro del conjunto de réplicas debe cumplir con estas etiquetas para que se lleve a cabo la operación de lectura. Por lo tanto decir, una configuración como esta

{ "disk": "ssd", "use": "reporting", "rack": "a" }

satisfará la consulta mientras que este

{ "disk": "ssd", "use": "production", "rack": "k" }

no satisfará la consulta.

Adición de etiquetas a una réplica de conjunto

Para su miembro seleccionado en un conjunto de réplicas, puede agregar conjuntos de etiquetas usando el método rs.conf() en MongoDB.

Supongamos que ha seleccionado un miembro en la posición 1 de su conjunto de réplicas, puede agregar conjuntos de etiquetas de la siguiente manera.

conf = rs.conf()
conf.members[0].tags = { "dc": "NYK", "use": "production"  }
conf.members[1].tags = { "dc": "LON", "use": "reporting"  }
conf.members[2].tags = { "use": "production"  }
rs.reconfig(conf)

Patrones de implementación para el conjunto de réplicas de MongoDB

Conjunto de réplicas distribuidas geográficamente:mejora la redundancia de los datos además de proteger los datos contra fallas como la pérdida de energía. Las instancias en ejecución se encuentran en varias ubicaciones.
Conjunto de réplicas de tres miembros:la arquitectura estándar básica para un conjunto de réplicas.
Conjunto de réplicas de cuatro o más miembros:permite una mayor redundancia de datos y también admite una distribución más amplia de operaciones de lectura en el conjunto de réplicas.

Técnicas de ajuste de implementación del conjunto de réplicas de MongoDB

Un conjunto de réplicas ideal requerirá una arquitectura bien diseñada con al menos 3 miembros para un sistema de producción. Estas estrategias de implementación lo ayudarán a habilitar un excelente conjunto de réplicas.

Utilice miembros retrasados y ocultos para admitir funciones dedicadas, como informes y copias de seguridad.
Haga siempre impar el número de miembros desplegados. Como hemos discutido anteriormente, se requerirá un número impar de miembros para elegir una primaria. Por lo tanto, asegúrese de tener un número impar y, de lo contrario, siempre puede agregar un árbitro.
Para implementaciones con muchas lecturas, deberá equilibrar la carga. Por lo tanto, se le pedirá que distribuya las lecturas al secundario para mejorar el rendimiento de lectura. Además, cuando los datos crecen con el tiempo, puede agregar más miembros y distribuirlos, pero tenga en cuenta que debe configurarlo de tal manera que el diseño principal sea elegir el principal.
Tenga siempre en cuenta la tolerancia a errores. Básicamente, esto determina cuántos miembros pueden no estar disponibles en un momento dado y cuántos permanecerán para sostener el proceso de elección de una primaria. Si no tiene un primario, lamentablemente el conjunto de réplicas no aceptará ninguna operación de escritura.
Agregue nuevos miembros al conjunto de réplicas existente antes de que surja la demanda.
Utilice conjuntos de etiquetas de conjunto de réplicas para asegurarse de que todas las operaciones se repliquen en centros de datos específicos. También puede usar estas etiquetas en el enrutamiento de las operaciones de lectura para máquinas de implementación específicas.
Distribuya a la mayoría de sus miembros en un solo lugar para evitar el contratiempo que surgirá de la partición de la red. La partición de la red puede ser el resultado de una comunicación desconectada entre los centros de datos, lo que dificulta el proceso de replicación y el proceso de elección de un principal.
Por razones de seguridad, distribuya a sus miembros geográficamente además de ocultar algunos. Puede establecer la prioridad de al menos 2 o 3 miembros en cero para evitar que se conviertan en principales.
Emplee el registro en diario para proteger la pérdida de datos que puede resultar en algo como una falla de energía. Esto garantiza que los datos se escriban en el disco en caso de un apagado repentino.

El registro de operaciones (Oplog)

El oplog mantiene un registro de las operaciones maestras que se aplicarán a los esclavos. Se almacena en una base de datos llamada local en la colección oplog.$main. Se crea cuando inicia un miembro del conjunto de réplicas por primera vez. En el límite superior, el registro de operaciones está restringido a un tamaño de 50 GB para todos los motores de almacenamiento. El tamaño del registro de operaciones se puede cambiar a partir de una configuración predeterminada. Si se alcanza este tamaño, por ejemplo, en 24 horas de funcionamiento, los secundarios no podrán copiarlo cómodamente durante este tiempo y es posible que terminen sin copiar en absoluto. Puede cambiar el tamaño del registro de operaciones utilizando la opción replSetResizeOplog, es decir,

db.database({replSetResizeOplog:1, size: 16384})

Si va a reducir el tamaño de este registro de operaciones, se eliminarán algunos datos. El impacto principal de esto en el conjunto de réplicas es que los miembros sincronizados con este nodo se vuelven obsoletos. Por lo tanto, deberá volver a sincronizar estos miembros.

Patrones de carga de trabajo que requerirían un tamaño de registro de operación grande

Actualiza varios documentos a la vez. Las múltiples operaciones de actualización deben traducirse en una operación individual para mejorar los resultados en los nodos. Esta operación utilizará una gran parte del espacio de oplog.
Número significativo de actualizaciones en el lugar. Esto generalmente sucede cuando se actualizan datos de documentos que no necesariamente aumentan el tamaño de este documento. La base de datos registrará una gran cantidad de operaciones en el registro de operaciones, por lo tanto, aumentará su tamaño.
Las eliminaciones equivalen a la misma cantidad de datos que las inserciones. Esto sucede cuando intenta eliminar una cantidad de datos (casi) igual a la cantidad de datos que inserta. Esta operación tenderá a aumentar el tamaño del registro de operaciones.

Conclusión

La replicación es un aspecto importante de las bases de datos que los desarrolladores deben comprender. Garantiza una mayor disponibilidad de datos. Su servidor MongoDB puede dejar de funcionar, por ejemplo, debido a un corte de energía, pero aún le gustaría que sus clientes accedan a sus datos. Si ha replicado datos en otro servidor, sus clientes podrán continuar accediendo a los datos si el servidor primario falla. Además, hay un mayor equilibrio de carga, de modo que en lugar de que todos los usuarios accedan a un solo servidor, hemos visto las ventajas y desventajas de atender el tráfico desde réplicas secundarias.