Query-only node¶
This page describes the query-only node type, which services database queries without ingesting feed data.
A query-only node is a node that includes all processes required for servicing database queries and nothing more. This means it should not have any data loader processes and as a result cannot receive incoming feed data or mutating requests.
A query-only node can surface the same data as any other KXS node, though it may be configured to surface just a subset as well.
This feature is useful for targeting different classes of queries to the query-only nodes, isolating the other nodes from that load. Servicing queries only also means the host can have a smaller set of resources, for example the CPU cores and RAM required for ingestion. Lastly, the query-only nodes may have different HDB retention periods compared to the other nodes in the cluster.
Create a query-only manifest file¶
To set up a query-only node, a set of service classes is required. These service classes must be included in the manifest file for the query-only node.
| Service class | Description |
|---|---|
| qetcd | Allows processes on the query-only node to communicate with discovery. |
| DBW | Ensures that a database is written. |
| SM | Responsible for EOX signaling. Database processes will not become active until they have opened a connection to their local SM. |
| R/I/HDB | Database processes that will service queries. |
| GW | Required on any node that will service queries. |
| RP | Required on any node that will service queries. |
| MON | Allows monitoring data to be collected. Useful for debugging purposes. |
| MONRDB | Ensures at least 24h of monitoring data is available to be queried. |
| HWMON | Checks that hardware on the node is performing adequately. |
Any other service classes can be added to the manifest at the user’s discretion.
Feed config for the query-only node¶
A query-only node needs to be specified in feed.yaml using queryNodes. If queryNodes is not set, the nodes field is used instead. In the feed config below, there are 3 nodes. Nodes A and B receive incoming feed1 data with nodes A, B and C surfacing its output data.
feed:
values:
feed1:
id: 101
sc: sdl
nodes: [ A, B ]
procs: [ kxsSDL_A1, kxsSDL_B1 ]
queryNodes: [ A, B, C ]
streamIn: feed1
topicIn: feed1
streamsOut: [ emsint ]
topicsOut: [ SD1 ]