PDF de programación - Curso de Administración MongoDB

MASTER CLASS

Curso de Administración MongoDB


Juan Manuel Parrilla



Consultor de Amaris en Telefónica I+D

Release Engineer



* FUENTE DE DOCUMENTACIÓN :

2

ÍNDICE

Elementos básicos de un Clúster

Tipos de Clúster

Que es un Shard

Replica Set + Sharding

File Based configuration + Examples

Montaje y configuración del Clúster

Comandos para administración y estado

Preguntas







ELEMENTOS DE UN CLÚSTER

3

ELEMENTOS DE UN CLÚSTER

4

Para el montaje de un Clúster 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





5

TIPOS DE CLÚSTER

Existen varios tipos de Clúster:

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.

SHARDS

6

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



REPLICA SET

7

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)

RS + SHARDING

8

Al juntar estos 2 modos de configuración la cosa
se complica, requisitos:

Debe haber tantos RS como Shards haya en el clúster

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

9

RS + SHARDING

10

Este es un esquema típico de producción:

2 servidores de aplicación con un clúster 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

11

Tras Levantar los demonios Arbiter y Shard, nos conectamos a un nodo
de cada shard para configurar el replica set:


$ 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
}


Después de esto ya tenemos 1 replica set configurado, vamos con las
shards.

RS + SHARDING

12

Tras configurar el RS, tenemos que levantar los demonios
restantes, configurador y enrutador. Tras hacerlo nos conectamos
al enrutador, a la DB Admin:

$ 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 }


Ya sólo queda activar el sharding en la base de datos, o sino en
alguna colección en concreto que sepamos que va a ser la mas
concurrida y consultada


RS + SHARDING

13

Te conectas a la base de datos (siempre a través del Mongos):

mongo 10.25.144.39:30000

use globserv

#creas el índice

mongos> db.user.ensureIndex({"userName" : 1})





use admin

#levantas el sharding en globserv

mongos> db.runCommand( { enablesharding : "globserv" } );

FILE BASED CONFIGURATION

14

Para levantar los demonios de base de datos, lo habitual es poner
los parámetros 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 configuración

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 demonios, ya que el
comando es muy grande y puedes olvidar u 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á así:

mongod -f /path/to/conf_file ó mongos -f /path/to/conf_file





EJEMPLOS DE ARCHIVOS DE CONFIGURACIÓN

15

Archivo rudra_arbiter.conf → Arbitro

Archivo agny_shard.conf → Demonio de Shard

dbpath = /var/lib/mongo/rudra

dbpath = /var/lib/mongo/agny

logpath =

/var/log/mongo/rudra.log

logpath = /var/log/mongo/agny.log

logappend = true

bind_ip = 10.25.144.38

port = 11000

fork = true

nohttpinterface = true

shardsvr = true

replSet = rudra

oplogSize = 1

logappend = true

bind_ip = 10.25.144.38

port = 10000

fork = true

nohttpinterface = true

shardsvr = true

replSet = agny

EJEMPLOS DE ARCHIVOS DE CONFIGURACIÓN

16

Archivo config_server.conf → Demonio de

Archivo mongos_server.conf → Demonio de enrutamiento

Configuración

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

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

CONFIGURANDO UN CLÚSTER...

17

Configurar un clúster es relativamente sencillo si se hace en la
propia maquina, no debería llevar mas de 5 minutos.

Vamos a usar la siguiente configuración:

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 únicamente

CONFIGURANDO UN CLÚSTER...

18

Debemos tener en cuenta que la ip siempre será localhost, lo único
que va a variar es el puerto al que te conectas.

Los pasos son los siguientes:

Levantamos los demonios Shards y Árbitros

Nos conectamos a la base de datos

Configuramos el RS

Levantamos los demonios Configuradores y enrutadores

Nos conectamos al enrutador

Configuramos el Sharding y después shardeamos una DB



COMANDOS DE ADMINISTRACIÓN

19

Ahora solo faltan los comandos para ver el estado del sharding, el
estado del replica set y demás, en principio a no ser que lo estéis
configurando o haya algún problema, generalmente no
necesitareis dicha información pero aun no habiendo lentitud en la
DB no esta demás echarle un ojo

Depende que necesites consultar, será necesario que te conectes a
un demonio u a otro:

Si necesitas información 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 PARA REPLICA SET

20

rs.status(): Status del Replica Set

rs.conf(): Muestra la configuración 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 "congelación" antes de que el
secundario se haga primario

Existen mas aquí



COMANDOS PARA SHARDING

21

db.printShardingStatus(): Muestra la información 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
búsqueda

Los chunks por defecto ocupan 64 Mb, se puede modificar su
tamaño pero 10Gen no suele recomendarlo

COMANDOS EN GENERAL

22

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 información aquí



23

Preguntas?

Muchas Gracias por vuestra atención

24