The master is totally unaware of the slaves. The slave continuously keeps polling the master (depending on the ‘pollInterval’ parameter) to check the current index version the master. If the slave finds out that the master has a newer version of the index it initiates a Â The steps are as follows,
- Slave issues a filelist command to get theÂ replication process.list of the files. This command returns the names of the files as well as some metadata (size,lastmodified,alias if any)
- The slave checks with its own index if it has any of those files in the local index. It then proceeds to download the missing files (The command name is ‘filecontent’ ). This uses a custom format (akin to the HTTP chunked encoding) to download the full content or a part of each file. If the connection breaks in between , the download resumes from the point it failed. At any point, it tries 5 times before giving up a replication altogether.
- The files are downloaded into a temp dir. So if the slave or master crashes in between it does not corrupt anything. It just aborts the current replication.
- After the download completes, all the new files are ‘mov’ed to the slave’s live index directory and the files’ timestamps will match the timestamps in the master.
- A ‘commit’ command is issued on the slave by the Slave’s ReplicationHandler and the new index is loaded.