Los conjuntos de réplica son básicamente maestro-esclavo con failover automático.
La idea es: tienes un esclavo y uno o más esclavos. Si el maestro se cae, uno de los esclavos automáticamente se convertirá en el nuevo maestro. Los drivers de base de datos, siempre encontrarán al maestro, si el maestro que se está usando se cae, ellos (drivers) automáticamente entenderán quién es el nuevo maestro y envía las escrituras a dichos servidor. Esto es mucho más fácil de manejar (y más rápido) que manejar manualmente el fallo sobre un esclavo.
Así, tu tienes un pool de servidores con un primario (el maestro) y N secundarios (esclavos). Si el primario tiene un accidente y desaparece, los otros servidores mantendrán una elección para elegir un nuevo primario.
Elecciones
Un servidor tiene que obtener una mayoría del total de votos para ser elegido, no sólo una mayoría. Esto significa que, si tenemos 50 servidores y cada servidor tiene un voto (por defecto, los últimos post mostrará cómo cambiar el número de votos que un servidor obtiene), un servidor necesita al menos 26 votos para convertirse en primario. Si ninguno obtiene 26 votos, ninguno se convierte en primario. El conjunto puede todavía manejar lecturas, pero no escrituras (ya que no hay maestro).
Si un servidor obtiene 26 o más votos, éste se convertirá en primario. Todas las futuras escrituras serán direccionadas a éste, hasta que pierda una elección, estalle, etc.
El primario original es todavía parte del cojunto. Si lo levantas, éste se convertirá en un servidor secundario (hasta que obtenga nuevamente la mayoría de votos).
Una multitud de tres (de buena manera)
Una complicación con este sistema de votación es que tú no puedes tener sólo un maestro y un esclavo.
Si estableces sólo un maestro y un esclavo, el sistema tiene un total de 2 votos, así que un servidor necesita ambos botos para ser elegido maestro (1 no es mayoría). Si uno de los servidores se cae, el otro servidor sólo tiene un voto de 2, así que ésto lo convierte (o lo conserva) en un esclavo. Si la red está particionada, y repentinamente el maestro no tiene una mayoría de los votosos (sólo tiene su único voto), será degradado a un esclavo. El esclavo además no tiene una mayoría de los votos, po lo que permanecerá siendo esclavo (así que terminarás con dos esclavos hasta que los servidores se puedan alcanzarse el uno al otro de nuevo).
Esto es un desperdicio, aunque, tener dos servidores y ningún maestro levantado, los conjuntos de réplica tienen varias formas de evitar esta situación. Una de las más simples y más versátiles es usar un árbitro, un servidor especial que existe para resolver disputas. Éste no sirve ningún dato al mundo exterior, si no que es simplemente un votante (puede incluso estar en la misma máquina como otro servidor, siendo muy ligero). En la parte 1, el árbitro era localhost:27019.
Así, digamos que establecemos un maestro, un esclavo y un árbitro, cada un con un voto (total 3 votos). Entonces, si tenemos un maestro y un árbitro en un centro de datos y el esclavo en otro, si se produce una partición de red, el maestro todavía tendrá una mayoría de votos (maestro+árbitro). El esclavo tiene sólo 1 voto. Si el maestro falle y la red no se particiona, el árbitro puede votar por el esclavo, promocionándole como maestro.
Con esta configuración de tres servidores, obtenemos un failover sensible y robusto.
Lo próximo: configuración dinámica de tu conjunto de réplica. En la parte 1, confiramos todo completamente al empezar. En el mundo real querremos ser capaces de añadir servidores dinámicamente y cambiar la configuración.
Artículo original: http://www.snailinaturtleneck.com/blog/2010/08/02/replica-sets-part-2-what-are-replica-sets/
