[SERVER-8476] slaveDelay with Ghostsync Created: 08/Feb/13 Updated: 06/Dec/22 Resolved: 08/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.3.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Hiroaki | Assignee: | Backlog - Replication Team |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | sync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS6.2 x86_64 |
||
| Issue Links: |
|
||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
| Comments |
| Comment by Eric Milkie [ 08/Sep/16 ] | |||||||
|
This was implemented via | |||||||
| Comment by Hiroaki [ 01/Mar/13 ] | |||||||
|
Thanks, write concern can be good measure for me. I'll try it and wait proper fix. | |||||||
| Comment by Kristina Chodorow (Inactive) [ 20/Feb/13 ] | |||||||
|
Maybe mongod should go into recovering state if it's syncing from an "less preferable" node (slave delayed, behind, etc.). In the meantime, you might want to use write concern (e.g., w:2) to ensure a write has been replicated to the secondary. If getLastError returns a timeout, you can send subsequent reads to the primary. If it returns success, you know that the secondary is up-to-date. | |||||||
| Comment by Hiroaki [ 20/Feb/13 ] | |||||||
|
problem #1 is OK. This is merely messaging issue. problem #2: > In general, ... Even the application can tolerate stale reads. Of course, I read from Primary if necessary.
Reading 10 secs past data is different from reading 3600 secs past data unintentionally. I think, almost all application would difficult to continue their service in this situation. But also, It's difficult to trap this problem immediately unless realtime watching all mongod's log. These combination will be fatal for service !! My suggestion Incidentally, I think that mongod can judge easily its status itself. ReplSetImpl::getMemberToSyncTo() in rs_initialsync.cpp
| |||||||
| Comment by Kristina Chodorow (Inactive) [ 19/Feb/13 ] | |||||||
|
For problem #1, perhaps we should always warn if the member is configured to be delayed. For problem #2, this behavior is by design. 192.168.159.134 will make a "best effort" attempt to sync from a non-delayed member, but if the only member available is delayed and ahead of 192.168.159.134, 192.168.159.134 will sync from it. In general, do not read from secondaries unless your application can tolerate stale reads. | |||||||
| Comment by Hiroaki [ 18/Feb/13 ] | |||||||
|
I think, "attempts == 0 &&" is not for the sake of REPLSET in the aspect of data consistency.
|