OK I've browsed the source code (the configuration parser only)
The fact is the * is not interpreted. It does not mean "anything". It means
default. Then if you write :
"*_node0": {
"servers" : [ "node0", "node1" ]
},
It will not be interpreted as "any cluster ending by _node0". Then I made
the following test with 4 nodes (node0 to node4) to implement RAID10 for
the t class :
{
"autoDeploy": true,
"hotAlignment": false,
"executionMode": "undefined",
"readQuorum": 1,
"writeQuorum": 2,
"failureAvailableNodesLessQuorum": false,
"readYourWrites": true,
"clusters": {
"internal": {
},
"index": {
},
"*": {
"servers" : [ "<NEW_NODE>" ]
},
"t_node0": {
"servers" : [ "node0", "node1" ]
},
"t_node1": {
"servers" : [ "node1", "node2" ]
},
"t_node2": {
"servers" : [ "node2", "node3" ]
},
"t_node3": {
"servers" : [ "node3", "node0" ]
}
}
then create cluster t_node0. When running the "clusters" command, t_node0
is seen on each node, but this is only metadata.
when connecting on node3 and I try to insert :
orientdb {db=db01}> INSERT INTO t(name, surname) VALUES ('Jay', 'Miner' ) ;
Error: com.orientechnologies.common.exception.OException: Cannot find best
cluster for class 't' on server 'node3'. ClusterStrategy=local
wihich is expected behaviour.
Conclusion : it would be nice if orientdb could implement pattern matching
for the distributed configuration to avoid too much reload.
Regards
--
---
You received this message because you are subscribed to the Google Groups
"OrientDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
