Así que pusiste MongoDB. Dime ¿cómo lo administras?

DevOps / Cloud /Scalability

Así que pusiste MongoDB. Dime ¿cómo lo

administras?
Alejandro E Brito Monedero @ae_bm

Así que pusiste MongoDB. Dime ¿cómo lo administras?

●

¿Quien soy?
–

Trabajo como administrador de sistemas y más

–

Estudié Ciencias de la Computacion

–

Participo en el grupo de Madrid DevOps

–

Aspirante a CTO (Chief Trolling Officer)


●

¿Aun no estas seguro de tu esquema de datos?

●

¿Has tenido que denormalizar tus datos?

●

No quieres tener que lidiar con sistemas como
pacemaker / corosync

●

Te gusta manipular JSON

●

Estas leyendo hacker news


●

Conoce a MongoDB
–

BD NoSQL

–

Orientado a documentos

–

No joins ni transacciones completas

–

Es “facil” poner en alta disponibilidad y hacer sharding

–

Empresa valorada en 1.2 Billones de $ (sorry RAE)


●

Algunos detalles en MongoDB
–

Orientado a documentos seerializados en formato BSON (Binary JSON)

–

Los drivers se comunican con la BD usando BSON

–

La manipulación sobre los documentos es atómica

–

Se pueden hacer reemplazos o updates parciales en los documentos

–

Los ficheros de la BD se manipulan con MMAP


●

Por si voy muy rápido
–

El tamaño máximo de un documento (hardcoded) son 16 MiB /
sino hay que usar GridFS

–

Se pueden hacer reemplazos o updates parciales en los
documentos

–

Cuidado con el aumentar en exceso el tamaño de un documento,
puedes forzar una relocalizacion (vease record size)


●

Por si voy muy rápido
–

Los ficheros de la BD se manipulan con MMAP

–

_id identificador único del documento (único por colección)

–

Las capped collections ya estan ordenadas por orden de
insercion

–

Locks a nivel de BD (v 2.2.X) con prioridad para las escrituras
(vease problema de lectores y escritores)


Mejor verlo graficamente


Vista lógica de un proceso mongod


Vista lógica como se almacenan los
documentos


Comienzos
mongodb@db01:~$ mongod dbpath /data/db journal


●

Backups
–

mongodump / mongorestore
●

●

Carga un poco al sistema

●

–

Fácil
Altera el page cache

Usando snapshots
●

Es necesario tener el journal activo

●

Rápido

●

Tienen que ser consistentes (SO y FS adecuados)


●

Backup mediante snapshots
–

Si todos los ficheros de datos y el journal estan en un
mismo disco
●

●

Hacer un snapshot con LVM ó EBS ó lo que uses
para hacer snapshots
Para restaurar simplemente iniciar un mongod con
la data del snapshot


●

–

Si los ficheros de datos estan en disco y el journal en otro o usas
RAID 1+0 con EBSs
●

Bloquear la BD – sincronizar (en el mongod)
db.fsyncLock();
Hacer el snapshot
–

●

●

Desbloquear la BD (no confiar en el autocompletar)
–

db.fsyncUnlock();


●

–

Los ficheros de datos en un disco y el journal en otro o usas
RAID 1+0 con EBSs (conectado al mongod)
●

Para restaurar seguir el proceso equivalente al caso anterior


Un mensaje de nuestros sponsors
No tienes backups hasta que has probado que
se hacen correctamente


Ahora la solución para el insomnio


●

Replicación
–

Llamados Replica Sets

–

Asincrona

–

Un solo nodo actua como primario (el único que procesa
escrituras)

–

Basada en statatements (change)

–

Auto failover

–

Auto node recovery


●

Replicación
–

El nodo primario es elegido por mayoria

–

El nodo con la data más actual es el favorito

–

Si se usa ack clusterwide no es necesario hacer rollback (para
cuando un antiguo primario se vuelve a unir al cluster)

–

Distintos niveles de preferencias para hacer lecturas


●

Replicación
–

Existen unos nodos llamados arbitrer, estos no tienen data pero
votan en la elección del primario

–

Siempre debe haber un número impar de votos para evitar un
caso de split-brain

–

Se pueden tener nodos secundarios con sincronizacion retardada
(util para cuando un error humano se replica XD)


●

Replicación
–

El cliente puede escoger el nivel de garantia que necesitamos al
escribir datos
●

Ninguno

●

Escrito en 1 nodo

●

Escrito en N nodos

●

Escrito en la mayoria de los nodos

●

