REDUNDANCIA PARA VOTING DISK

Si decides almacenar el fichero de voting disk en el mismo diskgroup de ASM que los ficheros de datos, añadir un grupo de fallo puede suponer añadir un montón de espacio y puede que esto suponga un problema. Para solucionar esto, se introduce un nuevo grupo de fallo tipo quorum. Cuando se añade este tipo de grupo, solamente se utiliza para añadir una copia extra de voting dik en ese grupo de fallo, lo cual permite que este disco sea mucho menor al resto que compone el grupo.

Generaríamos el disckgroup de esta manera, siendo FG1 y FG2 del mismo tamaño y FG3 mucho menor ya que solo va almacenar el voting disk.

CREATE DISKGROUP PRUEBA NORMAL REDUNDANCY
FAILGROUP FG1 DISK 'ORCL:PRUEBA01' NAME PRUEBA01
FAILGROUP FG2 DISK 'ORCL: PRUEBA02' NAME PRUEBA02
QUORUM FAILGROUP FG3 DISK 'ORCL: PRUEBA03' NAME PRUEBA03
ATTRIBUTE 'compatible.asm' = '11.2';

Precalentar colecciones en memoría

Prueba para cargar en memoria los ficheros en mongodb con wiretiger. Con wiretiger desaparece la opción de touch y como ya comentamos en post anteriores se puede copiar en memoria los ficheros.

https://cajondesastreoracle.wordpress.com/2016/07/30/precargando-los-datos-en-memoria-en-mongodb/

Queríamos hacer la prueba de que mejor suponía cargar los ficheros en memoria al reinicio de la máquina. Y se nos ocurrió hacer la siguiente prueba. Crear un fichero que obtuviera un find de todos los _id de la colección. Desordenar todos los datos. Y hacemos tres consultas:

 

  1. Con todos los datos en memoria
  2. Reiniciando y sin precalentar las colecciones
  3. Reiniciando y precalentado las colecciones.

 

Estos son los resultados finales

Crear el fichero sessions.js

db = db.getSiblingDB('Prueba');

db.SESION.find({}).forEach(function (SESIONES) {

printjson("db. SESION.find({\"_id\": ObjectId(\"" + SESIONES._id + "\")})" );

})

 

Lo ejecutamos en la base de datos:

mongo xx.xx.xx.xx:27017/admin -u admin -p xxxx  sessions.js > sesiones.js

Le quitamos la primera y segunda linea que tienen la conexión a mongdb y le quitamos los \

cat sesiones.js | sed 's/^.\|.$//g' |  sed 's/\\//g' | sed '1d' | sed '1d'  >sesionesnew.js

Lo desodernamos

cat sesionesnew.js | sort -R > sesionesdesordenadas.js

Hacemos un split porque el fichero es demasiado grande. El fichero contenía 5000000 de líneas y lo dejamos en 5 ficheros de 1000000

wc -l sesionesdesordenadas.js
5238482 sesionesdesordenadas.js

split -l 1000000 sesionesdesordenadas.js

 

 

 

Busquedas tipo like en mongodb

A partir de mongodb 2.6 aparecen los índices tipo text que permiten hacer búsquedas tipo like. Hay que tener en cuenta que esto índices no indexaran algunas palabras dependiendo del idioma. Os adjunto un pequeño ejemplo:

Creamos la colección foo con dos documentos:

db.foo.insert({desc: "This is a string with text"});

db.foo.insert({desc:"This is a another string with Text"});

Creamos un indice sobre desc tipo text, sin especificar idioma.

db.foo.ensureIndex({"desc":"text"});

db.foo.getIndexes()

[

        {

                "v" : 1,

                "key" : {

                        "_id" : 1

                },

                "name" : "_id_",

                "ns" : "admin.foo"

        },

        {

                "v" : 1,

                "key" : {

                        "_fts" : "text",

                        "_ftsx" : 1

                },

                "name" : "desc_text",

                "ns" : "admin.foo",

                "weights" : {

                        "desc" : 1

                },

                "default_language" : "english",

                "language_override" : "language",

                "textIndexVersion" : 2

        }

]

Como vemos por defecto lo crea en ingles.

Hacemos algunas búsquedas, como vemos por las stop words no encontramos resultados:

