Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
(John's comments are marked in red)
Aim: Split indexlet I (backed by backing table T) located on M1 into I1 (backing table remains T) and I2 (new backing table T2) and migrate I2 to M2.


Coordinator TableManager splitAndMigrateIndexlet:
Create table T2 on M2.
Call prepForIndexletMigration on M2 for I2.
Call splitAndMigrateIndexlet on M1 for I and get nextNodeId.
In index->indexlets: Truncate I to I1 (belonging to M1) and add I2 belonging to M2. (This would also get persisted to external storage when we implement coord fault tolerance for indexes.)
Call takeIndexletOwnership on M2 for I2 with nextNodeId.
Call trimAndBalance on M1 for I1 and on M2 for I2. (Note: we’ll have these functions return right away and do the actual work asynchronously.)

...

In indexletManager list of indexlets, truncateIndexlet I to of I1.
Send the last log segment.
(Or, we could send the entire log, truncate, check log if it has grown and if it has then migrate that segment.)
Return nextNodeId. Recompute on the receiving side as you receive segments? See recovery.


M2 MasterService prepForIndexletMigration:
Add I2 (with backing table T2) to local information with state RECOVERING.



M2 MasterService takeIndexletOwnership:
Add I2 to local information with state NORMAL and nextNodeId provided (and if I2 already exists, simply modify state and nextNodeId



M2 MasterService receiveMigrationData:
Same as pre-existing receiveMigrationData, except: Recompute nextNodeId on the receiving side as you receive segments. (See recovery to figure out how.)


M1 failures:
a: Coordinator starts split&m on whichever server (say RM) recovers this indexlet I.

...