Mongo db course administration
-
Upload
juan-manuel-parrilla-madrid -
Category
Technology
-
view
473 -
download
3
description
Transcript of Mongo db course administration
Curso de Administración de
- Indice -
Elementos básicos de un Cluster
Tipos de Cluster
Que es un Shard
Replica Set + Sharding
File Based configuration + Examples
Montaje y configuración del Cluster
Comandos para administración y estado
Preguntas
Elementos de un cluster
Shards – DB Daemon
Arbiters – Supervisor
Configuration – “DNS” for Routing daemon
Routing – in App server, make query to cluster
Estos son los elementos básicos de un cluster en replica set con Shards, a mi parecer es el mas útil, versátil y escalable. (V1.6)
Existe la modalidad Master-Slave, es similar a Mysql – (V1.2)
Elementos de un cluster
Para el montaje de un Cluster hay que basar la configuración en estructuras de 3 servidores.
Para poder configurar los demonios de configuración, es necesario levantar 3, exactamente igual para los demonios de bases de datos.
Los árbitros son considerados demonios de bases de datos, pero con el Oplog a 0, para que no “pesen”
En cambio los enrutadores solo puede haber 1 en cada servidor de aplicación
Elementos de un cluster
Existen varios tipos de Cluster:
Master-Slave
Replica Set
Replica Set + Shards
El Master-Slave se basa en 1 demonio por servidor, ese demonio es o Maestro o esclavo, es muy simple
Vamos centrarnos en el Replica Set y RS + Shards que es el mas complicado de configurar.
Tipos de Cluster
Un shard es un trozo de tu base de datos, extraído de la misma con ciertos patrones de configuración.
Lo normal es que esto sea automático, pero si quieres hacer que el sharding tenga una distribución concreta tienes que configurar un Shard Key
Es importante matizar que tanto un Shard, como un arbitro, como un configurador tienen por ejecutable el demonio MONGOD
En cambio los enrutadores tiene con ejecutable el demonio MONGOS
Shards
Es el modo de replicación que usa el servidor, un replica set contiene un espejo de el servidor/es configurado como tal.
Por si solo es un método un poco peculiar de almacenar los datos, ya que todo esta en todos los servidores
Puedes meter en un RS tantos servidores como quieras (E.G)
Replica Set
Al juntar estos 2 modos de configuración la cosa se complica, requisitos:
Debe haber tantos RS como Shards haya en el cluster
Debe haber mínimo 3 demonios de DB por replica set
Con haber 3 demonios de configuración en general valdría
1 demonio enrutador por servidor de aplicación
Mínimo 1 arbitro por replica set
Esta es la configuración recomendada para un producto en producción
RS + Sharding
RS + Sharding
Este es un esquema típico de produccion:
2 servidores de aplicación con un cluster de 4 servidores de MongoDB
Lo he configurado de tal manera que haya 2/3 demonios por servidor
Portalmdb1 – 1 demonio de DB + 1 Arbitro
Portalmdb2 – 1 demonio de DB + 1 Config server
Portalmdb3 – 1 demonio de DB + 1 Config server + 1 Arbitro
Portalmdb4 – 1 demonio de DB + 1 Config server
Portalweb1-2 – 1 demonio enrutador por servidor de aplicación
RS + Sharding
Tras Levantar los demonios Arbiter y Shard, nos conectamos a un nodo de cada shard para configurar el replica set:
Despues de esto ya tenemos 1 replica set configurado,vamos con las shards
RS + Sharding
$ mongo 10.25.144.38:10000/admin> rs.initiate({"_id" : "agny", "members" : [... {"_id" : 0, "host" : "10.25.144.38:10000"},... {"_id" : 1, "host" : "10.25.144.39:10000"},... {"_id" : 2, "host" : "10.25.144.40:11000", arbiterOnly : true}]}){ "info" : "Config now saved locally. Should come online in about a minute.", "ok" : 1}
Despues de configurar el RS, tenemos que levantar los demonios restantes, configurador y enrutador. Tras hacerlo nos conectamos al enrutador, a la DB Admin:
Despues solo queda activar el sharding en la base de datos, o sino en alguna coleccion en concreto que sepamos que va a ser la mas concurrida y consultada
RS + Sharding
$ mongo 10.25.144.39:30000/admin
> db.runCommand({addshard : "agny/10.25.144.38:10000,10.25.144.39:10000"}){ "shardAdded" : "agny", "ok" : 1 }> db.runCommand({addshard : "rudra/10.25.144.40:10000,10.25.144.41:10000"}){ "shardAdded" : "rudra", "ok" : 1 }
Te conectas a la base de datos (siempre a través del Mongos):
mongo 10.25.144.39:30000
use globserv
#creas el indice
mongos> db.user.ensureIndex({"userName" : 1})
use admin
#levantas el sharding en globserv
mongos> db.runCommand( { enablesharding : "globserv" } );
RS + Sharding
Para levantar los demonios de base de datos, lo habitual es poner los parametros en el comando:
mongod --dbpath /var/lib/mongo/rudra --port 11000 --replSet rudra --oplogSize 1 → Arbitro
mongod --dbpath /var/lib/mongo/agny --port 10000 --replSet agny → Shard
mongod --dbpath /var/lib/mongo/config --port 20000 → Demonio de configuracion
mongos --configdb 10.25.144.39:20000,10.25.144.40:20000,10.25.144.41:20000 --port 30000 → Enrutador
Esta no es la manera mas eficaz de levantar los demonios, ya que el comando es muy grande y puedes olvidar o omitir una parte importante
Para mejorar esto vamos a usar archivos de configuración, lo cual lo hace mucho mas sencillo, ya que se levantará asi:
mongod -f /path/to/conf_file ó mongos -f /path/to/conf_file
File Based Configuration
Archivo rudra_arbiter.conf → Arbitro
dbpath = /var/lib/mongo/rudra
logpath = /var/log/mongo/rudra.log
logappend = true
bind_ip = 10.25.144.38
port = 11000
fork = true
nohttpinterface = true
shardsvr = true
replSet = rudra
oplogSize = 1
Archivo agny_shard.conf → Demonio de Shard
dbpath = /var/lib/mongo/agny
logpath = /var/log/mongo/agny.log
logappend = true
bind_ip = 10.25.144.38
port = 10000
fork = true
nohttpinterface = true
shardsvr = true
replSet = agny
Ejemplos de archivos de Configuracion
Archivo config_server.conf → Demonio de Configuracion
dbpath = /var/lib/mongo/config
logpath = /var/log/mongo/config.log
logappend = true
bind_ip = 10.25.144.39
port = 20000
configsvr = true
fork = true
nohttpinterface = true
Archivo mongos_server.conf → Demonio de enrutamiento
logpath = /var/log/mongo/mongos.log
logappend = true
port = 30000
fork = true
configdb = 10.25.144.38:20000,10.25.144.40:20000,10.25.144.39:20000
IMPORTANTE: El orden para levantar los demonios es el siguiente:
Shard>Arbitros>Configurador>Enrutador
Ejemplos de archivos de Configuracion
Ejemplos de archivos de Configuracion
Configurar un cluster es relativamente sencillo si se hace en la propia maquina, no debería llevar mas de 5 minutos.
Vamos a usar la siguiente configuracion:
1 enrutador
1 configurador
1 arbitro
2 Shards de base de datos
Podemos usar ficheros o en su defecto levantar los servicios con los demonios unicamente
Configurando un Cluster...
Hay que tener en cuenta que la ip siempre será localhost, lo unico que va a variar es el puerto al que te conectas.
Los pasos son los siguientes:
Levantamos los demonios Shards y Arbitros
Nos conectamos a la base de datos
Configuramos el RS
Levantamos los demonios Configuradores y enrutadores
Nos conectamos al enrutador
Configuramos el Sharding y despues shardeamos una DB
Configurando un Cluster...
Ahora solo faltan los comandos para ver el estado del sharding, el estado del replica set y demas, en principio a no ser que lo esteis configurando o haya algun problema, generalmente no necesitareis dicha información pero aun no habiendo lentitud en la DB no esta demas echarle un ojo
Depende que necesites consultar, será necesario que te conectes a un demonio u a otro:
Si necesitas informacion del estado del replica set, es necesario conectarse a lo Shard de DB
Si necesitas consultar el estado del sharding, te debes conectar al enrutador
Comandos de adminsitracion
rs.status(): Status del Replica Set
rs.conf(): Muestra la configuracion del replica set
rs.reconfig(): reconfigura el RS
rs.isMaster(): Muestra si el servidor al que te conectas es el primario o el secundario
rs.stepDown(): Obliga a un nodo primario a ser secundario
rs.freeze(): configura un tiempo de "congelacion" antes de que el secundario se haga primario
Existen mas aqui
Comandos para Replica Set
db.printShardingStatus(): Muestra la infotmacion del Sharding actual
sh.splitAt(): parte en 2 un chunk donde tu le indiques
sh.splitAt( "records.people", { "zipcode": 63109 }
sh.splitFind(): Busca los splits dentro de tu DB
No recomiendo realizar acciones de Split sin haberlas consultado antes con la gente de BE, ya que puede incrementar los tiempos de busqueda
Los chunks por defecto ocupan 64 Mb, se puede modificar su tamaño pero 10Gen no suele recomendarlo
Comandos para Sharding
Mongotop y Mongostat: Ambos dan información sobre el estado de la base de datos, (mongotop no esta en todas las versiones)
db.stats(): Datos sobre el estado de una DB dentro de MongoDB
sh.getBalancerState().pretty(): Muestra el estado del balanceador interno de MongoDB
Mucha mas informacion aqui
Comandos en general
Preguntas...
Creditos
Nombre: Juan Manuel Parrilla
Puesto: Release Engineer en Telefonica I+D por Amaris
Contacto: [email protected]
Contacto Adicional: [email protected]
Skype: jmp_tid
Twitter: @kerbeross