Escrito en los nodos con el tag indicado


●

Replicación
–

Los secundarios se sincronizan con el primario, leyendo una
capped collection llamada oplog
●

Debe ser lo suficientemente grande para que el primario no
sobreescriba datos que los secundarios no han consumido

–

Se pueden tener nodos hidden (prácticos para hacer backups)

–

Máximo 12 nodos, de los cuales máximo 7 pueden tener voto


●

Opciones para configura la replicación (RS)
–

Priority: Indicamos nuestra preferencia por un primario

–

Hidden: Nodo oculto (no es visto ni consultado por los clientes)

–

Arbitrer

–

SlaveDelay: Indicar el retardo que tiene la replica

–

Tags: Para tener datacenter o rack awareness

–

Vote


Mejor verlo con diagramas


Funcionamiento lógico del HA


Ejemplo del uso de las prioridades


●

Para quitar el dolor de cabeza de no tener la BD replicada
–

Apagar el proceso mongod
●

●

–

Puedes hacer un fichero de configuracion para ahorrar el
pasar tantos parametros al iniciar mongod (ejem: El RS)
Hacer un snapshot no estaria de más

Iniciar mongod indicando el RS al que pertenece (Aunque el
proceso este arriba, como no esta inicializado, no hay primario,
solo se pueden hacer operaciones administrativas


●

–

Crear una configuración con el nombre con el nombre con el
que los clientes y otros miembros se conectaran al nodo

–

Iniciar el replica set

–

Ya tenemos mayoria, se elige un primario y se pueden aceptar
lecturas y escrituras

–

Sacar un snapshot para crear el secundario N y asi ahorrarnos un
full sync (hay que tener un oplog lo suficientemente grande)


●

–

Crear la máquina nueva con los datos del snapshot más reciente

–

Iniciar mongod indicando el replica set

–

Conectarse al nodo primario y agregar el nodo

–

Esperar a que se sincronice (esperemos que no sea un full sync)

–

Irse de vacaciones


●

Comandos para manipular los replica set
–

rs.initiate(cfg): Iniciar el RS, donde cfg es un documento JSON
con la configuración

–

rs.add("dbXX"): Agrega un nodo al RS

–

rs.config(): Muestra la configuración actual

–

rs.status(): Ver estado del RS

–

rs.isMaster()

–

db.printReplicationInfo(): Ver info sobre la replicación y el
oplog


Ejemplo de configuración de un RS


Ejemplo de rs.status() 1/2


Ejemplo de rs.status() 2/2


Ejemplo de db.printReplicationInfo()


●

Cosas para no olvidar sobre los RS
–

Sirven para hacer rolling updates (S-S-P)

–

Se pueden tener nodos dedicados para hacer backups

–

Se pueden tener nodos que repliquen con un retardo

–

Cuidado con la latencia y el tamaño del oplog

–

Distribuir los nodos en distintos sitios físicos (sea un entorno
cloud o no)


Vamos a hacer sharding


●

Sharding
–

Se usa para hacer scaling out

–

Se hace mediante rangos, según la llave seleccionada

–

La data se divide en chunks, los cuales se pueden migrar de un
shard a otro hasta que todos los shards esten balanceados

–

Se hace a nivel de colección


●

Sharding
–

Existen 2 tipos de operaciones en background
●

●

Split: cambia el metadata de un chunk al dividirlo
(operación no costosa)
Migrate: para mantener el balance, copia el chunk a otro
shard, despues actualiza la metadata. Se hace sin downtime,
pero es una operación costosa


●

Sharding
–

Los clientes se conectan a un proceso llamado mongos (es un
proxy que sabe en que shard está almacenada la información)

–

Se deberian tener 3 procesos mongod que sirven de config
servers (tienen la metadata que mapea un rango de la shard key
con el shard correspondiente)

–

Los config servers funcionan con 2 phase commit, así que si no
estan los 3 no se puede actualizar la metadata


●

Comenzar a a hacer sharding
–

Iniciar 3 mongod en máquinas distintas como config servers (no
olvidar el crear el dbpath)

–

Iniciar un mongos, indicandole las direcciones de los 3 config
servers

–

Conectarse al mongos y agregar un shard indicando el replica
set y al menos un miembro

–

Habilitar el sharding en la bd que contiene la colección que nos
interesa fragmentar


●

Comenzar a a hacer sharding
–

Crear un indice en la colección, la que usaremos como shard key

–

Activar el sharding en la colección indicando el indice a usar
como shard key

–

Si queremos agregar más replica sets, repetimos el punto de
agregar shards


●

Hacer backups con sharding
–

Detener el balanceador, sino puede que al hacer un respaldo,
haya información que se este migrando de shard y que se pierda
o se duplique

–

Hacer backup de los servidores de config apagando uno y
haciendo mongodump, para evitar cambios en la metadata

–

Hacer el backup de cada shard

–

Activar de nuevo los 3 config servers

–

Iniciar el balanceador


●

Comandos usados al hacer sharding
–

sh.addShard()

–

sh.status()

–

sh.enableSharding()

–

sh.shardCollection()

–

sh.stopBalancer()

–

sh.startBalancer()


●

Comandos usados al hacer sharding
–

sh.getBalancerState(): Ver si el balancer está activo

–

sh.isBalancerRunning(): Ver si hay migraciones en proceso


●

Consideraciones al hacer sharding
–

Es muy importante seleccionar un shard key que no presente
crecimiento monotono y con mucha cardinalidad, ahora hay un
helper que maneja la shard key usando un hash

–

Después de escoger un shard key no se puede cambiar


●

Consideraciones al hacer sharding
–

De ahora en adelante siempre operar a traves de un mongos, a
menos que se tenga que manipular un replica set

–

Si vas a hacer un bulk load considera hacer pre splitting, así
ahorras las actualizacione de metadata que hacen los config
servers


Ejemplo de una arquitectura lógica para hacer sharding


Ejemplo de lo que puede pasar si no detienes la migración de
chunks


Ejemplo del comando sh.status() 1/2


Ejemplo del comando sh.status() 2/2


●

Indices
–

Por ahora solo hay del tipo b-tree

–

Pueden ser simples o compuestos

–

En los indices compuestos importa el orden de los campos con
los que se creo el indice

–

Si no se crean en background (ensureIndex) son bloqueantes

–

Permiten duplicados


●

Indices
–

Se pueden usar sobre arrays o documentos anidados

–

Soportan el modo sparse, es bueno usar este tipo cuando se
hacen indices sobre campos que no están en un porcentaje alto
de documentos ~ 95%

–

También hay indices geoespaciales

–

Mejoran las lecturas pero las escrituras se hacen más lentas


●

Indices
–

Más indices implica hacer más escrituras

–

Si el documento tiene que ser relocalizado dentro del fichero
tambien hay que actualizar el indice

–

Es más rápido construir un indice despues de un import que
tenerlo creado antes hacer un bulk import

–

Cada cierto número de consultas la BD prueba varios planes
para saber cual es el mejor plan a seguir al hacer la consulta


●

Algunas operaciones relacionadas con los indices
–

.hint(): Sirve para forzar a usar un indice en particular

–

.explain(): Con esto sabemos si nos conviene crear un indice
para la consulta o si se está usando el indice


Ejemplo de consulta sin indice


Ejemplo de consulta con indice


●

Monitoring y otros tips
–

Existen comandos como el mongostat que nos sirven para ver
cosas como los fallos de página, el % de bloqueo de las bbdd, el
tamaño del conjunto residente y todas esas cosas que aprendiste
en sistemas operativos ^_^

–

Mongodb (la compañia) ofrece un servicio de monitoring en
cloud (MMS), por si te sientes cansado o no tienes tiempo


●

Monitoring y otros tips
–

RAM, más es mejor

–

Tener CPUs rápidas

–

Discos rápidos

–

Tener la data y el journal en spindles distintos

–

Usar RAID 1+0

–

Desactivar NUMA o hacer malabarismos con cgroups

–

Usar tamaños de readahead pequeños por la entrada y salida
aleatoria


●

Referencias / tarea
–

http://docs.mongodb.org/manual/administration/

–

http://media.amazonwebservices.com/AWS_NoSQL_MongoDB.pdf

–

https://education.mongodb.com/

–

http://docs.mongodb.org/manual/administration/production-notes/

–

Para ver pruebas de stress sobre BD distribuidas
http://aphyr.com/tags/jepsen

–

No olviden visitar http://madrid.devops.es/

Así que pusiste MongoDB. Dime ¿cómo lo administras?

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Así que pusiste MongoDB. Dime ¿cómo lo administras?

Ähnlich wie Así que pusiste MongoDB. Dime ¿cómo lo administras? (20)

Mehr von Alejandro E Brito Monedero

Mehr von Alejandro E Brito Monedero (14)

Kürzlich hochgeladen

Kürzlich hochgeladen (13)

Así que pusiste MongoDB. Dime ¿cómo lo administras?