View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004830 | SymmetricDS | Improvement | public | 2021-02-12 21:33 | 2022-08-02 20:15 |
Reporter | janicemc | Assigned To | |||
Priority | high | ||||
Status | new | Resolution | open | ||
Product Version | 3.12.6 | ||||
Summary | 0004830: A request for “symadmin remove-node” to be able to be run from any node in a multi-master configuration | ||||
Description | Currently in a multi-master configuration, any node can assume the role of “registration server” relative to node adds simply by having a new node register with it. This is highly convenient and useful, especially in light of the importance of minimizing single points of failure. It appears that currently there is no parallel capability relative to node deletes. That is, the removal of nodes requires steps to be performed only on the originally designated registration server (as determined by the engine properties files); it appears that these steps cannot be successfully performed on other master nodes. This may become an issue if the registration server goes down or otherwise becomes unavailable. | ||||
Steps To Reproduce | Remove a node on the original registration server (successful) ----------------------------------------------------------------------------------------- Multi-master configuration (one group and one group link) 1) On originally designated registration server (as determined by the engine properties files) (Note that auto.registration must be set to 'false', or else the node to be removed might automatically re-register before step 0000002 is performed, thereby necessitating that step 0000001 be performed again after step 0000002) symadmin remove-node -n <node> 2) On node to be removed: sym_server stop symadmin uninstall (Steps 0000001 and 0000002 can be reversed without auto.registration having to be ‘false’) Result: - all remaining nodes immediately see the update to the sym_node table - it is not relevant whether the node being removed was originally registered with the “originally designated” registration server or with another node Remove a node on a node other than the original registration server (not successful) -------------------------------------------------------------------------------------------------------------------------- Multi-master configuration (one group and one group link) 1) On non-"reegistration server" node (as determined by the engine properties files) (Note that auto.registration must be set to 'false', or else the node to be removed might automatically re-register before step 0000002 is performed, thereby necessitating that step 0000001 be performed again after step 0000002) symadmin remove-node -n <node> 2) On node to be removed: sym_server stop symadmin uninstall (Steps 0000001 and 0000002 can be reversed without auto.registration having to be ‘false’) Result: - sym_node table updated only on the node from step 0000001 - I could not find a sym_data entry with operation type ‘D’ corresponding to the sym_node table change on any of the nodes in the cluster - Other nodes continued without success to attempt to replicate to the removed node | ||||
Additional Information | This is a highly desirable capability which minimizes single points of failure with respect to the registration server. In general, it is highly desired that all capabilities of the registration server be available on every node of a multi-master configuration. A priority of "high" is indicated as this functionality is a must-have for our application. | ||||
Tags | registration | ||||