Universidad de San Buenaventura

ESPECIALIZACIÓN EN PROCESOS PARA EL DESARROLLO DE SOFTWARE

Replicación de bases de datos NoSql

1. La replicación proporciona redundancia y aumenta la disponibilidad de los datos.

Mediante múltiples copias de la información en diferentes servidores de bases de datos, la
replicación protege una base de datos de la pérdida de un solo servidor.

2. La replicación también le permite recuperarse de un fallo de hardware y las

interrupciones del servicio. Mediante copias adicionales de los datos

3. Un conjunto de réplicas es un grupo de instancias mongod que alojan el mismo

conjunto de datos.
4. Uno mongod (demonio del servicio), primaria, recibe todas las operaciones de
escritura. Todos los otros casos, secundarias, aplican operaciones sobre la primaria para
que tengan el mismo conjunto de datos.

El nodo principal o primario: acepta todas las operaciones de escritura de los clientes.
Conjunto de réplicas puede tener sólo una primaria. Debido a que sólo un miembro
puede aceptar operaciones de escritura, conjuntos de réplicas proporcionan
consistencia estricta para lectura de datos desde la primaria.
Los secundarios se replican de la primaria y aplican las operaciones a sus conjuntos de
datos. Conjuntos de datos secundarios reflejan el conjunto de datos primaria. Si el primario
no está disponible, en el conjunto de réplicas se elegirá a un secundario a ser primaria de
forma predeterminada.

Es posible agregar una instancia mongod extra para un conjunto de réplicas, el cual actuara
como árbitro. Los árbitros no mantienen un conjunto de datos. Árbitros sólo existen para
votar en las elecciones.

Conmutación automática por error

Cuando una primaria no se comunica con los otros miembros del conjunto por más de 10
segundos, el conjunto de réplicas intentará seleccionar a otro miembro para convertirse en el
nuevo primario. La primera secundaria que recibe la mayoría de los votos se convierte en
primordial.
Paso para la configuración de una réplica en MongoDb

1. En el archivo de configuración de mongo debemos especificar el nombre del replicaset

que vamos a configurar, asi:
 Detener la instancia de mongo para realizar los cambios en la configuración:
service mongodb stop detener, service mongodb start iniciar
 En las distribuciones ubuntu el archivo de configuración se encuentra en
/etc/mongodb.conf, editar el archivo y adicionar el nombre del replicaset,
para todos los mienbros de la replica.
 Para el ejemplo se a definido replSet replicaMongo, guardar y aceptar los
cambios
 Establecer las ip permitidas y los puertos por donde escuchara el servicio
de replicación, de la siguiente manera:
bind_ip = 0.0.0.0
port = 27017
 En el archivos mongodb.conf y en todos los miembros del replica set

2. una ver iniciado el servicio de mongo, iniciamos la consola con el comando mongo, y
revisamos el estado del replicaset con el comando rs.status();
$ mongo
...
> rs.status()
{
"startupStatus" : 3,
"info" : "run rs.initiate(...) if not yet done for the set",
"ok" : 0,
"errmsg" : "can't get local.system.replset config from self or any seed
(EMPTYCONFIG)"
}
rs.confg()
null

3. Iniciemos el replica set ejecutando el comando rs.initiate(): (en el primario)

Comando rs.initiate()

> rs.initiate()
{
"info2" : "no configuration explicitly specified -- making one",
"me" : "Mordor.local:27017",
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}

Para este caso mongod creará una configuración sencilla base para el replica set

replicaMongo:PRIMARY> rs.status()
{
"set" : "replicaMongo",
"date" : ISODate("2013-12-15T15:43:27Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "Mordor.local:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 401,
"optime" : Timestamp(1387122082, 1),
"optimeDate" : ISODate("2013-12-15T15:41:22Z"),
"self" : true
}
],
"ok" : 1
}
replicaMongo:PRIMARY> rs.conf()
{
"_id" : "replicaMongo",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "local:27017"
}
]
}

Ahora la consola de mongo indica el miembro específico sobre el cual estamos ejecutando
los comandos, en este caso sobre el primario (PRIMARY) del replica set de nombre
replicaMongo.

Podemos notar también mucha información con respecto a los miembros del replica
set como la estampilla de tiempo de la última operación realizada (optime), su estado
funcional, su función dentro del replica set .

Agregar miembros:

Nota: Para poder agregar los miembros del replica set, debemos configurar los permisos de
acceso de la red para que los equipos pueden comunicarse:
el archivos de configuración es /etc/hosts.allow, en este archivo colocaremos el parámetro
de los host que deseamos se comuniquen entre si. Para el ejemplo se utiliza ALL : ALL que
significa todos. Editar el archivo y agregar el parametros : gedit /etc/hosts.allow, guardar los
cambios

1. En los equipos secundarios debemos indicar el nombre del replica set de la misma
manera que lo hicimos con la primaria, editar el archivo de configuración. (en este caso
utilizamos el nombre replicaMongo)

2. al igual que en el primario detener antes de realizar la configuración, y reiniciar la

instancia de mongo después de hacer los cambios en el archivo.

3. Una ves realizados los cambios en los secundarios ejecutar rs.status()

> rs.status()
{
"startupStatus" : 3,
"info" : "run rs.initiate(...) if not yet done for the set",
"ok" : 0,
"errmsg" : "can't get local.system.replset config from self or any seed
(EMPTYCONFIG)"
}

En este caso no ejecutaremos rs.inititate() ya que el replica set se encuentra iniciado por
otro lado y este miembro será uno que agregaremos a este ya existente.
4. identificar la IP del equipo o equipos para agregarlos al primario, mediante el comando
ifconfig, este comando despliega la información de la configuración de las tarjetas de red.

vagrant@precise32:~$ ifconfig
Eth1 Link encap:Ethernet HWaddr **:**:**:**:**:**
inet addr:192.168.33.10 Bcast:192.168.33.255 Mask:255.255.255.0

5. Ahora volveremos a nuestra instancia primaria para agregar el nuevo miembro al replica
set:

replicaMongo:PRIMARY> rs.add('192.168.33.10:27017'), Si todo está bien

{ "ok" : 1 }

Esperamos un poco a que MongoDB para revisar la configuración del primario.

replicaMongo:PRIMARY> rs.status()
{
"set" : "replicaMongo",
"date" : ISODate("2013-12-15T17:40:32Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "local:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2010,
"optime" : Timestamp(1387129181, 1),
"optimeDate" : ISODate("2013-12-15T17:39:41Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.33.10:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 51,
"optime" : Timestamp(1387129181, 1),
"optimeDate" : ISODate("2013-12-15T17:39:41Z"),
"lastHeartbeat" : ISODate("2013-12-15T17:40:31Z"),
"lastHeartbeatRecv" : ISODate("2013-12-15T17:40:30Z"),
"pingMs" : 1,
 "lastHeartbeatMessage" : "syncing to: Mordor.local:27017",
"syncingTo" : ".local:27017"
}
],
"ok" : 1
}
miRS:PRIMARY> rs.conf()
{
"_id" : "replicaMongo",
"version" : 2,
"members" : [
{
"_id" : 0,
"host" : ".local:27017"
},
{
"_id" : 1,
"host" : "192.168.33.10:27017"
}
]
}