[SERVER-1096] Size for capped collection Created: 06/May/10 Updated: 12/Jul/16 Resolved: 24/Sep/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | None |
| Fix Version/s: | 1.7.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Participants: | |||||
| Description |
|
Right now the size field of db.oplog.$main.stats() is always 0. This makes it impossible to tell how much data is there before it wraps, so you can't know if its large enough. }, Also, the timeDiff and timeDiffHours fields of db.getReplicationInfo() should probably use (time * (storageSize / size)) to have more accurate results early on. Example of the issue: |
| Comments |
| Comment by auto [ 24/Sep/10 ] |
|
Author: {'login': 'erh', 'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}Message: more obvious db.getReplicationInfo() before an oplog roll-over |
| Comment by Aaron Staple [ 10/Aug/10 ] |
|
Any thoughts on the timeDiff issue? |
| Comment by Aaron Staple [ 09/Aug/10 ] |
|
Is timeDiff supposed to represent the time diff for a full oplog? If so, maybe we should rename it (or add a new field with a clearer name). |
| Comment by auto [ 09/Aug/10 ] |
|
Author: {'login': 'astaple', 'name': 'Aaron', 'email': 'aaron@10gen.com'}Message: |