Page History

...

...

1. The demander node prepares the set of IgniteDhtDemandedPartitionsMap#full cache partitions to fetch;
2. The demander node checks compatibility version (for example, 2.8) and starts recording all incoming cache updates to the new special storage – the temporary WAL storage;
3. The demander node sends the GridDhtPartitionDemandMessage to the supplier node as usual;
4. When the The supplier node receives GridDhtPartitionDemandMessage and starts the new checkpoint process and fixes cache partition file sizes;
5. The supplier node creates an empty the temporary temporary file with .delta (e.g. part-0.bin.delta file) postfix for each cache partition file with .tmp postfix (in the same cache persistence working directory or another configured);
6. The supplier node starts tracking each pageId write attempt to these partition files
   
   1. When the write attempt happens, the thread that caused it reads the original copy of this page from the partition and flushes it to the corresponding .delta file;
   2. After it the thread writes the changed page data to the partition file;
7. The supplier waits the checkpoint process ends;
8. On the supplier for each cache partition file
   1. The process opens the partition file in read-only mode;
   2. Starts sending partition file (as it is) by chunks of predefined constant size (multiple of PageMemory size);
      
   3. After the partition file sent it starts sending corresponding .delta
    node splits the whole cache partition file into virtual chunks of predefined size (multiply to the PageMemory size);
   
   1. If the concurrent checkpoint thread determines the appropriate cache partition file chunk and tries to flush dirty page to the cache partition file
      1. If rebalance chunk already transferred
         1. Flush the dirty page to the file;
      2. If rebalance chunk not transferred
         1. Write this chunk to the temporary cache partition file;
         2. Flush the dirty page to the file;
   2. The node starts sending to the demander node each cache partition file chunk one by one using FileChannel#transferTo
   3. If the current chunk was modified by checkpoint thread – read it from the temporary cache partition file;
   If the current chunk is not touched – read it from the original cache partition file;
9. The demander node starts to listen to new pipe incoming connections type of incoming connections (a socket channel created event) from the supplier node on TcpCommunicationSpi;
10. The demander node creates the temporary cache partition file with .tmp postfix in the same cache persistence directory;
11. When the appropriate connection established the demander node for each cache partition file
    1. Receives file metadata information (corresponding cache group identifier, cache partition file name, file size)
    2. Writes data from the socket to the particular cache partition file from the beginning of the file
    3. After the original cache partition file received the node starts receiving corresponding .delta file
    4. The node reads data from the socket by chunks of PageMemory size and applies each received pageId to the partition file
    The demander node receives each cache partition file chunk one by one
    1. The node checks CRC for each PageMemory in the downloaded chunk;
    2. The node flushes the downloaded chunk at the appropriate cache partition file position;
12. When the demander node receives the whole cache partition file
    1. The node initializes received .tmp file as its appropriate cache partition file;begins the rebuild secondary indexes procedure over received partition file
    2. After it the thread Thread-per-partition begins to apply for data entries from the beginning of WAL-temporary storage;
    3. All async operations corresponding to this partition file still write to the end of temporary WAL;
    4. At the moment of WAL-temporary storage is ready to be empty
       1. Start the first checkpoint;
       2. Wait for the first checkpoint ends and own the cache partition;
       3. All operations now are switched to the partition file instead of writing to the temporary WAL;
       4. Schedule the temporary WAL storage deletion;
13. The supplier node deletes the all temporary cache partition filefiles;

Сomponents to change

In terms of a high level overview a list of components that will be changed provided below.

...