Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getting keys from local and remote nodes for merging. #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Tthread
Copy link

@Tthread Tthread commented Dec 4, 2013

Hello, I found an issue when two nodes splits and each of ones added a key to a table.

In your code you get keys just from a local node. I suppose it's not fair as soon as a remote nodes can add keys in the tables too.
As a result when I try to add key_1 to table_1 at a first node and add key_2 to table_1at a second one I'll lost one of the record depends on which node will be merge.

So that I make a patch for fix it. Please, check it out.

With BR, Ilya.

@uwiger
Copy link
Owner

uwiger commented Dec 4, 2013

In general, it's probably risky to fetch keys from all nodes and merge. Also, it shouldn't be necessary to fetch keys from all nodes, as the nodes within one island should have the same set of keys for any given table.

What I imagine would be the best strategy (which is not the way it currently works) would be to identify the largest island and use the set of keys from that island. That is, check the sizes of IslandA and IslandB, and select either NodeA or NodeB to run the stitch. Then use the keys only from the node running the stitch.

This would mean that objects added to the other island would be ignored, which is not ideal. Better would be to use the 'majority' option to ensure that writing to a minority island is not allowed, and then find a way to lift extra objects from the minority island. Perhaps building a bloom filter from the keys on the first pass, then ask the remote node to run through the table and collect any key that doesn't match the bloom filter. This might give some false positives, but might actually work on a very large table. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants