In the ACID paper from aerospike, I found that
To make sure that no writes are lost in a race condition between the act of re-balancing and accepting writes, Aerospike maintains a journal of changes that will be reapplied, after proper checks, at the end of a partition’s migration.
That means the write will not apply to the index until the migration finished. So the new write during migration is not readable until the journal apply to index after the migration?
The writes are applied during migration and are available. The write journal is simply a safety net for re-applying any writes, if needed, in possible obscure timing edge cases.
So the migration will need check the new write in the index while migrating. How can it find out which is new write effective? Or it just rescan the index to find out new created keys? Is there any tech note on the node fail migration details?
http://www.aerospike.com/docs/architecture/clustering.html#what-happens-when-a-node-fails
The important point to focus is that writes will always only go to the master, and in a cluster, at anytime, there is only one master, thus writes are serialized.
In the case of a node failure, all nodes will agree on who the new master is. Also for reference - https://github.com/aerospike/aerospike-server/issues/70
If there are brief moments where multiple nodes may separately think they are the master and received writes, conflict resolution rules (TTL or generation) will determine which copy to take.
Thanks for the explanation.