OrientDB looses data when we restart cluster after some nodes crashed #6999
Assignees
Milestone
Comments
|
I suggest you to upgrade to the last 2.2.13 where many bugs on distributed have been already fixed. |
|
Sorry, was a typo, we use v2.2.13 |
|
We improved the merge strategy in 2.2.x branch. There are still some corner case where the merge is not done, but we will finalize it in the following days. However, if you could try 2.2.x, your feedback would be valuable before we release the next hotfix. |
|
I have tested with the latest v2.2.13 version. May I clarify, is it an OrientDB issue or maybe I can somehow change the configuration to make it working? |
|
Is this issue going to be resolved in the next hotfix? Just want to clarify the expectation, because we have a release very soon and it is critical for us. |
|
This issue has been fixed in last 2.2.x. Any chance to test it? |
|
Which version should I test, the latest snapshot? |
|
You can it by your own or use last snapshot just published: https://oss.sonatype.org/content/repositories/snapshots/com/orientechnologies/orientdb-community/2.2.14-SNAPSHOT/orientdb-community-2.2.14-20161221.214344-76.tar.gz |
|
I have tested 2.2.14 version and the bug is still here. |
|
If you tried the same wit 2.2.14, could you please publish here the content of the 2 files |
{
"@type": "d",
"@version": 0,
"version": 30,
"autoDeploy": true,
"readQuorum": 1,
"writeQuorum": 1,
"executionMode": "undefined",
"readYourWrites": true,
"newNodeStrategy": "dynamic",
"servers": {
"@type": "d",
"@version": 0,
"*": "master"
},
"clusters": {
"@type": "d",
"@version": 0,
"internal": {
"@type": "d",
"@version": 0
},
"*": {
"@type": "d",
"@version": 0,
"servers": [
"node-1",
"node-2",
"<NEW_NODE>"
]
},
"odocumentwrapper_2": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"odocumentwrapper": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"aclentity": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"aclentity_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"ofunction_0": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"configurationentry_3": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"configurationentry": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"v": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"v_3": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"principalentity": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"principalentity_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"roleentity": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"roleentity_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"rulemodelentity_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"rulemodelentity_3": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"favoriteentity_3": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"favoriteentity": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"extractfilterentity_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"extractfilterentity_2": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"e": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"e_1": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"osequence_0": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"orole_0": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"savedsearchentity_3": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"savedsearchentity": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"ouser_0": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
},
"oschedule_0": {
"@type": "d",
"@version": 0,
"servers": [
"node-2",
"node-1",
"<NEW_NODE>"
]
}
}
} |
|
Not the |
{
"@type": "d",
"@version": 0,
"version": 57,
"node-1": {
"@type": "d",
"@version": 0,
"segment": 0,
"position": 8726,
"@fieldTypes": "segment=l,position=l"
},
"lastOperationTimeStamp": 1482505984716,
"node-2": {
"@type": "d",
"@version": 0,
"segment": 0,
"position": 3552,
"@fieldTypes": "segment=l,position=l"
},
"@fieldTypes": "lastOperationTimeStamp=l"
} |
|
Could you please provide the files from other servers too, so I can compare what's wrong? |
|
Do you have the full log? What's happened next? Was it able to download the database? |
|
One more, with version |
|
Sorry, do not have the full log right now, I was trying to repeat the test and faced the error above. |
|
The reason of that exception is the following: |
|
Any comments on that? And could you please tell me an approximate date of 2.2.15 release? |
5 tasks
|
Looks like this issue is fixed, but I found one more minor issue related to that #7073 |
|
I have tested released 2.2.15 version and the fix was removed. Was not it released because of #7073 bug? |
|
Hi @pavlop-asg, Thanks for your comment. I'm sorry to hear about your problems. It seems strange to me this difference between 2.2.15-SHAPHOT and 2.2.15. As far as I see the fix has been included in 2.2.15 Are you sure you made the very same test on 2.2.15-SHAPHOT and 2.2.15? Thanks, |
|
I have repeated a test with 2.2.15 and looks like the issue is fixed only partly. Use cases:
|
|
I've just tried the 2nd case and everything works. The node1 was restarted, it recognized that its database was newer. This is the log. |
|
Actually this worked out after a fix that I just pushed on 2.2.x. Please could you test both cases? They both work for me. |
|
Thank you, I will try. |
|
It is working fine for me after your fix. Thank you a lot! |
|
Could you tell how soon 2.2.16 will be released? |
|
Hi @pavlop-asg, Glad to hear the issue has been fixed. Thanks for your patience and tests I'll discuss internally and try to understand when 2.2.16 will be released Thanks, |
|
Fixed by ce26174 Release notes updated No changes in the documentation required Can be closed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
OrientDB Version, operating system, or hardware.
Operating System
Expected behavior and actual behavior
There is an example. We have node A and B, we write a value "1" to a document when node A and B are up. We shut down node B and write value "2", after we shut down node A as well. When we start node B and after node A - cluster will have old value "1" instead of "2", looks like there is some bug when OrientDB merges the records. NOTE: when we start node A and after node B - everything works as expected.
Steps to reproduce the problem
Start two nodes with the following distributed configuration:
{ "autoDeploy": true, "readQuorum": 1, "writeQuorum": 1, "executionMode": "undefined", "readYourWrites": true, "newNodeStrategy": "static", "servers": { "*": "master" }, "clusters": { "internal": { }, "*": { "servers": ["<NEW_NODE>"] } } }This issue is applicable for other configurations as well, for example:
The text was updated successfully, but these errors were encountered: