How to get the replication and durability status of a document

[cheetah]

Hi Mongo-ers,  

Suppose, I write a document to a collection:

db.col.write({...})

And then I can get to know the status of it by calling: 

getLastError( w:2, j:true).

My first question is:

Does this mean there are two mongod servers in the replica set writing this document into the journal? And does "writing into the journal"  means the journal is flushing to the disk or just writing to the journal in the memory?

My second question is if my client fails before calling getLastError. When the client restart, how can it knows the last document's  status? This question equals how does another client knows a document's replication/durability status?

Thanks a lot. 

Regards,

Wen

[Scott Hernandez]

On Thu, Jan 26, 2012 at 2:58 AM, cheetah <xuw...@gmail.com> wrote:
> Hi Mongo-ers,
>
> Suppose, I write a document to a collection:
> db.col.write({...})
> And then I can get to know the status of it by calling:
> getLastError( w:2, j:true).
>
> My first question is:
> Does this mean there are two mongod servers in the replica set writing this
> document into the journal? And does "writing into the journal"  means the
> journal is flushing to the disk or just writing to the journal in the
> memory?

The j is just for the primary and it does require a write to disk.

> My second question is if my client fails before calling getLastError. When
> the client restart, how can it knows the last document's  status? This
> question equals how does another client knows a document's
> replication/durability status?

Most drivers, really all, allow a Safe WriteConcern be passed during
the write operation (or set on the Mongo/Server/DB/Collection as a
default) which will do the getLastError call for you, within the write
operation. It is best not to do it manually as a second operation from
your code.

If you do a write but crash before you can process the response or the
client can handle the possible error/exception then you would need to
query to verify the write. This is no different than any other system
and comes with the same challenges.

>
> Thanks a lot.
>
> Regards,
> Wen
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.

[cheetah]

On Thu, Jan 26, 2012 at 5:16 AM, Scott Hernandez <scotthe...@gmail.com> wrote:

On Thu, Jan 26, 2012 at 2:58 AM, cheetah <xuw...@gmail.com> wrote:
> Hi Mongo-ers,
>
> Suppose, I write a document to a collection:
> db.col.write({...})
> And then I can get to know the status of it by calling:
> getLastError( w:2, j:true).
>
> My first question is:
> Does this mean there are two mongod servers in the replica set writing this
> document into the journal? And does "writing into the journal"  means the
> journal is flushing to the disk or just writing to the journal in the
> memory?

The j is just for the primary and it does require a write to disk.

Is there anyway to force the secondaries to write to journal? 

> My second question is if my client fails before calling getLastError. When
> the client restart, how can it knows the last document's  status? This
> question equals how does another client knows a document's
> replication/durability status?

Most drivers, really all, allow a Safe WriteConcern be passed during
the write operation (or set on the Mongo/Server/DB/Collection as a
default) which will do the getLastError call for you, within the write
operation. It is best not to do it manually as a second operation from
your code.

If you do a write but crash before you can process the response or the
client can handle the possible error/exception then you would need to
query to verify the write. This is no different than any other system
and comes with the same challenges.

Makes sense. Thanks.  

[Scott Hernandez]

On Thu, Jan 26, 2012 at 2:13 PM, cheetah <xuw...@gmail.com> wrote:
>
>
> On Thu, Jan 26, 2012 at 5:16 AM, Scott Hernandez <scotthe...@gmail.com>
> wrote:
>>
>> On Thu, Jan 26, 2012 at 2:58 AM, cheetah <xuw...@gmail.com> wrote:
>> > Hi Mongo-ers,
>> >
>> > Suppose, I write a document to a collection:
>> > db.col.write({...})
>> > And then I can get to know the status of it by calling:
>> > getLastError( w:2, j:true).
>> >
>> > My first question is:
>> > Does this mean there are two mongod servers in the replica set writing
>> > this
>> > document into the journal? And does "writing into the journal"  means
>> > the
>> > journal is flushing to the disk or just writing to the journal in the
>> > memory?
>> The j is just for the primary and it does require a write to disk.
>
> Is there anyway to force the secondaries to write to journal?

No, the general idea is for your replicas to be in geographically
disperse locations where the chance of a hardware/DC failure is much
less likely across all the replica.

[cheetah]

On Thu, Jan 26, 2012 at 12:36 PM, Scott Hernandez <scotthe...@gmail.com> wrote:

On Thu, Jan 26, 2012 at 2:13 PM, cheetah <xuw...@gmail.com> wrote:
>
>
> On Thu, Jan 26, 2012 at 5:16 AM, Scott Hernandez <scotthe...@gmail.com>
> wrote:
>>
>> On Thu, Jan 26, 2012 at 2:58 AM, cheetah <xuw...@gmail.com> wrote:
>> > Hi Mongo-ers,
>> >
>> > Suppose, I write a document to a collection:
>> > db.col.write({...})
>> > And then I can get to know the status of it by calling:
>> > getLastError( w:2, j:true).
>> >
>> > My first question is:
>> > Does this mean there are two mongod servers in the replica set writing
>> > this
>> > document into the journal? And does "writing into the journal"  means
>> > the
>> > journal is flushing to the disk or just writing to the journal in the
>> > memory?
>> The j is just for the primary and it does require a write to disk.
>
> Is there anyway to force the secondaries to write to journal?

No, the general idea is for your replicas to be in geographically
disperse locations where the chance of a hardware/DC failure is much
less likely across all the replica.

Yes, I understand this. But when users don't have geographically dispersed machines, this has a risk of losing data when the power is down for all machines in a replica set and the disk of the primary is corrupted, although this has a low probability. Will Mongo consider adding this write option (j:true, fsync: true) to the secondaries in the future?

[Scott Hernandez]

Yes; I believe there is a feature request for this but there hasn't
been much interest from the community/users since it is not a common
use case.