System Design Considerations
The system configuration and dictionary compression information is maintained by the nodes running the admin role. This information only exists on nodes running the admin role, so a redundant design is essential to maintain high system availability.
- The system configuration contains information such as users, network configuration, table definitions, and so on, and is maintained in a file named /var/opt/ocient/metadataStorage.raft.
- The dictionary compression data is used for table columns defined with the COMPRESSION GDC column attributes and is stored in a file named /var/opt/ocient/globalDataStorage.raft.
Redundancy for the system configuration and dictionary compression is maintained using a "majority present" model. In a system with N nodes configured with the admin role, at least N / 2 + 1 must be present and active for the system to function correctly. If that number of nodes running the admin role is not present, your system cannot start, execute queries, load data, or perform system configuration.
The "majority present" model differs from the parity encoding used for storage clusters described in Key Storage Concepts and Terms, which allows for parity width failures.
In most cases, a similar redundancy level is preferable for Foundation (LTS) Node redundancy and Administrator Node redundancy. For example, a system configured with a parity width of 2 allows 2 Foundation Nodes to fail and the system to continue to function. To provide the same redundancy level for system configuration and dictionary compression data, the system must be configured with 5 nodes running the admin role. This allows the system to function even if 2 Administrator Nodes fail, leaving a majority of 3.
The following table shows the number of nodes that should be configured with the admin role for various levels of redundancy.
Number of Administrator Nodes Configured | Administrator Node Failures Tolerated |
---|---|
1 | 0 |
2 | 0 |
3 | 1 |
4 | 1 |
5 | 2 |
6 | 2 |
7 | 3 |
To configure a node to run the administrator role, run the command:
It is only possible to remove the admin role from a node if there are at least two other nodes with the administrator role. Administrators should exercise care when adding the admin role.
It is recommended that all nodes running the SQL role also run the admin role. Additional nodes can be configured with the admin role to bring the level of redundancy up to the level you want.
Future system designs might require that nodes running the SQL role also have the admin role configured.
Systems created prior to version 20.0 have dedicated nodes running the admin role. No changes are required on upgrade to 20.0, however it is recommended that the dedicated Administrator Nodes be deprecated and removed as appropriate.
You can retain dedicated Administrator Nodes to maintain the specified levels of redundancy, however support for those nodes could be removed in a future release.
To remove a dedicated Administrator Node:
- Add the admin role to the SQL Nodes and any additional nodes necessary to reach the required level of redundancy.
- Remove the dedicated Administrator Node with the command: DROP NODE nodename;
ALTER NODE