[DOCS-772] Documentation about what "t" and "i" fields mean in chunk to shard map Created: 19/Nov/12  Updated: 26/Nov/12  Resolved: 21/Nov/12

Status: Closed
Project: Documentation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Kevin Hanson Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 11 years, 13 weeks ago

 Description   

In a sharded cluster, curious what the "t" and "i" stand for. I couldn't find it... I'm a) curious what it stands for and b) think we should document it.

If I just can't find it because i'm looking in the wrong place, let me know - thanks!

Sample:
{ "_id" :

{ $minKey : 1 }

} -->>

{ "_id" : ObjectId("4e7bb4745fcc83a843000004") }

on : rs_14

{ "t" : 357000, "i" : 0 } { "_id" : ObjectId("4e7bb4745fcc83a843000004") }

-->>

{ "_id" : ObjectId("4e800098d0eab3b756000003") }

on : rs_18

{ "t" : 355000, "i" : 0 }

 Comments   
Comment by Kevin Hanson [ 21/Nov/12 ]

Got it - thanks, Scott. This customer has 30+ nodes in prod and is a pretty advanced user of MongoDB. He just wanted to know what those two fields meant, as we were exploring how chunks were migrating in a training class I was giving. He asked what those two fields meant, and I didn't know. Now I do.

Comment by Scott Hernandez (Inactive) [ 21/Nov/12 ]

...in the sharding chunk metadata this is the version marker where t = major and i = minor ...

I would suggest you get an engineer to talk to the customer as explaining sharding internals is something for an experienced person to do. While I think that documenting internals is generally a good thing, in this case we don't need to, nor should, as we will be changing how things work in the very near future.

We are working on defining how much of internal specs and design docs will be published (and which may become stale over time) and how much will be kept internal. In general most of this is all in jira, and of course all if it is in the code.

Comment by Kevin Hanson [ 21/Nov/12 ]

Also, it occurs to me that while your suggestion to take training was great, i didn't get an explicit definition about exactly what "t" and "i" were. I'm looking to get back to a customer on this.

Comment by Kevin Hanson [ 21/Nov/12 ]

Hi Scott,

Thanks for the suggestion on taking a training course. I looked at all the sharding presos I could find, and I didn't find one that reference those two specific fields. I also couldn't find any documentation on this on our website, hence my filing the ticket under "Documentation." If I'm incorrect, please point me to the right documentation. This was asked by a customer, and I think it would be nice to have this info available to them. Thanks!!!

-Kevin

Comment by Scott Hernandez (Inactive) [ 21/Nov/12 ]

Kevin, I would suggest taking the sharding training to learn how these are used, and how the internals work in more detail.

A quick summary is that is each chunk is versioned (when they are split or moved) and the max version across a namespace is kept on each member involved in a sharded cluster to invalid caches and make sure queries are not sent, nor data written, to the wrong shards.

Comment by Kevin Hanson [ 21/Nov/12 ]

Possible to get a bit more detail on this? Thanks!

Comment by Kevin Hanson [ 20/Nov/12 ]

Can I get a bit more clarity on "version marker?" Is it just that if i = 0, it indicates a minor version of MongoDB. And if flipped, it's a major version. And then if so, what does 355000 in the "t" field indicate? Which ints is it holding?

Comment by Scott Hernandez (Inactive) [ 19/Nov/12 ]

This is a Timestamp (type/value) where i = increment (counter) and t = time (sec since epoch UTC), but in the sharding chunk metadata this is the version marker where t = major and i = minor and has nothing to do with the Timestamp type really (except we use it to hold two ints).

Generated at Thu Feb 08 07:39:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.