db.foo.find({ $text:{ $search:"this" } });

db.foo.find({ $text:{ $search:"text" } });

{ "_id" : ObjectId("5810773579d890f4da883876"), "desc" : "This is a another string with Text" }

{ "_id" : ObjectId("5810772c79d890f4da883875"), "desc" : "This is a string with text"

Borramos el índice y lo recreamos para español

db.foo.dropIndex({ "_fts" : "text",

...                         "_ftsx" : 1})

{ "nIndexesWas" : 2, "ok" : 1 }

db.foo.ensureIndex({"desc":"text"}, { default_language: "spanish" })

{

        "createdCollectionAutomatically" : false,

        "numIndexesBefore" : 1,

        "numIndexesAfter" : 2,

        "ok" : 1

}

db.foo.find({ $text:{ $search:"is" } });

{ "_id" : ObjectId("5810773579d890f4da883876"), "desc" : "This is a another string with Text" }

{ "_id" : ObjectId("5810772c79d890f4da883875"), "desc" : "This is a string with text" }

db.foo.find({ $text:{ $search:"This" } });

{ "_id" : ObjectId("5810773579d890f4da883876"), "desc" : "This is a another string with Text" }

{ "_id" : ObjectId("5810772c79d890f4da883875"), "desc" : "This is a string with text" }

Al hacer las mismas búsquedas obtenemos resultados diferentes, porque las stop words dependen del idioma.

crs-1718: the css daemon is unable to continue due to a failure in required component gpnp.

Hoy instalando el grid de Oracle 12, nos hemos encontrado con un pequeño error:

crs-1718: the css daemon is unable to continue due to a failure in required component gpnp.

Mirando en con más detalle el los del css:

/opt/app/12.1.0/grid/log/hostname/cssd

Hemos visto que había un core del css

/opt/app/12.1.0/grid/log/cluster2-01/cssd

2016-10-24 11:30:29.054: [ default][1]Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running).

Normalmente esto se debe a un error de comunicación del interconect, o no está bien levantada la interfaz o hay un error en la interfaz indicada.

Alternativas para renombrar una base de datos en MongoDB

Tenemos varias opciones:

  1. Tenemos el comando copyDatabase, con autentificación hay que revisar bien los permisos del usuario con el que queremos hacer la copia, en la documentación explica con detalle los permisos necesarios dependiendo de la base base de datos.

 

https://docs.mongodb.com/v3.0/reference/method/db.copyDatabase/

  1. Tenemos la opción de hacer un mongodump y un mongorestore:
         $ mongodump -d old_db_name -o mongodump/

         $ mongorestore -d new_db_name mongodump/old_db_name

 

http://docs.mongodb.org/manual/tutorial/backup-with-mongodump/

 

  1. Luego podemos copiar colección a colección:
use admin   

db.runCommand({renameCollection: "[db_old_name].[collection_name]", to: "[db_new_name].[collection_name]"})

 

  1. O utilizar un el método agragate
db.oldCollection.aggregate([{$match: {}}, {$out: "newCollection"}])db.oldCollection.drop()

 

Precargando los datos en memoria en Mongodb

Tenemos varias opciones:

Touch: Solo válido para  l motor de almacenaje MMAPv1. No es compatible WiredTiger.

db.runCommand({ touch: "records", data: true, index: true })

Esto carga en memoria tanto los datos como los índices.

Cargar un índice especifico: En ocasiones no tenemos suficiente espacio en RAM para cargar todos los datos.

db.usuarios.find({}, {"_id" : 0, "clave" : 1, "fecha" : 1}). hint({"clave" : 1, "fecha" : 1}).explain()

 

Imaginemos que tienes un índice sobre el campo clave y fecha y queremos cargarlo en memoria. Con el comando explain forzaremos a mongod a iterar sobre todo el resultado. Se debe especificar que solo se quiere regresar los campos del índice (el segundo argumento del find) o cargaremos todos  los documentos en memoria.

Mover la base de datos a memoria: Se puede poner toda la base de datos en la RAM antes de iniciar mongo con el comando dd

     for file in /data/db/nombredb.*     

    >do    

    >dd if=$file of=/dev/null     

   > done

 

Esta técnica es buena si hay suficiente espacio en memoria para cargar los datos.