mongodb-user
[Arriba] [Todas las Listas]

[no subject]

To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Subject:
From: Asya Kamsky <asya@xxxxxxxxxxx>
Date: Fri, 11 Sep 2015 00:41:17 -0700
Delivery-date: Fri, 11 Sep 2015 03:52:32 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=coqmEdwhitSURD8BJhooLrPZqQ5MEs2SyCJhQM8esNo=; b=xSNTEVtvoh1WzpFds8cU4w4V9hAlBdL+5WLfuj31Xy7EQ7POe6hU3cOD0x0+PAHzs6 iqqZxxyiDTVAm5xR55lJsxUhtuLlOwfI9XOi6eOTzPahBV3pSul+39JnKUmJeUSQIM15 4gSdnue7dRJUXFzfb05mTNmlMxA+aQhs7jqlh9k68aUVOJl+PyAXX0AhrUcKLUbg0XYc /gOaJgmX8i2/0wWfl62QOYvPh9PevYQ7KiHzfojjMrg0/woer995T6d352yqk390/FDW cQjVgNPyMSpK/ZEDHQzY0nmY8/65+XQpVDU8IazNDFSOOqtmQ3MpXuvHhiZb1ts0oDo4 zcOg==
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mongodb.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:sender:list-subscribe :list-unsubscribe; bh=coqmEdwhitSURD8BJhooLrPZqQ5MEs2SyCJhQM8esNo=; b=TjV7FBfsCzHWshp5EBYpxRJtOztoD3XvkgnLk//0h1xZ+pdYEAJeJ8BbJb8qzMzi1h qA1QcUq3txe6hcQVDoXQynMHuZ8gPNHr3UPaPWHlMireLVxcuYbMVyM0Bkm2oSzULXqQ cGhouSd/beiXDBwlrJ8VNp0YV9CTm5opmQ52s=
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <51aa6800-068d-4292-9b73-eb5cf17bf326@googlegroups.com>
List-archive: <http://groups.google.com/group/mongodb-use>
List-help: <http://groups.google.com/support/>, <mailto:mongodb-user+help@googlegroups.com>
List-id: <mongodb-user.googlegroups.com>
List-post: <http://groups.google.com/group/mongodb-user/post>, <mailto:mongodb-user@googlegroups.com>
List-subscribe: <http://groups.google.com/group/mongodb-user/subscribe>, <mailto:mongodb-user+subscribe@googlegroups.com>
List-unsubscribe: <mailto:googlegroups-manage+1044811755470+unsubscribe@googlegroups.com>, <http://groups.google.com/group/mongodb-user/subscribe>
Mailing-list: list mongodb-user@xxxxxxxxxxxxxxxx; contact mongodb-user+owners@xxxxxxxxxxxxxxxx
References: <6aed493d-b684-49e0-ab57-5a6832c3680e@googlegroups.com> <83ef9f60-8f6b-4a9f-96cd-0eb7bd78695a@googlegroups.com> <425d9972-32c2-4426-ae83-16adf65f9aff@googlegroups.com> <50127ebc-730c-4f7c-b4e0-0d9f770f5dfa@googlegroups.com> <85e254c9-0fd4-49a5-acd0-9c774ecb00ed@googlegroups.com> <CAOe6dJDaYs+To5T3YQKiZ==kSjBQxN9Rv4OPBTP7U6Z34h41Ug@mail.gmail.com> <51aa6800-068d-4292-9b73-eb5cf17bf326@googlegroups.com>
Reply-to: mongodb-user@xxxxxxxxxxxxxxxx
Sender: mongodb-user@xxxxxxxxxxxxxxxx
Esto fuertemente sugiere un asunto con *underlying *storage capa - si el archivo
en disco consigue *corrupt no hay cualquier manera *journaling puede ayudar.

Desde esto es *YCSB dato puedes justo *wipe fuera del directorio y *repopulate
- que sería mi sugerencia pero yo  *verify el sistema de archivo primero.

*Asya


En *Thu, *Sep 10, 2015 en 2:00 PM, *prasad2019 <*prasad212019@*xxxxxxxxx> escribió:

