4
votes

I'm trying to setup on 3 servers. For the purpose of an example, I'm trying to setup a class "client", with 3 clusters "client_1", "client_2", and "client_3". My servers are called node1, node2, and node3. I want the clusters arranged such that I have 2 copies of each cluster, so if 1 node goes down I still have access to all the data, so for example:

  • node1 is master for client_1 and has a copy of client_2.
  • node2 is master for client_2 and has a copy of client_3.
  • node3 is master for client_3 and has a copy of client_1.

I've tried setting this up with the following steps: 1. Download OrientDB 2.1.1 Community and extract onto the 3 servers. 2. Delete the GratefulDeadConcerts database from the databases directory on each server. 3. Edit default-distributed-db-config.json on node1 as follows :

{
"autoDeploy": true,
"hotAlignment": false,
"executionMode": "undefined",
"readQuorum": 1,
"writeQuorum": 2,
"failureAvailableNodesLessQuorum": false,
"readYourWrites": true,
"clusters": {
"internal": {
},
"index": {
},
"client_1": {
"servers" : [ "node1","node2" ]
},
"client_2": {
"servers" : [ "node2","node3" ]
},
"client_3": {
"servers" : [ "node3","node1" ]
},
"*": {
"servers" : [ "<NEW_NODE>" ]
}
}
}
  1. Start node1 with dserver.sh.
  2. Create a database using console on node1: connect remote:localhost root password create database remote:localhost/testdb root password plocal graph
  3. Create a class and rename the default cluster: create class client extends v alter cluster client name client_1
  4. Startup node2 with dserver.sh, wait for database to auto deploy, then startup node3 and wait for deploy

At this point I have a database on 3 nodes, with a class called "client" with only one cluster "client_1".

  1. On node2, add the client_2 cluster: alter class client addcluster client_2
  2. Similarly, on node3: alter class client addcluster client_3

If I reconnect all console sessions and execute "list clusters" I now see all 3 clusters of the client class on each node. I also see the .cpm and .pcl files for each of the 3 clusters on each node. However, it appears that my intention in default-distributed-db-config.json is being taken into account as if I wait a couple of minutes and then insert a record from each node I see that the timestamps and file sizes only change on the files relating to the clusters that are supposed to be present on each node (would be nice and less confusing if the files didn't exist on the wrong nodes, but its not the end of the world).

So... now it appears that I have the database setup the way I intended, but the point of doing this is so that we can survive a server going down, so I shutdown node3 with ctrl-c. I can still see each of the records (I inserted 3, one per cluster) from both node1 and node2 - so far so good.

If I take a look at the contents of distirbuted-db.json on node1 or node2, I now see my "client" class clusters have been reconfigured - there's no node3 in the config any longer:

"client_3": { "servers": [ "node1" ], "@version": 0, "@type": "d" },
"client_2": { "servers": [ "node2" ], "@version": 0, "@type": "d" },
"client_1": { "servers": [ "node1", "node2" ], "@version": 0,
"@type": "d" }

Now I restart node3. The config is not getting updated again:

"client_3": { "servers": [ "node1" ], "@version": 0,
"@type": "d" },
"client_2": { "servers": [ "node2" ], "@version": 0, "@type": "d" },
"client_1": { "servers": [ "node1", "node2" ], "@version": 0,
"@type": "d" }

Is there something wrong in the way I've created/configured the database or is this a bug?

1

1 Answers

0
votes

I think the issue here is that "hotAlignment" needs to be set to "true" in the file "default-distributed-db-config.json". Per the OrientDB 2.2.x sharding doc, "If hotAlignment=false is set, when a node re-joins the cluster (after a failure or simply unreachability) the full copy of database from a node could have no all information about the shards." Note, though, this bullet from the changes between 2.1.x to 2.2.x: "Removed hotAlignment setting: servers, once they join the cluster, remain always in the configuration until they are manually removed."