What you will learn
Replace mixed operational chat notes with a focused workflow for membership, query execution, and connector failures.
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
If SELECT 1 works but no workers appear, inspect discovery and peer reachability. If workers appear but one catalog query fails, inspect that connector, its credentials, and source permissions. For slow queries, retain the query ID and examine the execution plan, queued time, memory, and scanned data.
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.