MongoDBghost sync & slaveDelay

－2 －

Have you ever seen the message of

“replica set ghost target no good”

What is GHOST ?

－4 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

－5 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync fail

Sync target

－6 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

－7 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

Ghost slave

Ghost target

NO GOOD ?

－9 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

－10 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync fail

－11 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

－12 －

replica set ghost target no good

Primary

Secondary

Secondary

Sync target

Sync target

“replica set ghost target no good”

NO GOOD !!(until 2.0.X )

－14 －

replica set ghost target no good

■ Ghost sync● Ghost sync can help replica set to improve availability– When temporary or partial network fault– When overflow the primary's oplog, only the nearest secondary can follow to the

primary and offer oplog to other secondaries by its large oplog space.– When new member of replica node joining.

● Ghost sync has the chance to ciclic sync between secondaries.– Secondaries specify the ghost target each other.(until 2.0.X)

Ghost sync on 2.3/2.4

－16 －

proper ghost sync

Primary

Secondary

Secondary

Sync fail

Sync target

－17 －

proper ghost sync

Primary

Secondary

Secondary

Sync target

Sync target

－18 －

proper ghost sync

Primary

Secondary

Secondary

Sync target

Sync target

Ghost slave

Ghost target

－19 －

proper ghost sync

Primary

Secondary

Secondary

Sync target

Sync target

Will change target as soon as possible

－20 －

Ghost sync on 2.3/2.4

■ Sync details● Sync from primary when “settings.chainingAllowed=false” since 2.2.2– syncFrom() is preferred for “settings.chainingAllowed”– The target is specifed by syncFrom() is saved on memory and cannot reset...

● Get primary's op time and choise the fresh nearest node to sync.– fresh : before me and behind within 30 seconds from Primary– nearest: by ping time– not slaveDelay and not hidden– not in the veto list

What is slaveDelay ?

－22 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

Sync target

－23 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

A

Inset A

－24 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

ASync immediately

A

－25 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

A AB

Inset B

－26 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

ASync immediately

AB B

－27 －

slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

A

Sync A after 60 secs from “Insert A”

A

A

B B

－28 －

slaveDelay

■ When construct the replicaset● You can specify the slaveDelay=<seconds> attribute to make delay the SECONDARY node sync data from the PRIMARY.

●You MUST specify the priority=0 attribute with slaveDelay.– It means slaveDelay node cannot promote to the PRIMARY.

● You SHOULD specify the hidden=true with slaveDelay in many cases.– You would have to prevent the slaveDelay node from connecting with client.

● slaveDelay would be used as the realtime backup for human errors.ex >When you run the “db.dropDatabase()” command by MISS !!

All normal secondaries delete the data files immediately and never recover. But then you have a chance to recover datas from slaveDelay node, if you did the proper action. (Shutdown this node IN A HURRY !!! )

Ghost sync & slaveDelay

－30 －

Ghost sync & slaveDelay

Primary Secondary

Sync target

Sync target

Ghost slave

Ghost target

SecondaryslaveDelay=60

－31 －

Ghost sync & slaveDelay

Primary

SecondaryslaveDelay=60

Secondary

A

Inset A

－32 －

Primary

SecondaryslaveDelay=60

Secondary

ASync immediately

A

Ghost sync & slaveDelay

－33 －

Primary

SecondaryslaveDelay=60

Secondary

A AB

Inset B

Ghost sync & slaveDelay

－34 －

Primary

SecondaryslaveDelay=60

Secondary

ASync immediately

AB B

Ghost sync & slaveDelay

－35 －

Primary

SecondaryslaveDelay=60

Secondary

A AB B

Sync A after 60 secs from “Insert A”

A

Ghost sync & slaveDelay

It's OK !!

－37 －

Primary Secondary

SecondaryslaveDelay=60

Ghost sync & slaveDelay

－38 －

Primary

SecondaryslaveDelay=60

Secondary

A

Inset A

Ghost sync & slaveDelay

－39 －

Primary

SecondaryslaveDelay=60

Secondary

AB

Inset B

Ghost sync & slaveDelay

－40 －

Primary

SecondaryslaveDelay=60

Secondary

A

Sync A after 60 secs from “Insert A”

A

B A

Sync immediately

Ghost sync & slaveDelay

No good ...

－42 －

■ Ghost sync & slaveDelay are on bad teams... The slaveDelay node's oplog is always delay from PRIMARY

So slaveDelay node's should NOT be chosen as Ghost target.

Or the SECONDARY which chose the slaveDelay node as Ghost target SHOULD change its status MAINTAINANCE (or be treated as the HIDDEN)

Then, clients will get fresh datas from other SECONDARIES or PRIMARY !!

Ghost sync & slaveDelay

[slaveDelay with Ghostsync] https://jira.mongodb.org/browse/SERVER-8476

Sincerely.