江龍滔，SphereEx 中介軟體研發工程師，Apache ShardingSphere Committer。主要負責 DistSQL 及安全相關特性的創新與研發。

蘭城翔，SphereEx 中介軟體研發工程師，Apache ShardingSphere Committer。目前專注於 DistSQL 的設計和研發。

背景

從 Apache ShardingSphere 5.0.0-Beta 版本釋出以來，DistSQL 迅速走進了使用者的視野，因其“動態生效、無需重啟”的獨有優勢和接近標準 SQL 的優美語法，越來越受到開發者和運維人員的喜愛。隨著 5.0.0 和 5.1.0 版本的迭代，ShardingSphere 社群再次為 DistSQL 新增了大量語法，帶來了眾多實用的特性。

本文將從“叢集治理”的角度，為大家解讀 DistSQL 的最新功能。

ShardingSphere 叢集

在典型的由 ShardingSphere-Proxy 構成的叢集中，一般包含多個計算節點，多個儲存節點，如圖：

為了便於交流，在 ShardingSphere 中，我們將 Proxy 稱為計算節點，將 Proxy 管理的分散式資料庫資源（如 ds 0，ds1），稱為資源或儲存節點。

其中，多個 Proxy 計算節點連線到同一註冊中心，共享配置和規則，並互相感知線上狀態。與此同時，這些計算節點也共享底層的儲存節點，它們可以同時對儲存節點進行讀寫操作。此時，使用者的應用程式連線到任一計算節點上，都能進行等效的操作。

透過這種叢集架構，在計算資源不足時，使用者可以快速的對 Proxy 進行水平擴充套件，也能夠在一定程度上降低單點故障帶來的風險，提高系統可用性。

應用程式與計算節點間還可以增加負載均衡的機制，此處不擴充套件。

計算節點治理

計算節點治理，適用於 Cluster 模式，關於模式的更多資訊可參考《 ShardingSphere Mode 執行模式詳解》。

叢集準備

這裡以單機模擬三個 Proxy 計算節點為例，使用如下模式配置：

mode:
  type: Cluster
  repository:
    type: ZooKeeper
    props:
      namespace: governance_ds
      server-lists: localhost:2181
      retryIntervalMilliseconds: 500
      timeToLiveSeconds: 60
      maxRetries: 3
      operationTimeoutMilliseconds: 500
  overwrite: false

分別執行啟動命令：

sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3307sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3308sh %SHARDINGSPHERE_PROXY_HOME%/bin/start.sh 3309

三個 Proxy 例項啟動成功後，計算節點叢集就準備好了。

SHOW INSTANCE LIST

使用客戶端連線到任一計算節點，如 3307：

mysql -h 127.0.0.1 -P 3307 -u root -p

檢視例項列表：

mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+---------+| instance_id    | host      | port | status  |
+----------------+-----------+------+---------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled || 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled |+----------------+-----------+------+---------+

各欄位含義如下：

instance_id ：例項的 id，目前由 host 和 port 組成；

host ：主機地址；

port : 埠號；

status : 例項的狀態， enabled 和 disabled 分別表示啟用和禁用狀態。

DISABLE INSTANCE

DISABLE INSTANCE 語句用於將指定計算節點設定為禁用狀態。需要注意的是，該指令並不會終止目標例項的程式，只是在邏輯上對其進行停用。 DISABLE INSTANCE 支援以下語法形式：

DISABLE INSTANCE 10.7.5.35@3308;# 或DISABLE INSTANCE IP=10.7.5.35, PORT=3308;

示例：

mysql> DISABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 rows affected (0.02 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+| instance_id    | host      | port | status   | 
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  || 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |+----------------+-----------+------+----------+

執行 DISABLE INSTANCE 語句後，透過再次查詢能夠看到，埠為 3308 的例項狀態已更新為 disabled，表示該計算節點已被禁用。

此時若有連線至 10.7.5.35@3308 的客戶端，執行任意 SQL 均會提示異常：

1000 - Circuit break mode is ON.

?提示：暫不允許禁用當前接受指令的計算節點，如果向 10.7.5.35@3309 傳送 DISABLE INSTANCE 10.7.5.35@3309; 將會收到異常提示。

ENABLE INSTANCE

ENABLE INSTANCE 語句用於將指定計算節點設定為啟用狀態。 ENABLE INSTANCE 也支援以下語法形式：

示例：

mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+| instance_id    | host      | port | status   | 
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  || 10.7.5.35@3308 | 10.7.5.35 | 3308 | disabled |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |+----------------+-----------+------+----------+
mysql> ENABLE INSTANCE 10.7.5.35@3308;
Query OK, 0 rows affected (0.01 sec)
mysql> SHOW INSTANCE LIST;
+----------------+-----------+------+----------+| instance_id    | host      | port | status   | 
+----------------+-----------+------+----------+
| 10.7.5.35@3309 | 10.7.5.35 | 3309 | enabled  || 10.7.5.35@3308 | 10.7.5.35 | 3308 | enabled  |
| 10.7.5.35@3307 | 10.7.5.35 | 3307 | enabled  |+----------------+-----------+------+----------+

執行 ENABLE INSTANCE 語句後，透過再次查詢能夠看到，埠為 3308 的例項狀態已恢復為啟用狀態。

計算節點引數管理

在此前的文章《 SCTL 涅槃重生：投入 RAL 的懷抱》中，我們為讀者解讀了 SCTL（ShardingSphere Control Language）到 RAL（Resource & Rule Administration Language）的演化，同時帶來了全新的 SHOW VARIABLE 和 SET VARIABLE 語法。不過在 5.0.0-Beta 版本中， VARIABLE 類別的 DistSQL RAL 僅僅包含以下三個語句：

SET VARIABLE TRANSACTION_TYPE = xx; （LOCAL, XA, BASE）SHOW VARIABLE TRANSACTION_TYPE;SHOW VARIABLE CACHED_CONNECTIONS;

在大量的客戶反饋中，我們發現查詢和修改 Proxy 的 props 配置（位於 server.yaml 中）也是一項高頻操作。於是，從 5.0.0 GA 版本開始，DistSQL RAL 增加了對 props 配置的支援。

SHOW VARIABLE

首先讓我們回顧一下 props 配置的內容：

props:
  max-connections-size-per-query: 1
  kernel-executor-size: 16  # Infinite by default.  proxy-frontend-flush-threshold: 128  # The default value is 128.  proxy-opentracing-enabled: false  proxy-hint-enabled: false  sql-show: false  check-table-metadata-enabled: false  show-process-list-enabled: false    # Proxy backend query fetch size. A larger value may increase the memory usage of ShardingSphere Proxy.    # The default value is -1, which means set the minimum value for different JDBC drivers.  proxy-backend-query-fetch-size: -1  check-duplicate-table-enabled: false  proxy-frontend-executor-size: 0 # Proxy frontend executor size. The default value is 0, which means let Netty decide.    # Available options of proxy backend executor suitable: OLAP(default), OLTP. The OLTP option may reduce time cost of writing packets to client, but it may increase the latency of SQL execution    # and block other clients if client connections are more than `proxy-frontend-executor-size`, especially executing slow SQL.  proxy-backend-executor-suitable: OLAP
  proxy-frontend-max-connections: 0 # Less than or equal to 0 means no limitation.  sql-federation-enabled: false    # Available proxy backend driver type: JDBC (default), ExperimentalVertx  proxy-backend-driver-type: JDBC

現在，使用者可以透過如下語法進行互動式查詢：

SHOW VARIABLE PROXY_PROPERTY_NAME;

例如：

mysql> SHOW VARIABLE MAX_CONNECTIONS_SIZE_PER_QUERY;
+--------------------------------+| max_connections_size_per_query |
+--------------------------------+| 1                              |
+--------------------------------+1 row in set (0.00 sec)
mysql> SHOW VARIABLE SQL_SHOW;
+----------+| sql_show |
+----------+| false    |
+----------+1 row in set (0.00 sec)
……

?提示：DistSQL 語法中，引數名稱使用下劃線分隔，與檔案中不同。

SHOW ALL VARIABLES

由於 Proxy 中的引數眾多，使用者也可以透過 SHOW ALL VARIABLES 的方式查詢全部引數值：

mysql> SHOW ALL VARIABLES;
+---------------------------------------+----------------+| variable_name                         | variable_value |
+---------------------------------------+----------------+
| sql_show                              | false          || sql_simple                            | false          |
| kernel_executor_size                  | 0              || max_connections_size_per_query        | 1              |
| check_table_metadata_enabled          | false          || proxy_frontend_database_protocol_type |                |
| proxy_frontend_flush_threshold        | 128            || proxy_opentracing_enabled             | false          |
| proxy_hint_enabled                    | false          || show_process_list_enabled             | false          |
| lock_wait_timeout_milliseconds        | 50000          || proxy_backend_query_fetch_size        | -1             |
| check_duplicate_table_enabled         | false          || proxy_frontend_executor_size          | 0              |
| proxy_backend_executor_suitable       | OLAP           || proxy_frontend_max_connections        | 0              |
| sql_federation_enabled                | false          || proxy_backend_driver_type             | JDBC           |
| agent_plugins_enabled                 | false          || cached_connections                    | 0              |
| transaction_type                      | LOCAL          |+---------------------------------------+----------------+21 rows in set (0.01 sec)

SET VARIABLE

動態管理資源和規則，是 DistSQL 獨有的優勢。現在，使用 SET VARIABLE 語句也可以動態地更新 props 引數了。例如：

# 開啟 SQL 日誌輸出SET VARIABLE SQL_SHOW = true;# 開啟 hint 功能SET VARIABLE PROXY_HINT_ENABLED = true;# 開啟聯邦查詢SET VARIABLE SQL_FEDERATION_ENABLED = true;
……

?提示：

以下引數可以透過 SET VARIABLE 語句進行修改，但新值僅在 Proxy 重啟後生效：

kernel executorsize

proxy frontendexecutor_size

proxy backenddriver_type
以下引數為只讀，不可修改：

cached_connections

其他未說明的引數，修改後立即生效。

儲存節點管理

在 ShardingSphere 中，儲存節點並不是直接與計算節點繫結的。由於同一個儲存節點可能在不同邏輯庫（schema）中同時扮演不同的角色，用於實現不同的業務邏輯，因此，儲存節點始終是關聯在某個邏輯庫中的。

在 DistSQL 中，透過 RESOURCE 相關語句來進行儲存節點的管理，包括：

ADD RESOURCE；
ALTER RESOURCE；
DROP RESOURCE；
SHOW SCHEMA RESOURCES。

邏輯庫準備

RESOURCE 相關語句僅作用於邏輯庫，因此在操作之前，需要先建立並使用 USE 命令成功選擇一個邏輯庫：

DROP DATABASE IF EXISTS sharding_db;CREATE DATABASE sharding_db;USE sharding_db;

ADD RESOURCE

ADD RESOURCE 語法支援以下形式：

指定 HOST、PORT、DB

ADD RESOURCE resource_0 (
    HOST=127.0.0.1,
    PORT=3306,
    DB=db0,
    USER=root,
    PASSWORD=root
);

指定 URL

ADD RESOURCE resource_1 (
    URL="jdbc:mysql://127.0.0.1:3306/db1?serverTimezone=UTC&useSSL=false",
    USER=root,
    PASSWORD=root
);

同時，以上兩種語法形式，都支援擴充套件引數 PROPERTIES。該引數用於指定 Proxy 與儲存節點間連線池的屬性配置，例如：

ADD RESOURCE resource_2 (
    HOST=127.0.0.1,
    PORT=3306,
    DB=db2,
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=10)
),resource_3 (
    URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=UTC&useSSL=false",
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
);