> *Hi  *Aysa,
>
>    *Thanks realicé que también después del par de CPU de sistema de las pruebas era justo
> 15% así que abundancia de habitación, era el IO que conseguía *maxed fuera de (450MB
> /*Sec Escribe) durante carga de Dato, para confirmar esto estoy planeando añadir
> discos adicionales para realizar el beneficio de *Batchsize de *default 1 para ver
> si estas ayudas en ayudas crecientes para el dato que carga.
>
> Bien ahora estoy encontrando *checksum error en uno del *datafile, *Beacuse
> de este primario *MongoDB accidentes de caso y dos *replicas no está cogiendo
> arriba de con el primario.  Incluso después de primario retoma esperar con *Journaling encima,
> corregirá ninguna necesidad de correr "Reparación *Database" orden.
>
> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (0)
> [1441911825:678595][11777:0*x7*f7#uno6*aa06700],
> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo: leído *checksum
> error para 32768*B bloque en *offset 24421470208: bloque calculado *checksum de 179228071
> no empareja esperado *checksum de 2102742815"
> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (0)
> [1441911825:678683][11777:0*x7*f7#uno6*aa06700],
> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo:
> colección-12--8249752617800779708.*wt: Encontrado un formato de archivo ilegal
> o valor interno"
> "2015-09-10*T13:03:45.678-0600 *E *STORAGE  [*conn47] *WiredTiger (-31804)
> [1441911825:678705][11777:0*x7*f7#uno6*aa06700],
> archivo:colección-12--8249752617800779708.*wt, *cursor.Próximo: el proceso tiene que
> salir y retomar: PÁNICO_de WT: *WiredTiger pánico de biblioteca"
>
> te #Poder complacer ayudarme cómo  recupero este bloque *checksum error, es
> allí orden de reparación del bloque que puedo utilizar?
>
>
> *Thanks
> 
>
>
>
> *Prasad En miércoles, septiembre 9, 2015 en 3:22:00 PM *UTC-7, *Asya *Kamsky escribió:
>>
>> *Hi *Prasad:
>>
>> Cuando *Rob señalado fuera de - puedes hacer el lote inserta en cualquier rama - de hecho,
>> el 10*gen-rama de laboratorios fue creada porque *YCSB parecido para tener ido muy
>> *dormant como proyecto, pero recientemente acontecían muy activos otra vez, fusionando
>> peticiones de atracción, sacando viejo *crufty material que no ha trabajado, y en general
>> *revitalizing el proyecto.   Tan desde *Rob ha entregado un número de las
>> mejoras similares a lo que creamos en la versión de laboratorios, es probablemente
>> mejor de utilizar el maestro para regular *YCSB probando.   Nuestro plan de plazo largo es
>> para utilizar nuestra rama propia para añadir alguna funcionalidad que falta en *YCSB -
>> habilidad de utilizar dato aquello es más realista (no aleatorio *byte corrientes), utilizando
>> índices secundarios, y consultas por índices secundarios, también cuando más
>> flexibilidad en tipo de lee y escribe.
>>
>> Cuándo originalmente añadimos el lote inserta era para reducir el tiempo toma a *wipe y *repopulate un grupo a entonces corrido alguna clase de mixto *workload.
>> Dependiendo en la configuración del grupo, *batching podría obtener *anywhere
>> de 2*x a 6*x en mi experiencia.   Pero cuánto obtienes fuertemente depende en
>> dónde el *bottleneck es para el documento solo inserta caso.  Si ya
>> estás escribiendo tanto cuando el *server puede escribir, entonces aquello es vuestro límite -
>> pero si el *server es *underloaded porque el atrás-y-adelante en la red
>> está retrasando cosas abajo, *batching puede ayudar mucho.
>>
>> Hope que ayudas,
>> *Asya
>>
>>
>> En Sentado, *Sep 5, 2015 en 3:58 PM, *prasad2019 <prasad...@xxxxxxxxx> escribió:
>>
>>> *Rob,
>>>
>>>  tengo 4 físico *servers cada cual con 28 Núcleos/256RAM de GB y SSD *Storage.
>>>   *MongoDB 3.0.6 con uno Primario y dos *replica conjunto y *YCSB  y *YCSB
>>> el cliente provocado de cuarto *server.
>>>
>>>  Otro punto interesante observé con *BatchSize=1  el *datadisk
>>> ubicación alrededor de 400MB por segundo escribe y *Log alrededor de 30 a 40MB cierra a 12
>>> a #15% Utilización de CPU con coherentemente 60*K *ops/*sec.
>>>
>>> Mientras que con *BatchSize=1 el *datadisk la ubicación escribe alrededor de 50  a 450MB
>>> por segundo y *Log alrededor de 10 a 20 CPU de MB 4 a #15% CPU y 15*K a 72*K
>>> *ops/*sec variación. *Bottomline *BatchSize Con 100 variación
>>>
>>> de rendimiento bastante parcela.
>>>
>>> Bien con respecto a *YCSB medida de documento 1*KB a 151 *bytes aquello es punto bueno yo
>>> amable de *overlooked. Intentará cambiar y comprobar.
>>>
>>>
>>> Finalmente te #poder complacer punto cómo para cambiar compresión y  no
>>> entendido *wipe fuera del dato significa cae el *default *database y cambiar la compresión
>>> y cargarlo otra vez.
>>>
>>>
>>>
>>> *Thanks
>>> 
>>>
>>>
>>> *Prasad En sábado, septiembre 5, 2015 en 8:34:26 SOY *UTC-7, *Rob *Moore escribió:
>>>>
>>>> En viernes, septiembre 4, 2015 en 6:53:29 PM *UTC-4, *prasad2019 escribió:
>>>>>
>>>>>   *Thanks para el *pointer, utilicé *BatchSize parámetro para *YCSB pruebas
>>>>> de carga y los resultados bajaron.
>>>>>
>>>>>
>>>>> Operaciones de Medida de los documentos/*Sec *YCSB Hilos *AverageLatency(nos)
>>>>> 95*thPercentileLatency(*ms) 99*thPercentileLatency(*ms)   Remarca 30
>>>>> Millones 61004 64 1036 0 1   *Batchsize=*Default 30 Millones 50119 64 1236
>>>>> 2 3   *Batchsize=100
>>>>>
>>>>
>>>> Puede describes vuestro *setup un poco mejor. Qué es el *MongoDB
>>>> configuración? Cuántos *servers? Dónde es el cliente en relación al
>>>> *servers? Qué versión de *MongoDB?
>>>>
>>>> En papel *batching en un más alto *latency el entorno tendría que mejorar
>>>> *throughput pero nunca vi el dato para probarlo. *Asya *blog No habla
>>>> sobre utilizarlo y la configuración para las charlas de característica sobre mejorar
>>>> la carga "" del *dataset no la carrera.
>>>>
>>>> También, para emparejar *Asya rendimiento necesitas hacer seguro tú *shrink el
>>>> *YCSB medida de documento del *default de 1*KB a 151 *bytes. En el *workload
>>>> conjunto de archivo/añade:
>>>>
>>>> *fieldcount=1
>>>> *fieldlength=100
>>>>
>>>>
>>>>
>>>>> yo también probado poniendo  Lee preferido a Primario
>>>>>  "*db.*getMongo().*setReadPref('*primaryPreferred')"   Y reemplazado  el
>>>>> *MongoDB archivo de Conductor de 3.0.2 a más tardío 3.0.3
>>>>>
>>>>
>>>> FYI - puedes poner la preferencia leída *via el *MongoDb *URI:
>>>>
>>>>
>>>> *http://*docs.*mongodb.*org/Conexión/de referencia/manual-la cadena/#leída-preferencia-opciones
>>>>
>>>>
>>>>
>>>>> “ *log_leyó: *Compressed registro con ningún configurado *compressor: ERROR_de WT:
>>>>> no-específico *WiredTiger error”
>>>>>
>>>>
>>>> sospecho que cambiando la compresión te requerirá a *wipe de los
>>>> archivos de dato.
>>>>
>>>>
>>>> --
>>> Recibiste este mensaje porque eres *subscribed al *Google
>>> Grupos "*mongodb-grupo"
>>> de usuario.
>>>
>>> Para otro *MongoDB opciones de apoyo técnico, ve:
>>> *http://www.mongodb.org/sobre/apoyo/.
>>> ---
>>> Recibiste este mensaje porque eres *subscribed al *Google
>>> Grupos "*mongodb-grupo" de usuario.
>>> A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar
>>> un *email a *mongodb-user...@xxxxxxxxxxxxxxxx.
>>> A correo a este grupo, envía *email a mongod...@xxxxxxxxxxxxxxxx.
>>> Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
>>> Para ver esta discusión en la visita de web
>>> *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/85*e254*c9-0*fd4-49#uno5-*acd0-9*c774*ecb00*ed%40*googlegroups.*com
>>> <*https://Grupos.*google.*com/*d/*msgid/*mongodb-Usuario/85*e254*c9-0*fd4-49#uno5-*acd0-9*c774*ecb00*ed%40*googlegroups.*com?*utm_Medio=*email&*utm_fuente=*footer>
>>> .
>>>
>>> Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
>>>
>>
>> --
> Recibiste este mensaje porque eres *subscribed al *Google Grupos
> "*mongodb-grupo"
> de usuario.
>
> Para otro *MongoDB opciones de apoyo técnico, ve:
> *http://www.mongodb.org/sobre/apoyo/.
> ---
> Recibiste este mensaje porque eres *subscribed al *Google Grupos
> "*mongodb-grupo" de usuario.
> A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un
> *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
> A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
> Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
> Para ver esta discusión en la visita de web
> *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/51*aa6800-068*d-4292-9*b73-*eb5*cf17*bf326%40*googlegroups.*com
> <*https://Grupos.*google.*com/*d/*msgid/*mongodb-Usuario/51*aa6800-068*d-4292-9*b73-*eb5*cf17*bf326%40*googlegroups.*com?*utm_Medio=*email&*utm_fuente=*footer>
> .
>
> Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
>

-- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo"
de usuario.

Para otro *MongoDB opciones de apoyo técnico, ve: *http://www.mongodb.org/sobre/apoyo/.
--- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo" de usuario.
A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
Visita este grupo en *http://grupos.*google.*com/Grupo/*mongodb-usuario.
Para ver esta discusión en la visita de web *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/*CAOe6*dJBa7*Oni1*U%2*B9*wcrGMWvWUCyOx_*Syn8*eev-*zN09*pcoUp%3*DMw%40correo.*gmail.*com.
Para más opciones, visita *https://grupos.*google.*com/*d/*optout.
This strongly suggests an issue with underlying storage layer - if the file
on disk gets corrupt there isn't any way journaling can help.

Since this is YCSB data you can just wipe out the directory and repopulate
- that would be my suggestion but I would verify the file system first.

Asya


On Thu, Sep 10, 2015 at 2:00 PM, prasad2019 <prasad212019@xxxxxxxxx> wrote:

> Hi  Aysa,
>
>    Thanks I realized that too after couple of tests system CPU was just
> 15% so plenty of room, it was the IO which was getting maxed out (450MB
> /Sec Writes) during Data load, To confirm this I am planning to add
> additional disks to realize the benefit of Batchsize from default 1 to see
> if this helps in increasing helps for data loading.
>
> Well now I am encountering checksum error on one of the datafile, Beacuse
> of this primary MongoDB instance crashes and two replicas are not catching
> up with the primary.  Even after primary restart hoping with Journaling on,
> it will correct no need to run "Repair Database" command.
>
> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (0)
> [1441911825:678595][11777:0x7f7a6aa06700],
> file:collection-12--8249752617800779708.wt, cursor.next: read checksum
> error for 32768B block at offset 24421470208: calculated block checksum of
> 179228071 doesn't match expected checksum of 2102742815"
> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (0)
> [1441911825:678683][11777:0x7f7a6aa06700],
> file:collection-12--8249752617800779708.wt, cursor.next:
> collection-12--8249752617800779708.wt: encountered an illegal file format
> or internal value"
> "2015-09-10T13:03:45.678-0600 E STORAGE  [conn47] WiredTiger (-31804)
> [1441911825:678705][11777:0x7f7a6aa06700],
> file:collection-12--8249752617800779708.wt, cursor.next: the process must
> exit and restart: WT_PANIC: WiredTiger library panic"
>
> Can you please help me how do I recover this block checksum error, is
> there block repair command that I can use?
>
>
> Thanks
> Prasad
>
>
>
> On Wednesday, September 9, 2015 at 3:22:00 PM UTC-7, Asya Kamsky wrote:
>>
>> Hi Prasad:
>>
>> As Rob pointed out - you can do batch inserts on either branch - in fact,
>> the 10gen-labs branch was created because YCSB seemed to have gone very
>> dormant as a project, but recently they became very active again, merging
>> pull requests, removing old crufty stuff that hasn't worked, and in general
>> revitalizing the project.   So since Rob has submitted a number of
>> improvements similar to what we created in the labs version, it's probably
>> better to use the master for regular YCSB testing.   Our long term plan is
>> to use our own branch to add some functionality that is missing in YCSB -
>> ability to use data that's more realistic (not random byte streams), using
>> secondary indexes, and queries by secondary indexes, as well as more
>> flexibility in types of reads and writes.
>>
>> When we originally added batch inserts it was to reduce the time it takes
>> to wipe and repopulate a cluster to then run some sort of mixed workload.
>> Depending on the configuration of the cluster, batching could gain anywhere
>> from 2x to 6x in my experience.   But how much you gain heavily depends on
>> where the bottleneck is for the single document insert case.  If you're
>> already writing as much as the server can write, then that's your limit -
>> but if the server is underloaded because the back-and-forth on the network
>> is slowing things down, batching can help hugely.
>>
>> Hope that helps,
>> Asya
>>
>>
>> On Sat, Sep 5, 2015 at 3:58 PM, prasad2019 <prasad...@xxxxxxxxx> wrote:
>>
>>> Rob,
>>>
>>>  I have 4 physical servers each with 28 Cores/256GB RAM and SSD Storage.
>>>   MongoDB 3.0.6 with one Primary and two replica set and YCSB  and YCSB
>>> client triggered from fourth server.
>>>
>>>  Another interesting point I observed with BatchSize=1  the datadisk
>>> location around 400MB per second writes and Log around 30 to 40MB close to
>>> 12 to 15% CPU Utilization with consistently 60K ops/sec.
>>>
>>> Whereas with BatchSize=1 the datadisk location writes around  50 to
>>> 450MB per second and Log around 10 to 20 MB CPU 4 to 15% CPU and 15K to 72K
>>> ops/sec variation. Bottomline BatchSize with 100 performance
>>>
>>> variation quite lot.
>>>
>>> Well regarding YCSB document size 1KB to 151 bytes that's good point I
>>> kind of overlooked. Will try to change and check out.
>>>
>>>
>>> Finally can you please point how to switch compression and didn't
>>> understood wipe out data means drop the default database and change the
>>> compression and load it again.
>>>
>>>
>>>
>>> Thanks
>>> Prasad
>>>
>>>
>>> On Saturday, September 5, 2015 at 8:34:26 AM UTC-7, Rob Moore wrote:
>>>>
>>>> On Friday, September 4, 2015 at 6:53:29 PM UTC-4, prasad2019 wrote:
>>>>>
>>>>>   Thanks for the pointer, I did used BatchSize parameter for YCSB load
>>>>> tests and results went down.
>>>>>
>>>>>
>>>>> Documents Size Operations/Sec YCSB Threads AverageLatency(us)
>>>>> 95thPercentileLatency(ms) 99thPercentileLatency(ms)   Remarks 30
>>>>> Million 61004 64 1036 0 1   Batchsize=Default 30 Million 50119 64 1236
>>>>> 2 3   Batchsize=100
>>>>>
>>>>
>>>> Can you describe your setup a little bit better. What is the MongoDB
>>>> configuration? How many servers? Where is the client in relation to the
>>>> servers? What version of MongoDB?
>>>>
>>>> On paper batching in a higher latency environment should improve
>>>> throughput but I never saw the data to prove it. Asya's blog does not talk
>>>> about using it and the configuration for the feature talks about improving
>>>> the "load" of the dataset not the run.
>>>>
>>>> Also, to match Asya's performance you need to make sure you shrink the
>>>> YCSB document size from the default of ~1KB to 151 bytes. In the workload
>>>> file set/add:
>>>>
>>>> fieldcount=1
>>>> fieldlength=100
>>>>
>>>>
>>>>
>>>>> I also tried setting  Read preferred to Primary
>>>>>  "db.getMongo().setReadPref('primaryPreferred')"   and  replaced the
>>>>> MongoDB Driver file from 3.0.2 to latest 3.0.3
>>>>>
>>>>
>>>> FYI - You can set the read preference via the MongoDb URI:
>>>>
>>>>
>>>> http://docs.mongodb.org/manual/reference/connection-string/#read-preference-options
>>>>
>>>>
>>>>
>>>>> “ log_read: Compressed record with no configured compressor: WT_ERROR:
>>>>> non-specific WiredTiger error”
>>>>>
>>>>
>>>> I suspect that switching compression will require you to wipe of the
>>>> data files.
>>>>
>>>>
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mongodb-user"
>>> group.
>>>
>>> For other MongoDB technical support options, see:
>>> http://www.mongodb.org/about/support/.
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "mongodb-user" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mongodb-user...@xxxxxxxxxxxxxxxx.
>>> To post to this group, send email to mongod...@xxxxxxxxxxxxxxxx.
>>> Visit this group at http://groups.google.com/group/mongodb-user.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/mongodb-user/85e254c9-0fd4-49a5-acd0-9c774ecb00ed%40googlegroups.com
>>> <https://groups.google.com/d/msgid/mongodb-user/85e254c9-0fd4-49a5-acd0-9c774ecb00ed%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user"
> group.
>
> For other MongoDB technical support options, see:
> http://www.mongodb.org/about/support/.
> ---
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
> To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
> Visit this group at http://groups.google.com/group/mongodb-user.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mongodb-user/51aa6800-068d-4292-9b73-eb5cf17bf326%40googlegroups.com
> <https://groups.google.com/d/msgid/mongodb-user/51aa6800-068d-4292-9b73-eb5cf17bf326%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAOe6dJBa7Oni1U%2B9wcrGMWvWUCyOx_Syn8eev-zN09pcoUp%3DMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
<Anterior por Tema] Tema Actual [Siguiente por Tema>