I would like to first thank you for your work in the development of this tool. It is small yet seems truly powerful and conveniant for embedded applications.
I am currently investigating its use in a scenario where a set of embedded linux devices would be connected in a local enterprise network without internet, sharing a decentralized DB. Over time, devices would join then permanently leave the network, with a minimum of 1 device present at any given time.
Ideally, all devices would be embedded with the same default program, without manual configurations to distinguish between primaries/secondaries. So far, P2P topology seems to fit best.
These devices can already discover eachother on the network in an accurate manner and have almost real-time knowledge of the number and adress of the other nodes on the network. As such, they are able to close and re-open their litesync connection with new parameters if needed (total_primary_nodes, connect adresses, ..) dynamically based on the devices leaving/joining the network.
Also, (this is key) devices that are offline would be software-restrained to not perform any operation on their DB until they are back online. As such, this is a scenario where DB availability for offline devices is not really the concern. However, synchronization when online is important and should be based on latest commits.
A common scenario :
1. There is first only 1 device on the network and some records are added to its DB
2. Then 7 additonnal devices join and some records are added/updated/deleted
3. Later, 4 devices leave the network permanently (including the first device)
And so on ... with potentially full rotation of devices joining then permanently leaving the network.
The desired behaviour would be that devices joining a network (for the first time or not) would always have their DB updated with the latest up-to-date data from the devices already present in the network, independently from the ratio of new devices joining versus already existing online devices. If we take as example the transition from step 1 to 2 in the example above :
. One device on the network as a primary node (total_primary_nodes=1) , a table is created and some data is added ( DB > Table A : row 1, row 2 are added)
. Then 7 devices are added at the same time on the network as primary nodes (on these devices : DB> Empty). LiteSync connection with DB is automatically closed then re-opened on all devices with new URI connection string with 8 total_primary_nodes with adequate connection adresses.
. New primary nodes synchronize with the first node and all 8 devices have DB > Table A : row 1, row 2
If we narrow my question down, I guess it would be : how is consensus managed by LiteSync in P2P topology ? Would table 'A' be lost because the majority of nodes joining do not have Table A ? Or is there tracking of the order of the commits, which would enable the desired outcome ?
If not, an alternative (I guess) would be to temporarily add new nodes as secondaries and wait for them to be synchronized before setting them up as primaries. My second general question would be : Does LiteSync allow the changing of node types on existing DBs ? Or even more generally : is it possible to close then re-open a connection with different URI parameters on the same DB ?
I didn't yet have the chance to try LiteSync (will do very soon), and wanted to ask in case you already have a quick answer
Thanks in advance !