Thanks for the reply. Starting, stopping, and restarting H2 in my example was the only way I could think of to (roughly) simulate having one node in the cluster disconnect temporarily. It could be the result of a network disruption or something as simple as someone rebooting one of the machines in a cluster without understanding the implications. If that happens, the node that went offline temporarily shouldn't be allowed to rejoin the cluster automatically, because it may have missed some transactions while offline. I'm not sure what would happen if one of the nodes fails a commit due to a constraint violation in such a situation.
I'm assuming the expectation is for the node to be readded manually using the create cluster tool. If that's the expectation, I think it would be prudent to make eviction from the cluster permanent until an administrator intervenes. Once SessionRemote sets CLUSTER='' an administrator should be forced to run the CreateCluster tool to resynchronize the failed node. If you end up implementing a new clustering mechanism, I would really like to see some type of fail fast mode in addition to high availability. To clarify what I mean, if even one node in the cluster can't be reached, the cluster is taken offline. I think it would be useful for some types of small business applications where budgetary constraints increase the likelyhood of hardware or network failure (networks that are poorly designed by local admins and end up being prone to partitioning). In most of those cases redundant hardware is usually minimal and the applications are fairly low capacity. For those situations, I think providing data consistency at the expense of availability can be easy to justify because inconsistent or lost data ends up being more detrimental than taking the application offline temporarily while the root cause of the failure is identified and fixed. Let me know if you'd like me to clarify anything. Hopefully I haven't misinterpreted what SessionRemote is doing. Ryan -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To view this discussion on the web visit https://groups.google.com/d/msg/h2-database/-/CO6c-xWv_ugJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
