Un conjunto de réplica significa que tiene varias instancias de MongoDB que reflejan todos los datos entre sí. Un conjunto de réplicas consta de un Maestro (también llamado "Primario") y uno o más Esclavos (también conocido como Secundario). Cualquier esclavo puede realizar operaciones de lectura, por lo que puede aumentar el rendimiento de lectura agregando más esclavos al conjunto de réplicas (siempre que su aplicación cliente sea capaz de utilizar diferentes miembros de conjunto). Pero las operaciones de escritura siempre tienen lugar en el maestro del conjunto de réplicas y luego se propagan a los esclavos, por lo que las escrituras no serán más rápidas cuando agregue más esclavos.
Los conjuntos de réplica también ofrecen tolerancia a fallas. Cuando uno de los miembros del conjunto de réplicas cae, los otros se hacen cargo. Cuando el maestro cae, los esclavos elegirán un nuevo maestro. Por esa razón , se recomienda que la implementación productiva utilice siempre MongoDB como un conjunto de réplica de al menos tres servidores, dos de los cuales contienen datos (el tercero es un "árbitro" sin datos que se requiere para determinar un nuevo maestro cuando uno de los esclavos cae).
Un clúster fragmentado significa que cada fragmento del clúster (que también puede ser un conjunto de réplicas) se ocupa de una parte de los datos. Cada solicitud, tanto de lectura como de escritura, es atendida por el clúster donde residen los datos. Esto significa que se puede aumentar el rendimiento de lectura y escritura agregando más fragmentos a un clúster. Qué documento reside en qué fragmento está determinado por la clave de fragmento de cada colección. Debe elegirse de manera que los datos se puedan distribuir uniformemente en todos los clústeres y de modo que quede claro para las consultas más comunes donde reside la clave de fragmento (ejemplo: cuando consulta con frecuencia user_name, su clave de fragmento debe incluir el campo user_namepor lo que cada consulta se puede delegar a sólo el fragmento que tiene ese documento).
El inconveniente es que la tolerancia a fallos sufre. Cuando un fragmento del clúster se cae, no se puede acceder a los datos que contiene. Por esa razón, cada miembro del clúster también debe ser un conjunto de réplicas. Esto no es requerido. Cuando no le importa la alta disponibilidad, un fragmento también puede ser una sola instancia mongod sin replicación . Pero para el uso de producción siempre debe usar la replicación .
Entonces, ¿qué significa eso para tu ejemplo?
Sharded Cluster
/ | \
Shard A Shard B Shard C
/ \ / \ / \
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
|Primary| |Secondary| |Primary| |Secondary| |Primary| |Secondary|
| 25GB |=| 25GB | | 25 GB |=| 25 GB | | 25GB |=| 25GB |
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
Cuando desee dividir sus datos de 75 GB en 3 fragmentos de 25 GB cada uno, necesita al menos 6 servidores de bases de datos organizados en tres conjuntos de réplicas. Cada conjunto de réplicas consta de dos servidores que tienen los mismos 25 GB de datos.
También necesita servidores para los árbitros de los tres conjuntos de réplicas, así como el enrutador mongos y el servidor de configuración para el clúster. Los árbitros son muy livianos y solo se necesitan cuando un miembro del conjunto de réplicas cae, por lo que generalmente pueden compartir el mismo hardware con otra cosa. Pero el enrutador y el servidor de configuración de Mongos deberían ser redundantes y estar en sus propios servidores.