Details
-
Improvement
-
Resolution: Done
-
Major - P3
-
2.4.8
-
None
-
Minor Change
-
(copied to CRM)
Description
When a new clean node is being added to a replica set, if the source for initial sync has corrupted data, it seems that we try to sync whatever we can, silently ignoring all the records we can not fetch.
While this "best effort" behavior makes sense, it can lead to significant data inconsistency within the replica set. We should not ignore data access errors during initial sync.
example behavior (PRIMARY is the node with corruption in dummy.acl namespace, SECONDARY is the newly synced secondary):
X:SECONDARY> rs.slaveOk()
|
X:SECONDARY> use dummy
|
switched to db dummy
|
X:SECONDARY> db.acl.count()
|
101
|
X:SECONDARY> exit
|
bye
|
AD-MAC10G:ff alexander$ mongo
|
MongoDB shell version: 2.4.8
|
connecting to: test
|
X:PRIMARY> use dummy
|
switched to db dummy
|
X:PRIMARY> db.acl.count()
|
10002
|
X:PRIMARY> exit
|
bye
|
Attachments
Issue Links
- is duplicated by
-
SERVER-17903 When corruption detected, server continues to run and sync secondaries
-
- Closed
-
- is related to
-
DOCS-4315 Document that documents will be skipped in initial replSet sync if source has corrupt data
-
- Closed
-
-
SERVER-1558 Documents should write checksum on write, verify checksum on read
-
- Closed
-
- related to
-
SERVER-17903 When corruption detected, server continues to run and sync secondaries
-
- Closed
-