Skip to main content

SQL Cluster Troubleshooting

This page collects the most common SQL Cluster connection and performance issues and how to fix them. For general SQL Cluster usage, see SQL.

Connection drops with TSocket read 0 bytes​

JDBC clients (beeline, dbt, BI tools, Airflow operators) intermittently lose connections to the SQL Cluster with TSocket read 0 bytes, Unexpected end of file from HS2, or similar transport errors. The three most common causes:

  • Spark configs missing on a newly created cluster. A freshly provisioned SQL Cluster may lack connection-stability tuning that your production cluster has. If a new cluster behaves worse than an older one, compare effective Spark configs and apply the missing ones via SET <property>=<value> at session start.
  • hive.server2.thrift.max.worker.threads saturated. Many concurrent JDBC clients can exhaust the default thread pool. Contact support to raise the limit if you genuinely need more concurrency.
  • MERGE-ON-READ table queries are slower on a Quanton-enabled cluster. If you migrate workloads to a new cluster and see slower queries on MOR tables specifically, the new cluster may be missing optimizations that were applied to the original. Open a support ticket with the cluster name and a slow-query example.

Long-running queries fail after ~1 hour​

Onehouse SQL Clusters sit behind an AWS Classic Load Balancer with a 4,000-second (~66-minute) idle timeout. Queries that run uninterrupted past that limit are disconnected at the network layer, surfacing as transport errors at the client.

Workarounds, in order of preference:

  1. Break the query into smaller batches. This is the most robust fix — long single queries are also more fragile to retries.
  2. Increase sync frequency upstream so each query has less data to scan.
  3. Request an upgrade to a Network Load Balancer. NLB does not enforce the same idle timeout. The endpoint URL changes during the upgrade — coordinate with support so client connection strings are updated.

SQL Cluster doesn't auto-scale or feels under-resourced​

A SQL Cluster scales between 1 instance and its Max OCU based on utilization. If you expect autoscaling and don't see it:

  • Some configuration changes — including hive.server2.thrift.max.worker.threads and certain queue settings — require a cluster restart to take effect. The console reflects the new setting before it is actually applied.
  • Queue configurations can reset to defaults on restart if they are not persisted through the right mechanism. Verify your settings after any restart.
  • Connection-pool health and per-node CPU are not the same metric. A cluster fully utilized on connection slots but lightly loaded on CPU will not scale up because the autoscaler reads CPU. Raise the thrift worker limit instead.

CREATE TABLE succeeds but the table is missing from SHOW TABLES​

Verify the table was created in the database and catalog you expect — SHOW TABLES is scoped to the current USE catalog.db. If you can DESCRIBE the table by fully-qualified name but it doesn't appear in the list, you're connected to a different database in the session.

See also​