In backup/restore tests, consider running resetPlacementHistory after sharded cluster comes up

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Storage Engines - Server Integration
    • SESI - 2026-02-10
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      In an automated restore, this happens through automation after the restore. Not resetting the placement history after the cluster comes up would mean that change streams won't work until a background cleaner task comes and sweeps the placement history, which by default could take a long time to happen.

      Simply running resetPlacementHistory (which takes no arguments) after the sharded cluster comes up will resolve this. This step should also be part of the manual restore process.

            Assignee:
            Unassigned
            Reporter:
            Ryan Berryhill
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: