[SERVER-53914] ReshardingCoordinator instances to load metrics state upon instantiation Created: 20/Jan/21  Updated: 06/Dec/22  Resolved: 02/Jun/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Lamont Nelson Assignee: [DO NOT USE] Backlog - Sharding NYC
Resolution: Won't Do Votes: 0
Labels: PM-234, PM-234-M3, PM-234-T-autocommits, sharding-nyc-subteam1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-66994 Complete TODO listed in SERVER-53914 Closed
Assigned Teams:
Sharding NYC
Sprint: Sharding 2021-07-12, Sharding 2021-07-26, Sharding 2021-08-09
Participants:

 Description   

Should instantiate ReshardingMetrics object with the persisted data

Tracked quantities in the ReshardingMetrics class:

  • runningOperation time interval (c)
  • ** opStatus (d, c, r) always set to running.
  • copyingDocuments time interval (r)
  • documentsToCopy (r)
  • documentsCopied (r)
  • bytesToCopy (r)
  • bytesCopied (r)
  • applyingOplogEntries time interval (r)
  • oplogEntriesFetched (r)
  • oplogEntriesApplied (r)
  • // inCriticalSection time interval (c)
  • // writesDuringCriticalSection (d)
  • donorState (d)
  • recipientState (r)
  • coordinatorState (c)

d = donor
r = recipient
c = coordinator



 Comments   
Comment by Max Hirschhorn [ 05/Aug/21 ]

Randolph had discovered that ReshardingMetrics::setCoordinatorState() is ever being called by the ReshardingCoordinator (SERVER-59038). I imagine we could have recovery update the tracked coordinatorState but figured I'd mention this issue with the current ReshardingCoordinator behavior in case it makes testing the changes odd.

Generated at Thu Feb 08 05:32:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.