System Settings
System Settings is used to maintain hot standby, alarm recovery behavior, network parameters, time synchronization, system control, and PING testing. After opening the page, use the left navigation to switch between modules.
Entry
Log in to GatewayRuntime Web and open System Management > System Settings.
Modules
| Module | Purpose |
|---|---|
| Hot standby | View local role, four production tasks, peer connectivity, and arbitration authorization; configure node identity, dual-network links, TLS, shared arbitration, and historical compensation. |
| Alarm configuration | Configure whether recovered alarms are removed directly from the real-time alarm list. |
| Network configuration | View network adapters and edit DHCP, IP address, subnet mask, gateway, and DNS servers. |
| Time synchronization | View local time, UTC time, and time zone; set system time; configure NTP servers and sync interval. |
| System control | Restart GatewayRuntime, restart the application, or download a configuration database backup. |
| PING test | Test connectivity to an IP address or domain and view packet loss, latency, and per-packet results. |
Hot Standby
Click Hot Standby in the left navigation. The page shows the current node, local role, peer connection, shared-arbitration authorization, configuration summary, and historical-data protection. It also provides edit, refresh, immediate peer sync, and manual failover actions.
| Area | What to check |
|---|---|
| Current node | Whether this node is Working, Standby, Taking Over, Needs Attention, or Failed, and whether collection, data forwarding, alarm, and rule-engine tasks match that role. |
| Peer connection | Transport state, complete-health state, consecutive failures, identified peer node, and peer role for each link. A link is completely healthy only after connection plus cluster, identity, complementary-role, and security validation. |
| Work authorization | With shared arbitration configured, verify that only the working node holds authorization. Check authorization expiry, failover epoch, and the latest failover error. |
| Historical-data protection | Review protected targets, pending peer sync, pending database writes, Journal status, and database-write authorization. |
Use Edit Configuration to open the hot-standby configuration panel.
| Setting | Description |
|---|---|
| Enable hot standby | Run the two gateways as a failover pair. When disabled, this gateway runs independently without peer connection or arbitration. |
| Cluster name | Required and identical on both gateways. Nodes with different cluster names cannot establish a control relationship. |
| Local node name | Stable, unique name of this gateway. It is required when hot standby is enabled and must differ between the two gateways. |
| Peer node name | Expected local-node name of the other gateway. It is required and must exactly match the peer's Local node name. |
| Connection mode | Configure one node to wait for a peer connection and the other to actively connect. The two roles must be complementary. |
| Peer address | First control-link address, usually IP:port without http:// or https://. The waiting side enters its local listen address; the connecting side enters the reachable peer address. |
| Dual network / second-link address | The second address is required when enabled and must differ from the first. Prefer separate adapters, switches, or subnets. Any completely healthy link can keep the peer online. |
| Shared connection key | Both gateways must use the same complex value for control-link identity validation. It does not encrypt the link. |
| Local transport certificate / trusted root / peer certificate host | Optional mutual TLS. All three fields must either be configured or be empty. The host or IP must appear in the peer server certificate SAN. Each gateway selects its own transport certificate and trusts the root that issued the peer certificate. |
| TLS protocol / revocation check | Select allowed TLS versions and revocation policy. Use the system security defaults unless the site has a specific requirement. |
| Shared arbitration file | Recommended in production. Both gateways must point to the same SQLite file on shared storage. File locking and short leases allow only one node to hold work authorization. Use an equivalent UNC or mounted path and verify read, write, and file-lock support from both nodes. |
| Work-authorization duration | Shared-arbitration lease in milliseconds; minimum 3000, default 15000. |
| Authorization renewal | Renewal interval in milliseconds; minimum 500 and no more than one third of the lease duration, default 3000. |
| Failover safety margin | Window in which a node must stop production tasks before lease expiry; minimum 500 milliseconds. Renewal plus safety margin must be less than the lease duration; default 2000. |
| Connection-check interval | Peer-check interval in milliseconds; minimum 1000, default 60000. Smaller values add network load; larger values delay fault detection. |
| Disconnect threshold | Processing starts after all configured links fail this many consecutive checks; range 1–100, default 3. With arbitration configured, the node must still acquire work authorization before starting production tasks. |
| Data-sync interval | Interval for configuration and variable data synchronization from the working node to standby, in milliseconds; minimum and default 1000. |
| Historical data/alarm compensation | Supported historical targets use a local reliable Journal, peer sync, and recovery replay. Enabled by default and independent from target-level dual-database mirroring. |
| Historical-protection settings | Tune batch size, peer acknowledgment timeout, local pending limit, database-write authorization and renewal, and retry interval according to outage duration, write volume, network latency, database load, and disk capacity. |
After upgrading an older pair, do not keep only the former addresses and connection key. Configure the cluster, local-node, and peer-node names on both gateways; then verify complementary connection modes, identical keys, shared arbitration, and TLS as required. After saving, confirm peer identity, complete link health, arbitration authorization, and all four production-task states before a failover drill.
Historical Data And Alarm Reliability
When hot standby is enabled, historical data and historical alarms can use historical compensation. The gateway stores events in the local Journal, synchronizes them with the peer node, replays unfinished records before an authorized node becomes Working, and uses a record key to avoid duplicate inserts on standard SQL targets.
| Item | Description |
|---|---|
| Applies to | Historical data targets and historical alarm targets. |
| Requirement | Hot standby is enabled and Historical Data/Alarm Compensation remains enabled. |
| Supported databases | Standard SQL write path for SqlServer, MySql, Sqlite, and PostgreSql. |
| Not covered | QuestDB, TDengine, custom SQL mode, historical table scripts, historical alarm table scripts, or other custom write paths. |
| Site recommendation | Enable offline cache for historical targets, reserve disk capacity for both CacheDB and Journal rows, and validate failover, link interruption, database outage, and restart recovery during a maintenance window. |
Historical-Data Protection Diagnostics
The Historical-Data Protection area helps verify whether historical targets support failover compensation, whether the Journal has backlog, and which node currently holds target-database write authorization.
| Area | Description |
|---|---|
| Summary | Shows the node, max sequence, pending peer-sync count, and pending database-write count. Long-lasting backlog indicates a hot-standby link, peer node, target database, or cache recovery issue. |
| Filters | Filter Journal events by target key, source node, record type, record key, pending peer, or pending DB state. |
| Target support | Lists each historical data/alarm target, support status, unsupported reason, and Journal target keys. |
| Journal state | Summarizes max sequence, total rows, pending peer, pending DB, oldest pending time, and newest event time by target key, source node, and record type. |
| Epoch lease | Shows the holder node, lease expiry, and lease status for each historical target. |
| Journal events | Shows individual historical events, peer/DB flags, record keys, and payloads for point-level or alarm-level troubleshooting. |
The shared arbitration file is not an independent third node; it is one SQLite file accessible by both gateways. Without it, the pair uses link-only failover and a network partition can produce split-brain. When all three TLS fields are empty, the shared connection key still validates identity, but traffic uses unencrypted TCP. Configure reliable shared storage and certificates for production, and test link loss, power loss, shared-storage failure and recovery, and manual failover in a maintenance window.
Alarm Configuration
Click Alarm Configuration in the left navigation.
| Setting | Description |
|---|---|
| Remove after alarm recovery | When enabled, recovered alarms are removed directly from the real-time alarm list. When disabled, recovered alarms still need confirmation before removal. |
The switch is saved immediately. Before changing it in production, confirm the on-duty and alarm acknowledgment process.
Network Configuration
Click Network Configuration in the left navigation.
| Setting | Description |
|---|---|
| DHCP | Enable automatic network configuration. When disabled, IP address, subnet mask, and gateway can be edited. |
| IP address | Static IP address used by the selected network adapter. |
| Subnet mask | Subnet mask for the selected adapter. |
| Gateway | Default gateway. |
| DNS servers | One or more DNS server addresses. |
Changing network adapter, gateway, or DNS settings may interrupt the current Web connection. Confirm remote access and fallback access before saving.
Time Synchronization
Click Time Synchronization Configuration in the left navigation.
| Area | Setting | Description |
|---|---|---|
| System time | Local time | Current local time of the gateway. |
| System time | UTC time | Current UTC time. |
| System time | Time zone | Current system time zone name. |
| System time | Set time | Open the side panel to select and save a new system time. |
| NTP | Enable NTP | Enable automatic NTP synchronization. |
| NTP | NTP servers | Server list used for NTP synchronization. |
| NTP | Sync interval | Synchronization interval in minutes. |
| NTP | Sync now | Run one NTP synchronization immediately. |
System Control
Click System Control in the left navigation.
| Operation | Description |
|---|---|
| Restart runtime | Restart GatewayRuntime. A confirmation dialog is shown before execution. |
| Restart application | Restart the application. The Web connection will be interrupted and needs to reconnect. |
| Backup configuration database | Download a consistent, standalone SQLite snapshot that includes committed WAL data for backup or migration. |
Restart operations affect collection, data forwarding, and Web access. Perform them in a maintenance window.
PING Test
Click PING Test in the left navigation.
| Parameter | Description |
|---|---|
| Target address | IP address or domain to test. |
| Test count | Number of PING requests. |
| Timeout | Timeout for each request in milliseconds. |
| Start test | Run the PING test. |
| Clear results | Clear current test results. |
The result area shows target host, success count, failure count, packet loss, average latency, latency range, and per-packet details.