A mode in which two nodes will perform synchronization during Leadership Election. First option means that
all nodes makes snapshots in advance and then just send it by request from other nodes.
Second option is when the node sends required Journal files to other nodes, which contains events with
transaction ID more or equals to current node last transaction ID.
First option is prefered, but is not recommended for big models, because of size of snapshot
and costs spent to make it for each Leadership Election process.
Second option is generally not recommended if there is a big amount of Journal files or rolling
is performed very rarely, means big files will be always transmitted.
Default value is SyncMode.SNAPSHOT
void threadPoolSize(int threads)
Thread pool size of Sync Server, which handles synchronization requests and sends appropriate
threads - to be used
void retries(int count)
Number of retries to transmit state data until it fails.
void port(int port)
Port on which Sync Server will be listening.
void waitAllNodesSync(boolean wait)
The synchronization process lasts during global Leadership Election process, which means
no node during it can operate on production. Sometimes, it is obvious that Master
candidate has the latest state, and can start to operate not awaiting other Slaves to catch up with
In that case, if waitAllNodesSync is set to true, it will start to handle Commands normally
during "sync" stage of Leadership Election process.
Warning!!! You should consider using that flag *very* carefully, as it means that all failover data
from Master will not be handled by Slaves as usual, but just buffered in memory, until they finish syncing.
And if synchronization process takes too long, some data might be even lost. Use it primarily if
you want Master to start operate as soon as possible (millisends matters) and you know that sync process
either not happens at all or will be very short.