Analisis SAOCOM Sync Mongo
==========================

###### tags: `SAOCOM` `SAOSM-71` `Mongo`

# Sincronización MongoDb

## Problema detectado

se ve en log de mongo que al conectar la VM-SAO-GRS-CORE-USS-ALL-NSQL01-1 (13.121) al principio no tenía conexión con VM Primaria. Luego se conectan y se intenta sincronizar las BD, en la misma se presenta un error ya que las BD estan muy defasadas en contenido, por consiguiente la VM-SAO-GRS-CORE-USS-ALL-NSQL01-1 no pudo sincronizarse quedando en estado RECOVERING.

### Estado de las replicas (VM 13.121)
La replica en puerto 27017 esta seteada como primaria y la que esta en puerto 27018 esta como secundaria (13.121).
`rs.status()` :

{
	"set": "rsuss0",
	"date": {
		"$date": "2019-12-02T14:54:39.126+0000"
	},
	"myState": 1.0,
	"members": [{
		"_id": 0.0,
		"name": "VM-SAO-GRS-CORE-USS-ALL-NSQL01-1:27017",
		"health": 1.0,
		"state": 3.0,
		"stateStr": "RECOVERING",
		"uptime": 251641.0,
		"optime": {
			"$timestamp": {
				"t": 1573612066,
				"i": 1
			}
		},
		"optimeDate": {
			"$date": "2019-11-13T02:27:46.000+0000"
		},
		"lastHeartbeat": {
			"$date": "2019-12-02T14:54:39.107+0000"
		},
		"lastHeartbeatRecv": {
			"$date": "2019-12-02T14:54:38.006+0000"
		},
		"pingMs": 0.0,
		"configVersion": 4.0
	}, {
		"_id": 1.0,
		"name": "VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27017",
		"health": 1.0,
		"state": 1.0,
		"stateStr": "PRIMARY",
		"uptime": 257544.0,
		"optime": {
			"$timestamp": {
				"t": 1575033202,
				"i": 1
			}
		},
		"optimeDate": {
			"$date": "2019-11-29T13:13:22.000+0000"
		},
		"electionTime": {
			"$timestamp": {
				"t": 1575041229,
				"i": 1
			}
		},
		"electionDate": {
			"$date": "2019-11-29T15:27:09.000+0000"
		},
		"configVersion": 4.0,
		"self": true
	}, {
		"_id": 2.0,
		"name": "VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27018",
		"health": 1.0,
		"state": 2.0,
		"stateStr": "SECONDARY",
		"uptime": 257249.0,
		"optime": {
			"$timestamp": {
				"t": 1575033202,
				"i": 1
			}
		},
		"optimeDate": {
			"$date": "2019-11-29T13:13:22.000+0000"
		},
		"lastHeartbeat": {
			"$date": "2019-12-02T14:54:37.528+0000"
		},
		"lastHeartbeatRecv": {
			"$date": "2019-12-02T14:54:37.661+0000"
		},
		"pingMs": 0.0,
		"configVersion": 4.0
	}],
	"ok": 1.0
}

### Info de la replica (VM 13.121)
`rs.printReplicationInfo()` :

configured oplog size:   3028.406234741211MB
log length start to end: 112933secs (31.37hrs)
oplog first event time:  Thu Nov 28 2019 02:51:09 GMT-0300
oplog last event time:   Fri Nov 29 2019 10:13:22 GMT-0300
now:                     Tue Dec 03 2019 09:05:50 GMT-0300

### Logs

En los logs de mongo se pudo encontrar el siguiente mensaje de error:

2019-11-29T17:00:37.040+0000 I REPL     [ReplicationExecutor] Member VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27018 is now in state SECONDARY
2019-11-29T17:00:37.056+0000 I REPL     [ReplicationExecutor] Member VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27017 is now in state PRIMARY
2019-11-29T17:00:37.128+0000 I NETWORK  [initandlisten] connection accepted from 192.168.13.124:58768 #3 (3 connections now open)
2019-11-29T17:00:38.944+0000 I NETWORK  [initandlisten] connection accepted from 192.168.17.208:54848 #4 (4 connections now open)
2019-11-29T17:00:38.944+0000 I NETWORK  [conn4] end connection 192.168.17.208:54848 (3 connections now open)
2019-11-29T17:00:39.267+0000 I REPL     [ReplicationExecutor] syncing from: VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27017
2019-11-29T17:00:39.336+0000 W REPL     [rsBackgroundSync] we are too stale to use VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27017 as a sync source
2019-11-29T17:00:39.336+0000 I REPL     [ReplicationExecutor] syncing from: VM-SAO-GRS-CORE-USS-ALL-NSQL01-2:27018
2019-11-29T17:00:39.421+0000 I REPL     [ReplicationExecutor] could not find member to sync from
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet error RS102 too stale to catch up
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet our last optime : Nov 13 02:27:46 5dcb6a22:1
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet oldest available is Nov 28 05:51:09 5ddf604d:3
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember
2019-11-29T17:00:39.421+0000 I REPL     [ReplicationExecutor] transition to RECOVERING

...

2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet error RS102 too stale to catch up
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet our last optime : Nov 13 02:27:46 5dcb6a22:1
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet oldest available is Nov 28 05:51:09 5ddf604d:3
2019-11-29T17:00:39.421+0000 I REPL     [rsBackgroundSync] replSet See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember

Este error se produce en varios escenarios, lo que entendemos es que se produce porque la cantidad de datos que se deben sincronizar entre las bases de datos es demasiado grande.

## Propuestas para la sincronización

### Opción 1: Sincronizar desde un backup

La solución puede ser exportar las BD de la VM activa e importar en la VM inactiva ailada. Luego iniciar la VM inactiva en el entorno y ver que se sincronicen correctamente.

Esto implica
- generar un backup de la base de datos de la cadena de backup,
- restaurar el backup en la cadena pincipal
- iniciar las bases de datos para que se puedan sincronizar

pros:
- Toma menos tiempo sincronizar
-
contr:
- Puede ocasionar errores al intentar cambiar de cadena ?

### Opción 2: Actualizar conficuración para la sincronización

La solución puede estar en aumentar el tamaño del registro de operaciones para la sincronización del nodo obsoleto.

Pros
- Es lo recomendado en páginas
- ??

Contras
- Requiere saber el tamaño y que recursos hacen falta para poder sincronizar cuando hay como 3 semanas de defasaje en datos.
- Puede demorar mucho la sincronización.
- Puede fallar por falta de recursos

### Opción 3: Iniciar con un mongo vacío

Reiniciar el mongo de la cadena main conn un directorio de datos vacio

pros:
- Este proceso es más simple
-
contr:
- toma mucho tiempo volver a sincronizar los datos
-

### Opción 4: Utilizar el directorio de datos de la base de datos principal

Copiar el directorio de datos de la base de datos del host 01-2 al host 01-1

pros:
- toma menos tiempo volver a sincronizar los datos
-
contr:
- Este proceso es más complejo
-

## Requerimientos

Para poder definir el procedimiento de sincronización necesitamos:

- Poder replicar las base de datos de las dos cadenas para poder valizar el procedimiento

mongodump --host="mongodb0.example.com" --port=27017 --archive=dump_`date "+%Y-%m-%d"`.gz --gzip 

## Referencias

[1] https://manios.org/2017/11/23/mongodb-replica-stale-during-recovery
[2] https://dba.stackexchange.com/questions/176154/mongodb-secondary-node-not-recovering
[3] http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember