Use multiple compute clusters to isolate computing resources for different workloads - ApsaraDB for SelectDB

ApsaraDB for SelectDB supports multiple compute clusters within a single instance. Each cluster gets physically isolated computing resources, but all clusters read and write the same underlying data — so different business systems can run workloads independently without affecting each other's performance.

How it works

ApsaraDB for SelectDB uses a cloud-native compute-storage separation architecture. Upper-layer computing resources are decoupled from storage, which means multiple compute clusters can share the same data without duplicating it. Each cluster operates like a dedicated resource group: it coordinates one or more compute units to complete a computing task, and its computing resources are physically isolated from other clusters.

Use cases

Multiple compute clusters are suited for workload isolation across distinct business systems:

Read/write isolation: Separate write-heavy ingestion workloads from read-heavy query workloads so that large inserts do not degrade query response times.
Online/offline isolation: Run real-time serving queries and batch analytics jobs on separate clusters to guarantee predictable latency for production traffic.

Example: isolate two business systems

This example shows how to set up two clusters — cluster_01 for Business System A and cluster_02 for Business System B — and confirm that both clusters share the same underlying data.

Prerequisites

Before you begin, ensure that you have:

An ApsaraDB for SelectDB instance with at least two compute clusters (cluster_01 and cluster_02)
Admin account access to the instance

Step 1: Create user accounts and grant cluster access

Connect to the instance using the admin account and create two user accounts.

-- Create user accounts
CREATE USER test_01 IDENTIFIED BY 'testPassword';
CREATE USER test_02 IDENTIFIED BY 'testPassword';

-- Grant full data access to both accounts
GRANT ALL ON *.* TO test_01;
GRANT ALL ON *.* TO test_02;

-- Assign each account to its cluster
GRANT USAGE_PRIV ON CLUSTER cluster_01 TO test_01;
GRANT USAGE_PRIV ON CLUSTER cluster_02 TO test_02;

Step 2: Verify cluster assignments

While still using the admin account, run SHOW clusters to confirm the setup.

SHOW clusters;

Expected output:

+------------+------------+-------+
| cluster    | is_current | users |
+------------+------------+-------+
| cluster_01 | FALSE      |       |
| cluster_02 | TRUE       |       |
+------------+------------+-------+

The admin account has access to both clusters and uses cluster_02 by default.

Now connect as test_01 and run the same command.

SHOW clusters;

Expected output:

+------------+------------+-------+
| cluster    | is_current | users |
+------------+------------+-------+
| cluster_01 | TRUE       |       |
+------------+------------+-------+

test_01 can only access cluster_01, which confirms the cluster assignment is working correctly.

Now connect as test_02 and run the same command.

SHOW clusters;

Expected output:

+------------+------------+-------+
| cluster    | is_current | users |
+------------+------------+-------+
| cluster_02 | TRUE       |       |
+------------+------------+-------+

test_02 can only access cluster_02, which confirms the cluster assignment is working correctly.

Step 3: Write data on cluster_01

Connect as test_01 and insert test records into a new table.

CREATE TABLE golds_log
(
    user_id     bigint,
    accounts    string,
    change_type string,
    golds       bigint,
    log_time    int
) DISTRIBUTED BY HASH(`user_id`) BUCKETS 3;

INSERT INTO golds_log VALUES
    (3645356, 'wds7654321(4171752)',    'swim',  1700, 152607152),
    (2016869, 'dqyx123456789(2376699)', 'noise', 1140, 152607152),
    (3630468, 'dke3776611(4156064)',    'white', 1200, 152602752);

Step 4: Read the same data on cluster_02

Connect as test_02 and query the table that test_01 just wrote.

SELECT * FROM golds_log;

Expected output:

+---------+------------------------+-------------+-------+-----------+
| user_id | accounts               | change_type | golds | log_time  |
+---------+------------------------+-------------+-------+-----------+
| 3630468 | dke3776611(4156064)    | noise       |  1200 | 152602752 |
| 2016869 | dqyx123456789(2376699) | whitewo     |  1140 | 152607152 |
| 3645356 | wds7654321(4171752)    | swim        |  1700 | 152607152 |
+---------+------------------------+-------------+-------+-----------+

test_02 can read data written by test_01, confirming that all clusters share the same underlying storage.

What happens when a user has no cluster access

Connect to the instance using the admin account and create a third user without granting any cluster access.

CREATE USER test_03 IDENTIFIED BY 'testPassword';
GRANT ALL ON *.* TO test_03;

Connect as test_03 and run a query:

SELECT * FROM golds_log;

The query fails with the following error:

ERROR 1105 (HY000): errCode = 2, detailMessage = 90363 have no queryable replicas. err: 90364's backend -1 does not exist or not alive, or you may not have permission to access the current cluster, clusterName=null

This error means the account has no access to any cluster in the instance. Grant USAGE_PRIV on at least one cluster to resolve it.