?提示：僅 URL 形式支援指定 JDBC 連線引數，如 useSSL。

ALTER RESOURCE

ALTER RESOURCE 用於修改已有儲存節點的連線資訊，如改變連線池大小、修改 JDBC 連線引數等。

在語法形式上， ALTER RESOURCE 與 ADD RESOURCE 完全一致，例如：

ALTER RESOURCE resource_2 (
    HOST=127.0.0.1,
    PORT=3306,
    DB=db2,
    USER=root,
    PROPERTIES("maximumPoolSize"=50)
),resource_3 (
    URL="jdbc:mysql://127.0.0.1:3306/db3?serverTimezone=GMT&useSSL=false",
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=50,"idleTimeout"="30000")
);

?提示：由於修改儲存節點可能導致後設資料變更或應用資料異常，ALTER RESOURCE 不能修改連線的目標 DB，僅可修改以下內容：

使用者名稱
使用者密碼
PROPERTIES 連線池引數
JDBC 引數

DROP RESOURCE

DROP RESOURCE 用於從邏輯庫中刪除儲存節點，不會刪除儲存節點中的任何資料。語法示例如下：

DROP RESOURCE resource_0, resource_1;

?提示：為保護資料正確，被規則引用的儲存節點是無法刪除的。

例如 t order 為分片表，它的實際表分佈於 resource0 和 resource 1 中，那麼 resource0 和 resource 1 即被 torder 的分片規則引用，不能刪除。

SHOW SCHEMA RESOURCES

DROP RESOURCE resource_0, resource_1;

# 查詢當前 use 的邏輯庫中的儲存節點SHOW SCHEMA RESOURCES;# 查詢指定邏輯庫中的儲存節點SHOW SCHEMA RESOURCES FROM sharding_db;

示例：在透過前述的 ADD RESOURCE 命令新增 4 個儲存節點後，執行查詢操作：

由於查詢結果列數較多，只擷取部分。

以上就是透過 DistSQL 動態管理儲存節點的方式，與修改 YAML 檔案相比，DistSQL 的執行是實時的，無需重啟 Proxy 計算節點，讓線上業務更安全。

同時，透過 DistSQL 執行的變更會透過註冊中心實時同步到叢集內的其他計算節點，而連線到任一計算節點的客戶端，也能即時查詢到儲存節點的變化。

這，就是叢集治理的魅力。

結語

以上就是本次分享的全部內容，如果讀者對 Apache ShardingSphere 有任何疑問或建議，歡迎在 GitHub issue 列表提出，或可前往中文社群交流討論。 GitHub issue：

貢獻指南：

中文社群：

參考資訊：

1.ShardingSphere-Proxy 快速入門： https://shardingsphere.apache.org/document/5.1.0/cn/quick-start/shardingsphere-proxy-quick-start/

2.DistSQL RDL： https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/distsql/syntax/rdl/resource-definition/

3.DistSQL RQL： https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/distsql/syntax/rql/resource-query/

4.DistSQL RAL： https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/distsql/syntax/ral/

特性更新！DistSQL 叢集治理能力詳解

背景