[SERVER-6476] Setting slaveDelay on a sync target should cause syncing members to find a new target. Created: 17/Jul/12  Updated: 03/Oct/12  Resolved: 03/Oct/12

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.1.2
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Bernie Hackett Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-5208 Replica set periodic reevaluation of ... Closed
Operating System: ALL
Participants:

 Description   

Steps to reproduce:

1. Set secondary A to sync from secondary B
2. Reconfigure the set such that secondary B has a slaveDelay greater than 10 seconds.

Secondary A will continue to sync from secondary B with no warnings at all. Consequently secondary A is now also slaveDelayed. In the following example 27019 has been configured to sync to 27018.

foo:SECONDARY> rs.conf()
{
	"_id" : "foo",
	"version" : 6,
	"members" : [
		{
			"_id" : 0,
			"host" : "behackett-dt:27017"
		},
		{
			"_id" : 1,
			"host" : "behackett-dt:27018",
			"priority" : 0,
			"slaveDelay" : 200
		},
		{
			"_id" : 2,
			"host" : "behackett-dt:27019"
		},
		{
			"_id" : 3,
			"host" : "behackett-dt:27020",
			"arbiterOnly" : true
		}
	]
}
foo:SECONDARY> rs.status()
{
	"set" : "foo",
	"date" : ISODate("2012-07-17T00:52:31Z"),
	"myState" : 2,
	"syncingTo" : "behackett-dt:27018",
	"members" : [
		{
			"_id" : 0,
			"name" : "behackett-dt:27017",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"uptime" : 94,
			"optime" : Timestamp(1342486334000, 4),
			"optimeDate" : ISODate("2012-07-17T00:52:14Z"),
			"lastHeartbeat" : ISODate("2012-07-17T00:52:29Z"),
			"pingMs" : 0
		},
		{
			"_id" : 1,
			"name" : "behackett-dt:27018",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 94,
			"optime" : Timestamp(1342486034000, 1),
			"optimeDate" : ISODate("2012-07-17T00:47:14Z"),
			"lastHeartbeat" : ISODate("2012-07-17T00:52:29Z"),
			"pingMs" : 0,
			"errmsg" : "syncing to: behackett-dt:27017"
		},
		{
			"_id" : 2,
			"name" : "behackett-dt:27019",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 1874,
			"optime" : Timestamp(1342486034000, 1),
			"optimeDate" : ISODate("2012-07-17T00:47:14Z"),
			"self" : true
		},
		{
			"_id" : 3,
			"name" : "behackett-dt:27020",
			"health" : 1,
			"state" : 7,
			"stateStr" : "ARBITER",
			"uptime" : 94,
			"lastHeartbeat" : ISODate("2012-07-17T00:52:29Z"),
			"pingMs" : 0
		}
	],
	"ok" : 1
}



 Comments   
Comment by Eliot Horowitz (Inactive) [ 03/Oct/12 ]

SERVER-5208

Comment by Bernie Hackett [ 17/Jul/12 ]

Subsequently telling A to sync from B again raises no warning in the shell or in the logs:

foo:SECONDARY> rs.syncFrom('behackett-dt:27018')
{
	"syncFromRequested" : "behackett-dt:27018",
	"prevSyncTarget" : "behackett-dt:27018",
	"ok" : 1
}
 
Mon Jul 16 18:06:32 [initandlisten] connection accepted from 127.0.0.1:60446 #281 (5 connections now open)
Mon Jul 16 18:06:38 [rsBackgroundSync] replSet syncing to: behackett-dt:27018 by request
Mon Jul 16 18:06:46 [conn279] end connection 127.0.0.1:60438 (4 connections now open)
Mon Jul 16 18:06:46 [initandlisten] connection accepted from 127.0.0.1:60453 #282 (5 connections now open)
Mon Jul 16 18:06:47 [conn280] end connection 127.0.0.1:60439 (4 connections now open)

Generated at Thu Feb 08 03:11:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.