Paso 1: No usar fragmentación
En serio. Casi nadie lo necesita. Si estabas en el punto donde necesitabas particionar tu base de datos MySQL, probablemente tengas otras vías de hacerlo antes de que necesites particionar MongoDB (nos burlamos de los billones de filas).
Ejecuta MongoDB como un conjunto de réplica. Cuando necesites realmente capacidad extra, entonce, y sólo entonces, comienza la fragmentación. ¿Por qué?
1. Tienes que elegir una clave de fragmentación. Si conoces las características de tu sistema antes de elegir una clave de fragmentación, puedes ahorrarte a tí mismo un mundo de dolor.
2. La fragmentación añade complejidad.: tienes que mantener trazabilidad de más máquinas y procesos.
3. La optimización prematura es la raíz de todo mal. Si tu aplicación no se ejecuta rápido, ¿está tu CPI o tu red limitadas? ¿Tienes demasiados índices? ¿Demasiados pocos? ¿Están siendo golpeados por tus consultas? Verifica (al menos) todas estas causas primero.
Usar la fragmentación
Un fragmento está definido como uno o más servidores con un maestro. Asi, un fragmento podría ser un simple mongod (mala idea), una configuración maestro-esclavo (mejor idea), o un conjunto de ráplica (mejor idea).
Digamos que renemos tres fragmentos y cada uno de ellos es un conjunto de réplica. Para tres fragmentos, querrás un mínimo de 3 servidores (la regla general es: mínimo de N servidores para N fragmentos). Haremos también el mínimo en los conjuntos de réplica: un maestro, primario y árbitro para cada conjunto.
Las tazas son procesos MongoDB. Así, tenemos tres conjuntos de réplica:
“M” representa al “maestro” (master), “S” representa al “esclavo” (slave), y “A” representa el "árbitro" (arbiter). Tenemos también los servidores de configuración:
y procesos mongos:
Ahora, soporta estos procesos en servidores (las bandejas son servidores). Cada maestro necesita hacer mucho, así que cada primario toma su propio servidor.
Ahora ponemos también un esclavo y un árbitro en cada caja.
Observar cómo mezclamos las cosas: sin conjunto de réplica está alojado en un servidor simple, así que si un servidor se cae, el conjunto puede recuperarse en un servidor diferente y seguir funcionando.
Ahora podemos añadir tres servidores de configuración y dos procesos mongos. Los procesos mongos son puestos normalmente en el appserver, pero son muy ligeros, así que soportaremos un par de ellos aquí.
Un poco cargado, pero posible
En caso de emergencia...
Digamos que caemos una bandeja. CRASH! Con esta configuración, tus datos están a salvo (mientras estés usando w) y el cluster no pierde funcionalidad (en términos de lecturas y escrituras).
Los trozos no estarán disponibles para migrar (debido a que uno de los servidores de configuración está caído), así que un fragmento puede estar "hinchado" si el servidor de configuración está caído por mucho tiempo.
Las particiones de red y perder dos servidores son problemas grandes, así que deberías tener más de tres servidores si quieres gran disponibilidad.
Fuente original: http://www.snailinaturtleneck.com/blog/2010/08/09/sharding-and-replica-sets-illustrated/
