Loading...

XML

Word

Printable

JSON

Type: Improvement
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 5.0.10, 4.4.16, 4.2.22, 6.0.0-rc11, 6.1.0-rc0
Affects Version/s: 4.2.15
Component/s: None
Labels:
- sharding-slow-logging
- shardingemea-qw

Backwards Compatibility:
Fully Compatible
Backport Requested:

v6.0, v5.3, v5.0, v4.4, v4.2
Sprint:
Sharding EMEA 2022-06-13
Case:
Linked BF Score:
170
Story Points:
6
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

It appears to be expected behaviour that a metadata refresh initiated on a lagging secondary will be waiting for the replication to catch up to least the timestamp at which the refresh was triggered.

At this moment there is no way to infer from the messages produced by SH_REFR if a refresh was/is waiting for replication.

Can we please improve the logging detail in that regard?

Assignee:: Allison Easton
Reporter:: Dmitry Ryabtsev
Participants:: Allison Easton, Dmitry Ryabtsev, Githook User
Votes:: 0 Vote for this issue
Watchers:: 5 Start watching this issue

Created:: Aug 28 2021 12:03:05 AM UTC
Updated:: Oct 29 2023 09:49:07 PM UTC
Resolved:: Jun 08 2022 01:54:02 PM UTC
Confidence Status Last Update:: 07/Jun/22 8:47 AM

Details

Description

Attachments

Activity

People

Dates