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)


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


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


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


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



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

Mongo db course administration

Technology

Transcript of Mongo db course administration