-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Execution NAMR Team 2023-09-04
Any data migration protocol that applies oplog entries on inconsistent snapshot (i.e, not a stable recovery), then the following sequence could cause the data migration to fail with error ErrorCodes::commandNotSupportedOnView - Namespace <xxxx> is a view, not a collection
1) Sync source: Create a regular collection on nss db.coll at TS(100).
2) SyncTarget: Starts the logical cloning with beginApplyingTimestamp as TS(110).
3) Sync source: Inserts an entry into collection db.foo at TS(120).
4) Sync source: Drop collection db.foo at TS(130).
5) Sync Source: creates a view on dropped collection nss db.coll at TS(140).
6) SyncTarget: Database Cloner clones database 'db'. And, that results in copying db.system.views collection which would register the view on nss db.coll.
7) SyncTarget: Finishes cloning and starts applying the oplog entries from TS(110) to TS(140) to make the data consistent.
8) SyncTarget: Now, on trying to apply TS(120), the oplog applier will fail with CommandNotSupportedOnView.
To fix this issue, we should just ignore CommandNotSupportedOnView error for oplog application mode kInitialSync and for kUnstableRecovering. To be noted, both logical initial sync and tenant migration uses oplog application mode kInitialSync .
Note: I have attached a tenant migration repro for this bug.
- is depended on by
-
SERVER-79482 Tenant migration/merge and split passthrough should support timeseries workload.
- Closed
- is related to
-
SERVER-63129 Collection recreated on a dropped view namespace should be handled correctly on logical tenant collection cloner resume.
- Closed