II Jornadas Técnicas UEx – CIEMAT. Introducción a NoSQL con MongoDB
En esta presentación se tratan temas como la configuración avanzada, Replica Set, Sharding, Seguridad y Backups
Linux, OS X y Windows. Si nos centramos en la distribución Ubuntu-Server 14.04 LTS: Importar la clave pública usada por el sistema de paquetería (dpkg/apt): apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv EA312927 Incluir el repositorio de MongoDB dentro de /etc/apt/sources.list.d: echo "deb http://repo.mongodb.org/apt/ubuntu trusty/mongodb-org/3.2 multiverse" | tee /etc/apt/sources.list.d/mongodb-org-3.2.list Actualizar la base de datos de paquetes: apt-get update Instalar la última versión estable de MongoDB: apt-get install -y mongodb-org
realizar la configuración el servicio mongod de dos formas distintas: Linea de Comandos: Indicando las opciones de configuración al iniciar el servicio: mongod --dbpath /data/db --port 27017 --logpath file.log --logappend --fork Opciones Descripción --config Indica el path del fichero de configuración a utilizar. --dbpath Indica el path donde se almacenan los ficheros de la base de datos. --port Indica el puerto por el cual va a escuchar la instancia. --logpath Indica el path donde se almacena el fichero de log de la instancia. --logappend Si es true, no sobrescribe el fichero de log si existe, añade entradas. --fork Habilita el modo daemon (el proceso se ejecuta en backgroud). --journal Habilita el journal (habilitado por defecto). --bind_ip Fuerza al servidor la IP por la cual recibirá las peticiones.
del fichero: /etc/mongod.conf Debemos tener en cuenta que usa formato YAML (no soporta tabulación). Dicho fichero de configuración es utilizado por el script de inicio del servicio /etc/init.d/mongod.
Comando Función db.help() Muestra los comandos disponibles y su descripción db.copyDatabase(fromdb, todb, fromhost) Copia una base de datos incluso desde un host remoto. db.currentOp() Muestra las operaciones ejecutándose actualmente en la DB. db.dropDatabase() Elimina una base de datos. db.hostInfo() Muestra la información del servidor donde se aloja MongoDB. db.killOp(opid) Mata el proceso de la operación indicada. db.repairDatabase() Repara la base de datos en la que estamos ubicados. db.serverStatus() Devuelve un documento con el estado del servicio. db.shutdownServer(timeoutSecs) Detiene el proceso que tiene levantado el servicio. db.stats() Devuelve las estadísticas de la base de datos actual. db.version() Muestra la versión de MongoDB ejecutándose.
a través de múltiples servidores. ¿Qué aporta la replicación a nuestras BBDD? Redundancia / durabilidad. Alta disponibilidad Tipos de replicación: Replicación binaria Basada en “estado” MongoDB!!
Automatic failover Independencia de versiones Diferentes Storage Engines en miembros No hay downtime en actualizaciones ¿Cómo se gestiona en MongoDB? Miembros del Replica Set: Primary, Secondaries, Arbiter Máximo 50 miembros (v3.0+) Procesos mongod & parámetros de configuración Replica Set Oplog (async replication) Elections: Primary down (+10s) (automatic failover) New!! (v3.2) : “protocolVersion: 1” para acelerar la detección de múltiples primarios Máximo 7 miembros con derecho a voto
Replica Set Solo él recibe las escrituras y por defecto las lecturas Solo él garantiza la consistencia Mantiene el oplog a replicar En elecciones no existe primario, no se puede escribir Si no “ve” una mayoría de miembros se convierte en secundario En su proceso mongod se define el nombre del replica-set Puede invitar a nuevos miembros Establece la seguridad REPLICACIÓN (REPLICA SET)
una copia exacta de los datos del PRIMARY replicando su oplog asíncronamente. Pueden aceptar lecturas contemplando tolerancia a obsolescencia de datos Opciones del Driver cliente readConcern: “local” (primary), “majority” (eventual consistency) Query Read Preference: primary, primaryPreferred, secondary, secondaryPreferred, nearest (menor latencia) Tipos de miembros secundarios Sin derecho a voto { votes: 0 } Prioridad 0 { priority: 0 } Oculto { hidden: true, priority: 0 } Retardado { slaveDelay: nsecs }
mantiene copia de datos Requiere pocos recursos. Preferiblemente en máquina independiente (cloud - AWS) Tienen 1 voto en las elecciones Permiten mantener número impar de miembros No pueden convertirse en primarios en una elección Secundario especial { arbiterOnly: true } No debe ejecutarse en máquinas que ya incluyen primario o secundarios Tan solo intercambian votos, heartbeats y datos de configuración Antes de ser añadido necesita un --dbpath para iniciar mongod Minimizar con --nojournal y --smallfiles
Determinar un número impar de miembros Considerar “fault tolerance”: FT = members - majority Utilizar “hidden” o “delayed” members para funciones dedicadas Backup, reporting, analytics. Balancear la carga en entornos con excesivas lecturas Anticipar el aumento de capacidad a la demanda Utilizar journaling para protección ante fallos Sin journaling activo MongoDB no podrá recuperar datos ante desastres inexperados El mínimo recomendado son 3 miembros Distribuye geográficamente los miembros de una réplica
las réplicas secundarias determinan conjuntamente quién debe ser elegido como nuevo primario usando una implementación extendida del “Raft consensus algorithm” http://raft.github.io/ - http://thesecretlivesofdata.com/raft/ follower leader candidate election timeout heartbeat timeout
Fallo en el Primary → (v3.2) protocolVersion: 1, electionTimeoutMillis stepDown(sec) reconfig(conf) pérdida de quorum Elección de nuevo primario en MongoDB 1)El más actualizado 2)El de mayor prioridad 3)Menos de 10s detrás del primario, si excede queda inaccesible Rollback de primario Un rollback revierte las escrituras en un primario cuando retorna al replica-set después de un fallo. El rollback solo es necesario si el primario ha aceptado operaciones de escritura y no se han replicado correctamente en los secundarios antes de que quedara inaccesible
Almacena el documento de configuración del replica-set rs.initiate(), rs.conf(), rs.reconfig(), rs.status() local.oplog.rs Es la colección cíclica que almacena el oplog El tamaño por defecto es del 5% del espacio libre en disco Se puede cambiar mediante oplogSizeMB Si un miembro “cae” durante demasiado tiempo debe ser inicializado (re-sync) Cada operación en el oplog es idempotente Operaciones de actualización múltiple se desglosan en secundarios Oplog status helper rs.printReplicationInfo() Consultar lag desde el primario con rs.printSlaveReplicationInfo()
Concern Por defecto las operaciones de escritura solo se confirman desde el primario. Se puede cambiar en operaciones desde clientes db.products.insert( { item: "envelopes", qty : 100, type: "Clasp" }, { writeConcern: { w: 2, wtimeout: 5000 } } ) O en la configuración del replica set cfg = rs.conf() cfg.settings = {} cfg.settings.getLastErrorDefaults = { w: "majority", wtimeout: 5000 } rs.reconfig(cfg)
Preference Por defecto en un replica set las operaciones de lectura se realizan sobre el primario. Con readConcern “local” las lecturas del primario reflejan las últimas actualizaciones si no ha habido recuperación. Con readConcern “majority” las lecturas son del primario o secundarios con lo que se tiene consistencia eventual (solo v3.2 con WiredTiger). El driver de MongoDB soporta 5 modo en preferencia de lecturas: Primary PrimaryPreferred Secondary SecondaryPreferred Nearest La síntaxis depende del driver que se utilize (PHP, python, etc.) En el shell de mongo disponemos del método readPref en el cursor
rs.add(“host:port”) Añade un nuevo miembro al replica set con las siguientes opciones: { priority: n, votes: 1, se recomienda no modificar!! slaveDelay: n, artbiterOnly: true, hidden: true, tags: […] } rs.addArb(“host:port”) Añade un miembro “árbitro” al Replica Set rs.remove(“host:port”) Elimina un miembro del Replica Set rs.status() Muestra un documento con información de estado del Replica Set rs.conf() Muestra el documento con la configuración del Replica Set rs.reconfig(newConfig) Re-configura un Replica Set aplicando el nuevo objeto de configuración rs.isMaster() Indica qué miembro es el “primary” rs.stepDown(n) Convierte el primario en secundario forzando una elección rs.freeze(n) Previene que el miembro actual pueda ser elegido como primario rs.printReplicationInfo() Imprime informe de estado desde el punto de vista del primario rs.printSlaveReplicationInfo() Imprime informe de estado desde la perspectiva de un secundario rs.slaveOk() Habilita lecturas de secundarios. Deprecado. Ahora readPref() rs.syncFrom(“host:port”) Fuerza a obtener el oplog de otro miembro del Replica Set
los siguientes requisitos: Debe estar formado por: 5 miembros (majority=3, fault tolerance=2) 1 miembro árbitro Objetivos: Configurar e iniciar el Replica Set Forzar “down” y re-elección de Primario Cambiar la prioridad de un secundario Ocultar un secundario y reconfigurar Configurar secundario con sincronización retardada (20s)
método para almacenar datos a través de múltiples máquinas. ¿Por qué necesitamos Sharding? Almacenar grandes conjuntos de datos . Resolver operaciones que necesitan alto rendimiento. Escalado Vertical: + CPU + RAM Limitaciones Hardware + Storage Escalado Horizontal (Sharding): Divide el conjunto de datos y los distribuye a través de varios servidores, en lo se que denominan shards .
operaciones que cada shard maneja. Cada shard procesa menos operaciones a medida que el cluster crece. Reducir la cantidad de datos que el servidor tiene que almacenar. Cada shard almacena menos datos a medida que el cluster crece Aumento de la capacidad y del rendimiento HORIZONTALMENTE FRAGMENTACIÓN ( SHARDING)
nivel de colección. Las particiones de los datos de las colecciones viene determinada por la Shard Key. Shard Keys Campo muy importante, es vital seleccionar una Shard Key óptima. Debe ser el campo más común es las “queries” para una colección. Debe ser un Single Field Index o un Compound Index. Son inalterables y no se pueden cambiar después de realizar una inserción. Debe tener buena “cardinalidad” / “granularidad” (tener los suficientes valores para repartir la colección a través de los shards). FRAGMENTACIÓN ( SHARDING)
de cualquier campo del documento. Por defecto, todas las colecciones están indexadas por el campo “_id” Usuarios o Aplicaciones tienen la posibilidad de añadir nuevos índices. Los índices utilizados para el Sharding pueden ser: Single Field Indexes: FRAGMENTACIÓN ( SHARDING)
campos ( Límite 31 campos). Chunks No son datos físicos. Es una agrupación lógica de los rangos en los que dividimos los documentos de una colección, determinada por la Shard Key. FRAGMENTACIÓN ( SHARDING)
el conjunto de documentos de una colección en función de la Shard key , y distribuye cada trozo (chunk) en cada shard. Para realizar dicha división MongoDB tiene dos posibles métodos: Hash Based Sharding Range Based Sharding FRAGMENTACIÓN ( SHARDING)
determinado por los valores de la Shard Key. Cada rango (chunk), contiene un rango no superpuesto de valores de la Shard Key. Cuando un chunk crece por el encima del chunksize, MongoDB intenta dividir (split) el chunk, en chunks mas pequeños. FRAGMENTACIÓN ( SHARDING) Range Based Sharding
estos hashes para crear los chunks. Asegura una distribución aleatoria de una colección en el cluster. Dos documentos con el mismo valor de Shard Key, rara vez forman parte del mismo chunk. FRAGMENTACIÓN ( SHARDING) Hash Based Sharding
rango de consultas, dado que los datos suelen estar en el mismo chunk, y por lo tanto en el mismo shard. Las escrituras continuadas un mismo shard pueden provocar la sobrecarga del sistema. Distribución desigual de datos ( con Share Keys que aumentan su valor linealmente). Hash Based Sharding Distribución uniforme de los datos, dando lugar a escrituras más eficientes. Poco eficiente para rango de consultas, dado que los datos suelen estar repartidos por diferentes chunks, y por lo tanto en distintos shards. FRAGMENTACIÓN ( SHARDING)
datos o nuevos servidores (shards), puede dar lugar a una distribución no balanceada de los datos. MongoDB asegura en balanceo de los datos en el clúster con 2 procesos (background): Splitting Se realiza cuando un chunk sobrepasa el chunksize especificado (defecto 64MB), dividiendo el chunk a la mitad. Divide los metadatos, sin afectar a los datos ni a los shards. Habilitado por defecto (--noAutoSplit ) FRAGMENTACIÓN ( SHARDING)
≤ total chunks < 80 4 total chunks ≥ 80 8 FRAGMENTACIÓN ( SHARDING) Se realiza en los servidores mongos. Esta habilitada por defecto, aunque se puede deshabilitar, tanto globalmente, como a nivel de colección. Se realiza cuando la diferencia entre el número de chunks de dos shards sobrepasa un límite:
Cluster esta formado por: Shards: Almacenan los datos. Puede ser un Single Mongod o Replica Set(Producción). Query Routers: Encargada de dirigir las peticiones de los clientes a los shards, devolviendo el resultado a los clientes posteriormente. Config Servers: Almacenan los metadatos del cluster, así como la localización de los datos en cada shard. Version 3.2 Replica Set (Wired Tigger) FRAGMENTACIÓN ( SHARDING)
que contiene todas las colecciones que no has sido fragmentadas. Es Posible cambiar el “Primary Shard” de una base de datos (movePrimary). El proceso de migración puede necesitar un tiempo elevando y no es recomendable acceder a las colecciones hasta que el proceso haya finalizado. FRAGMENTACIÓN ( SHARDING) ¿ Como realiza MongoDB la implementación del Sharding ?.
administración del Sharded Cluster? Comando Función sh.addShard(<host:port>) Añade un host (Primary of ReplSet) al Sharded Cluster sh.enableSharding(<dbname>) Habilita el Sharding para una base de datos sh.shardCollection(<fullName, key, unique>) Añade un colección al Sharded Cluster sh.status() Devuelve un resumen del estado del Sharded Cluster sh.moveChunk(<fullName, find, to>) Migra un chunk a otro Shard sh.splitFind(<fullName, find>) Divide un chunk a la mitad basándose en una Query sh.splitAlt(<fullname, key>) Divide un chunk en 2 basándose en una ShardKey sh.stopBalancer() Detiene el balanceador globalmente (mongos) sh.startBalancer() Inicia el balanceador globalmente (mongos) sh.BalancerState() Devuelve si el balanceador está habilitado sh.isBalancerRunning() Devuelve “true” si el balanceador está migrando chunks sh.disableBalancing(<coll>) Deshabilita el balanceo en un colección sh.enableBalancing(<coll>) Habilita el balanceo en un colección
Nuestro Sharded Cluster va a estar formado por: 3 Shards (ReplSet) 1 Config Servers (ReplSet) 2 Mongos Vamos a configurar la resolución de nombres local (evitar localhost): echo “10.10.1.6 juc01 juc01.local" >> /etc/hosts Creamos directorios donde se almacenaran los datos de cada servicio: mkdir -p /data/shard0/rs0 /data/shard0/rs1 /data/shard0/rs2 mkdir -p /data/shard1/rs0 /data/shard1/rs1 /data/shard1/rs2 mkdir -p /data/shard2/rs0 /data/shard2/rs1 /data/shard2/rs2 mkdir -p /data/cfg/rs0 /data/cfg/rs1 /data/cfg/rs2
Base de Datos y Habilitamos el Sharding use juc db.example.insert({x: 0, description: "Documento Testing"}) db.example.find() sh.status() sh.enableSharding("juc") 8. Añadimos la colección al Sharded Cluster sh.shardCollection("juc.example", {x:1}) db.example.createIndex({x:1}) sh.status() for (var i=0; i < 20000; i++) { db.example.insert({x: i, description: "Documento Testing"}) } sh.status() db.example.stats()
los siguientes requisitos: Debe estar formado por: 2 Shards (shard0 – shard1) 1 Config Servers (configrepl) 1 Mongos Incluir una base de datos llamada “practica”, que contendrá una colección llamada “inventario” con el siguiente documento inicial: { item: 0, details: { model: "Nexus 5“, manufacturer: “LG" } } Fragmentar la colección inventario, utilizando como Shared Key el campo “item”. Añadir otros 500.000 documentos a la colección (el campo item debe ser único).
environment” Bloqueo a nivel de red. Acceso restringido por clientes. Independiente a MongoDB 2) Autenticación MongoDB Ejecutar mongod y mongos con opciones --auth Control de acceso de clientes --keyFile Seguridad intra-cluster --bind_ip Fuerza en el servidor la IP por la cual recibirá las peticiones.
MongoDB? Usuario de aplicación, administrador, backups, monitoring. Autorización - ¿Qué puedes hacer en MongoDB? Operaciones CRUD, configurar la BD, configurar sharding, gestión de usuarios. Habilitar autenticación de Usuarios Iniciar mongod con –auth Especificar directiva “security.authorization = enabled” en el fichero de config. Credenciales de usuario/password, SCRAM-SHA-1 por defecto en v3.0+ Certificados “x.509“ LDAP, Kerberos (Enterprise!!) Habilitar autenticación Interna (Replica Set, Sharding) Mediante “keyFile” o certificados “x.509”
root, etc Roles customizados Definir roles de usuario en base a privilegios o roles pre-definidos Almacenamiento de usuarios En sharding se mantienen en el config server, no en los mongos Se almacenan en la colección system.users en BD admin Recomendaciones No exponer los servidores de BD a internet Buen diseño y configuración de AC Habilitar SSL. Utilizar ficheros SSL CA entre cliente y servidor Auditar la actividad del sistema (Enterprise!!) Encriptar los datos
Usuarios? Comando Función db.auth() Autentica un usuario en una base de datos db.createUser() Crea un nuevo usuario db.updateUser() Actualiza los datos de un usuario db.changeUserPassword() Cambia la clave de un usuario existente db.removeUser() Deprecado. Elimina un usuario de la base de datos db.dropAllUsers() Elimina todos los usuarios de una base de datos db.dropUser() Elimina solo un usuario especificado db.grantRolesToUser() Asigna un rol y sus privilegios a un usuario db.revokeRolesFromUser() Elimina un rol a un usuario db.getUser() Devuelve información sobre el usuario db.getUsers() Devuelve la información de todos los usuario de una bd
Crea un rol y especifica sus privilegios db.updateRole() Actualiza un rol personalizado db.dropRole() Elimina un rol personalizado db.dropAllRoles() Elimina todos los roles personalizados asociados a una bd db.grantPrivilegesToRole() Asigna privilegios a un rol personalizado db.revokePrivilegesFromRole() Elimina un privilegio de un rol personalizado db.grantRolesToRole() Asigna roles del que hereda un rol personalizado db.revokeRolesFromRole() Elimina roles heredados en un rol db.revokeRolesFromUser() Inicia el balanceador globalmente (mongos) db.getRole() Devuelve información sobre el rol db.getRoles() Devuelve información de todos los roles de una bd
Consideraciones: Configurar una instancia mongod con autenticación activada Configurar un Replica Set básico de 3 miembros con autenticación Objetivos: Crear nuevo usuario para acceso autenticado Comprobar control de autorización mediante asignación de Roles Crear Rol personalizado para acceso autorizado a colección Configurar un keyfile para autenticación a base de datos
una estrategia para realizar backups y restaurar los datos en caso de desastre, o perdida de datos. MongoDB propone las siguientes alternativas para dicho propósito: Estrategias de Backup basadas en Sistemas de Ficheros. Utilizando las utilidades de Mongodb. Uso de herramientas Enterprise: MongoDB Cloud Manager Backup Ops Manager Backup Software
Ficheros: Realizando snapshots si el sistema de fichero lo permite (LVM, EBS) Tener habilitado el journal y que resida en el mismo volumen lógico que los datos. En un Sharded Cluster, debemos deshabilitar el balanceador y realizar un snapshot de cada shard y config aprox. mismo tiempo. Si el sistema de ficheros no soporta snapshots, puedes copiar los datos directamente utilizando utilidades como cp, scp, rsync. No son compatibles “point in time recovery” para el Replica Set. Difícil gestión con Sharded Cluster grandes.
que lee los datos de una base de datos MongoDB y los vuelca en un fichero BSON (Alta fiabilidad). Excluye el contenido de la base de datos local. Solo captura los documentos de la base de datos, no incluye los índices. En sistemas con Replica Set se recomienda ejecutarlo con la opción --oplog, para registrar en el oplog, las operaciones que realiza mongodump. mongodump --db test --collection collection mongodump --host mongodb1.example.net --port 37017 --username user --password pass --out /opt/backup/mongodump-2016-02-04
datos con los datos del fichero BSON. Reconstruye los índices después de importar los datos. En sistemas con Replica Set se recomienda ejecutarlo con la opción --oplogRelay. mongorestore --host mongodb1.example.net --port 37017 --username user --password pass /opt/backup/mongodump-2016-02-04 mongodump y mongorestore son simples y eficientes para despliegues pequeños de MongoDB, pero pueden dar problemas con grandes entornos con Replica Set o Sharding.
monitorización que proporciona un panel de control con estadísticas, gráficas, etc Mongoowl - http://mongoowl.citsoft.net/ Herramienta de monitorización en tiempo real y visualización gráfica basada en DHTML Robomongo - http://robomongo.org/ Herramienta open source de gestión de MongoDB orientada a Shell Mongo Management Studio - Community Edition http://www.litixsoft.de/english/mms Consola de gestión para MongoDB con un interface claro y ligero. Puedes ejecutar los comandos típicos de MongoDB sin necesidad de utilizar MongoDB shell Edda – http://goo.gl/bck5fp Script python que trata ficheros log de MongoDB como entrada y genera un timeline gráfico de eventos en un Replica Set REFERENCIAS Y ENLACES DE INTERÉS
cetaciemat
ken5scal
negi111111
kazushi_ohata
shonansurvivors
salaboy
tohutohu
ohnoeight
uhyo
cyberagentdevelopers
tkikuchi
tubone24
abemii
notwaldorf
swwweet
keithpitt
csswizardry
kevinliebholz
lauravandoore
philhawksworth
bluesmoon
davidbonilla
jakevdp
morganepeng
mongodb
![Administración de MongoDB Raúl Bojo Romero <[email protected]> II Jornadas Técnicas](https://files.speakerdeck.com/presentations/90bee5f8062e482d973bac323e1e508e/slide_0.jpg){kind=link}
