Mongo db course administration

868 views

Published on

Curso de Admintri

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
868
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Un Shard pueden ser todos los registros de tu base de datos que tengan como letra inicial de nombre de usuario la A o A-D.
  • Con “tipico” me refiero a que la configuración de los servidores la ha creado alguien que no sabía como escala MongoDB respecto al numero de servidores con el que contamos. Lo normal sería que en vez de 4 fueran 6 servidores para que la replicación fuese perfecta. Con esta configuración, consigues un HA bastante robusto y ademas de eso se caiga el servidor que se caiga, nunca se quedará como maestro un arbitro. Los arbitros al tener el Oplog a 0, no almacenan base de datos, simplemente observan que si el servidor maestro esta caido, le convierten en esclavo hasta que vuelva a levantar, durante ese periodo de tiempo, un esclavo toma el role de maestro. Cuando un Maestro caido, se levanta, comienza a drenar los datos del actual maestro hasta que quedan sincronizados. Cuando terminan dicha sincronización es cuando el que ahora es Maestro pasa a ser esclavo y el que inicialmente había caído pasa a ser Maestro de nuevo.
  • Con “tipico” me refiero a que la configuración de los servidores la ha creado alguien que no sabía como escala MongoDB respecto al numero de servidores con el que contamos. Lo normal sería que en vez de 4 fueran 6 servidores para que la replicación fuese perfecta. Con esta configuración, consigues un HA bastante robusto y ademas de eso se caiga el servidor que se caiga, nunca se quedará como maestro un arbitro. Los arbitros al tener el Oplog a 0, no almacenan base de datos, simplemente observan que si el servidor maestro esta caido, le convierten en esclavo hasta que vuelva a levantar, durante ese periodo de tiempo, un esclavo toma el role de maestro. Cuando un Maestro caido, se levanta, comienza a drenar los datos del actual maestro hasta que quedan sincronizados. Cuando terminan dicha sincronización es cuando el que ahora es Maestro pasa a ser esclavo y el que inicialmente había caído pasa a ser Maestro de nuevo.
  • Con “tipico” me refiero a que la configuración de los servidores la ha creado alguien que no sabía como escala MongoDB respecto al numero de servidores con el que contamos. Lo normal sería que en vez de 4 fueran 6 servidores para que la replicación fuese perfecta. Con esta configuración, consigues un HA bastante robusto y ademas de eso se caiga el servidor que se caiga, nunca se quedará como maestro un arbitro. Los arbitros al tener el Oplog a 0, no almacenan base de datos, simplemente observan que si el servidor maestro esta caido, le convierten en esclavo hasta que vuelva a levantar, durante ese periodo de tiempo, un esclavo toma el role de maestro. Cuando un Maestro caido, se levanta, comienza a drenar los datos del actual maestro hasta que quedan sincronizados. Cuando terminan dicha sincronización es cuando el que ahora es Maestro pasa a ser esclavo y el que inicialmente había caído pasa a ser Maestro de nuevo.
  • Con “tipico” me refiero a que la configuración de los servidores la ha creado alguien que no sabía como escala MongoDB respecto al numero de servidores con el que contamos. Lo normal sería que en vez de 4 fueran 6 servidores para que la replicación fuese perfecta. Con esta configuración, consigues un HA bastante robusto y ademas de eso se caiga el servidor que se caiga, nunca se quedará como maestro un arbitro. Los arbitros al tener el Oplog a 0, no almacenan base de datos, simplemente observan que si el servidor maestro esta caido, le convierten en esclavo hasta que vuelva a levantar, durante ese periodo de tiempo, un esclavo toma el role de maestro. Cuando un Maestro caido, se levanta, comienza a drenar los datos del actual maestro hasta que quedan sincronizados. Cuando terminan dicha sincronización es cuando el que ahora es Maestro pasa a ser esclavo y el que inicialmente había caído pasa a ser Maestro de nuevo.
  • Mongo db course administration

    1. 1. Curso de Administración de
    2. 2. - 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
    3. 3. Elementos de un cluster
    4. 4. 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 replicaset con Shards, a mi parecer es el mas útil, versátil yescalable. (V1.6) Existe la modalidad Master-Slave, es similar a Mysql –(V1.2)
    5. 5. Elementos de un cluster Para el montaje de un Cluster hay que basar laconfiguración en estructuras de 3 servidores. Para poder configurar los demonios de configuración, esnecesario levantar 3, exactamente igual para los demoniosde bases de datos. Los árbitros son considerados demonios de bases dedatos, pero con el Oplog a 0, para que no “pesen” En cambio los enrutadores solo puede haber 1 en cadaservidor de aplicación
    6. 6. Tipos de ClusterExisten varios tipos de Cluster: Master-Slave Replica Set Replica Set + Shards El Master-Slave se basa en 1 demonio por servidor, esedemonio es o Maestro o esclavo, es muy simple Vamos centrarnos en el Replica Set y RS + Shards que esel mas complicado de configurar.
    7. 7. ShardsUn shard es un trozo de tu base de datos, extraído de lamisma 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
    8. 8. Replica Set Es el modo de replicación que usa el servidor, un replica setcontiene 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 servidoresPuedes meter en un RS tantos servidores como quieras (E.G)
    9. 9. RS + Sharding 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 enproducción
    10. 10. RS + Sharding
    11. 11. RS + ShardingEste 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
    12. 12. RS + Sharding 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 }Despues de esto ya tenemos 1 replica set configurado,vamos con las shards
    13. 13. RS + Sharding Despues de 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 }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
    14. 14. RS + ShardingTe 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" } );
    15. 15. File Based ConfigurationPara 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 → EnrutadorEsta no es la manera mas eficaz de levantar los demonios, ya que el comando es muy grande y puedes olvidar o omitir una parte importantePara 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
    16. 16. Ejemplos de archivos de ConfiguracionArchivo rudra_arbiter.conf → Arbitro Archivo agny_shard.conf → Demonio de Sharddbpath = /var/lib/mongo/rudra dbpath = /var/lib/mongo/agnylogpath = /var/log/mongo/rudra.log logpath = /var/log/mongo/agny.loglogappend = true logappend = truebind_ip = 10.25.144.38 bind_ip = 10.25.144.38port = 11000 port = 10000fork = true fork = truenohttpinterface = true nohttpinterface = trueshardsvr = true shardsvr = truereplSet = rudra replSet = agnyoplogSize = 1
    17. 17. Ejemplos de archivos de ConfiguracionArchivo config_server.conf → Demonio de Configuracion Archivo mongos_server.conf → Demonio de enrutamientodbpath = /var/lib/mongo/config logpath = /var/log/mongo/mongos.loglogpath = /var/log/mongo/config.log logappend = truelogappend = true port = 30000bind_ip = 10.25.144.39 fork = trueport = 20000 configdb = 10.25.144.38:20000,10.25.144.40:20000,10.25.144.39:20000configsvr = truefork = truenohttpinterface = true IMPORTANTE: El orden para levantar los demonios es el siguiente: Shard>Arbitros>Configurador>Enrutador
    18. 18. Configurando un Cluster... 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 datosPodemos usar ficheros o en su defecto levantar los servicios con los demonios unicamente
    19. 19. 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
    20. 20. Comandos de adminsitracion 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
    21. 21. Comandos para Replica Set 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
    22. 22. Comandos para Sharding 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
    23. 23. Comandos en generalMongotop 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 MongoDBsh.getBalancerState().pretty(): Muestra el estado del balanceador interno de MongoDB Mucha mas informacion aqui
    24. 24. Preguntas...
    25. 25. CreditosNombre: Juan Manuel ParrillaPuesto: Release Engineer en Telefonica I+D por AmarisContacto: juanmanuel.parrilla@amaris.comContacto Adicional: jmp.tid@gmail.comSkype: jmp_tidTwitter: @kerbeross

    ×