[SERVER-1565] mongostat and serverStatus() do not show proper stats on slave Created: 18/Aug/10  Updated: 12/Jul/16  Resolved: 09/Nov/10

Status: Closed
Project: Core Server
Component/s: Tools
Affects Version/s: 1.6.0
Fix Version/s: 1.7.3

Type: Bug Priority: Minor - P4
Reporter: Kenny Gorman Assignee: Eliot Horowitz (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Participants:

 Description   

If I run a workload against the primary, the replica does not show the proper stats for serverStatus() and thus mongostat. An insert to the primary then the same insert on the replica should show as an insert in serverStatus().



 Comments   
Comment by auto [ 09/Nov/10 ]

Author:

{'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: mongostat shows replicated ops SERVER-1565
/mongodb/mongo/commit/558cb4a9c8b71452e3a39ec6387efaa02cf5f02f

Comment by auto [ 09/Nov/10 ]

Author:

{'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: track replicated ops SERVER-1565
/mongodb/mongo/commit/7cc161c6a53144f90a612da5bf17118a9580b614

Comment by auto [ 15/Oct/10 ]

Author:

{'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}

Message: master/slave set info in mongostat part of SERVER-1565
http://github.com/mongodb/mongo/commit/069e56b8b311515492710ef3edca92ba22559143

Comment by Kenny Gorman [ 25/Aug/10 ]

I like that M | S flag, thats what I was thinking as well

Comment by Eliot Horowitz (Inactive) [ 25/Aug/10 ]

I would take that and make the opposite argument

I think you want to know if they're slave or master ops, and mongostat needs to tell you that.

I guess we could add a status field that would say M or S

Comment by Kenny Gorman [ 25/Aug/10 ]

Right, so if it switches then it continues to show stats in the same way. That is exactly why it makes sense to keep the same method of displaying queries/insert/update/deletes/etc no matter if it's slave or primary.

Comment by Eliot Horowitz (Inactive) [ 25/Aug/10 ]

They do because of things like replica sets where master/slave can switch.

The other options is having sep columns for insert, delete, update.

Can do something like we do for queue length

insert|update|delete

so its compact

Comment by Kenny Gorman [ 25/Aug/10 ]

I disagree. Here is why.

Applied ops won't distinguish between and insert an update or delete. So it will be hard to tell w/o looking on the primary what is going on. So having them show up distinct is helpful still. Tools don't have to make a decision about slave vs non-slave. They can just read the info as they would on a primary. Any queries are known to be from allowing slave reads. Since mongoDB does not allow multimaster replication, all insert/update/delete traffic is known to be from the oplog.

Comment by Eliot Horowitz (Inactive) [ 25/Aug/10 ]

I think a separate field for "repl applied ops" makes more sense.
then its clear what operations are real and what are coming from an oplog

Comment by Dwight Merriman [ 25/Aug/10 ]

tend to agree

not hard to change

eliot giving you this you know the mongostat code i take it? should go in maybe

void applyOperation_inlock(const BSONObj& op)

p.s in v2.x we should break out repl applications as a separate mongostat column

Generated at Thu Feb 08 02:57:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.