What you will learn
Learn which settings must match across nodes, which must be unique, and which describe a data-source connector.
Before you begin
Prepare the coordinator at host1.sample.com and the worker at host2.sample.com with private connectivity and persistent local data directories. Obtain verified server and CLI distributions for the chosen release. The HTTP example below is for an isolated lab only; an accessible deployment needs the release’s authentication, TLS, and internal-communication security configuration.
1. Set persistent node identity
node.environment=tutorial
node.id=coordinator-01
node.data-dir=/srv/presto/data
Place these in etc/node.properties. On the worker use a different stable node.id and its own data directory, while retaining the same environment. Copying a node ID across machines prevents reliable identity.
2. Configure the coordinator
coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8080
discovery-server.enabled=true
discovery.uri=http://host1.sample.com:8080
Place these in etc/config.properties. The coordinator plans queries and serves discovery. With coordinator scheduling disabled, a healthy worker is required for distributed work. Use the pinned release’s supported JVM options and memory configuration rather than copying an unrelated server’s heap settings.
3. Configure the worker and start both nodes
coordinator=false
http-server.http.port=8080
discovery.uri=http://host1.sample.com:8080
bin/launcher start
bin/launcher status
Use the worker config on the worker only. Review server logs for registration errors. Before starting, add etc/catalog/tpch.properties on both nodes for a self-contained test catalog:
connector.name=tpch
The TPCH connector generates a tiny demonstration dataset, so this exercise needs no external database credentials. A catalog file is separate from node identity and discovery.
4. Run progressively stronger checks
SELECT 1;
SELECT node_id, http_uri, node_version, coordinator, state FROM system.runtime.nodes;
SHOW CATALOGS;
SELECT count(*) FROM tpch.tiny.nation;
The final query should return 25 for the TPCH nation table. Run with the CLI against the coordinator. SELECT 1 proves a basic query path, not that a remote data source works. Confirm the expected worker appears, then query a small known table in a configured catalog with bounded output.
5. Use the failure location
Change one setting at a time and retain the previous file. Compare node.environment and discovery.uri across hosts; compare node.id for uniqueness. Connector credentials belong in the approved secret mechanism, not copied command transcripts.
Example output
The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.
-- SELECT count(*) FROM tpch.tiny.nation;
_col0
-------
25
(1 row)
The TPCH connector’s nation table contains 25 rows. This verifies a real catalog query in addition to SELECT 1. Inspect system.runtime.nodes separately to confirm the expected worker is available.
Verify the result
The coordinator and intended worker appear with matching software versions, a real connector query succeeds, and the client reaches the intended coordinator. Measure the query on a bounded dataset before increasing concurrency.
Troubleshooting
No active workers points to discovery, environment mismatch, node identity, or connectivity. JVM startup errors need the release’s Java/options requirements checked. Catalog errors are not fixed by arbitrarily raising cluster memory limits.
Recovery and next steps
If a config change fails, restore the previous versioned config and restart only the affected lab node. For worker maintenance, account for running queries and use the release’s shutdown guidance. Preserve query IDs and logs rather than repeatedly restarting the whole cluster.