計算節點執行相關
計算節點啟動說明
- 啟動計算節點，可以切換到/usr/local/hhdb/hhdb-server/bin目錄下，再執行啟動指令碼，或者直接加上路徑:sh /usr/local/hhdb/hhdb/bin/hotdb_server start；
- 配置庫複製同步狀態會影響計算節點啟動，計算節點啟動或者發生高可用切換Online時配置庫必須保證複製追上；
- 儲存節點複製同步狀態會影響計算節點啟動，透過在server.xml中配置引數waitSyncFinishAtStartup 的true/false屬性控制計算節點啟動時是否等待儲存節點複製追上，預設需等待；
- 啟動計算節點時,若儲存節點連線狀態異常，可透過修改server.xml中的配置引數masterSourceInitWaitTimeout，控制資料節點中主儲存節點是否重新初始化及初始化超時時間，具體控制邏輯參考計算節點啟動時對邏輯庫可用的判斷;
影響計算節點啟動失敗的原因可能是多種多樣的，包括但不限於： - 軟硬體環境異常：例如指令碼校驗無法透過，磁碟空間不足，可用記憶體不足，Java版本不匹配等;
- 配置庫異常：例如配置庫無法連線，配置錯誤等;
- 節點異常：例如資料節點無法正常連線或無法正常初始化等;
- 授權異常：例如USB-Key服務異常，授權節點超出限制，授權過期等;
- XA異常：例如XA RECOVER失敗等;
- 埠被佔用：例如埠已被其他程式佔用，或者啟動了多個計算節點服務等;
- 複製異常：例如配置了啟動時等待複製追上，實際資料節點的複製一直存在延遲，無法追上等;
- 叢集異常：例如叢集無法達成共識，啟動時存在網路分割槽，各節點時間不同步等。
計算節點啟動時對邏輯庫可用的判斷
為保證垂直拆分場景下，出現資料節點不可用狀態時，與之不相關的不同邏輯庫之間的業務場景不受影響，計算節點在啟動時，對所有邏輯庫的可用狀態做了特殊判斷處理，說明如下：
-
若配置的主儲存節點為可用狀態，實際該儲存節點無法連線，則計算節點啟動時，會等待masterSourceInitWaitTimeout配置的時間（預設：300s）,判斷該儲存節點是否真實不可連線，若在此期間，該儲存節點重連無異常，則該節點初始化成功；
-
如果資料節點初始化失敗且無可用邏輯庫，或資料節點下無儲存節點，則計算節點無法啟動，日誌提示：04/13 10:50:54.644 ERROR [main] (HotdbServer.java:436) -datanodes:[3] init failed. System exit.
-
只要存在某個邏輯庫對應的資料節點均可用，則可以啟動計算節點，對應邏輯下的表可以正常操作。如果其他邏輯庫下有不可用的節點，則該邏輯庫下的表不能正常讀寫，客戶端提示：ERROR 1003 (HY000): DATABASE is unavailable when datanodes:[datanode_id] unavailable.
例如：A邏輯庫包含1,2兩個節點，B邏輯庫包含3,4兩個節點。如果1、2節點不可用，3、4節點可用，則計算節點可以啟動，B邏輯庫下的表可以正常操作，A邏輯庫下的表無法進行讀寫；如果1、3節點不可用，則計算節點無法啟動。
- 判斷某個節點是否可用，跟儲存節點在配置庫的狀態以及儲存節點實際可用狀態有關，要求配置狀態與儲存節點狀態要一致，否則會影響計算節點的啟動。計算節點啟動時連線配置庫配置的可用儲存節點，如果均能連線，則視為可用。如果某個配置為可用的儲存節點無法連線，且該資料節點下所有其他儲存節點都配置為不可用或配置為可用但實則無法連線，則視為該資料節點不可用。每個節點至少應配置一個可用儲存節點，否則無法啟動計算節點。具體情況如下：
1.主從儲存節點均配置為可用
如果主從儲存節點均可以連線，則該節點可用。如果主庫無法連線，從庫可連線，則會發生切換，將主庫置為不可用，並且使用從庫。如果主庫可以連線，從庫無法連線，則使用主庫，從庫會置為不可用。如果主從資料庫均無法連線，則該節點不可用。
2.主庫配置不可用，從庫配置可用
如果從庫可以連線，則使用從庫，此節點可用。如果從庫無法連線，則該節點不可用。
3.主庫配置可用，從庫配置不可用
如果主庫可以連線，則使用主庫，此節點可用。如果主庫無法連線，則該節點不可用。
儲存節點服務端引數校驗
為了保證資料的一致性，計算節點在啟動的時候，將對儲存節點例項的引數進行校驗。針對不同的引數，如果引數配置不符合校驗規則，計算節點將報告警告資訊，或者不能啟動。計算節點對儲存節點例項的引數要求有兩種：一種是所有的儲存節點例項的引數需一致；另一種是所有的儲存節點例項的引數必須為固定值。
要求設定為固定值的引數
對於下列儲存節點例項的引數，計算節點要求設定為統一的固定值：
1.completion_type必須為NO_CHAN, 如果出現該引數不符合規範，則動態載入失敗；
2.innodb_rollback_on_timeout需要為ON，且任何時候SHOW [GLOBAL|SESSION] VARIABLES顯示出來的innodb_rollback_on_timeout引數都為on，說明如下：
-
如果innodb_rollback_on_timeout引數全為off， 則計算節點允許載入成功，但計算節點的行為將等同於innodb_rollback_on_timeout引數為on時的事務回滾方式，且配置校驗時給出提示：
且動態載入時日誌輸出：innodb_rollback_on_timeout=off is not supported, HotDB behavior will be equivalent to innodb_rollback_on_timeout = on； -
如果innodb_rollback_on_timeout引數儲存節點間不一致，動態載入失敗，且動態載入時，為off的儲存節點日誌輸出，MySQL variables 'innodb_rollback_on_timeout' is not consistent,the current value is OFF ,neet to bu changed to ON , 為on的儲存節點日誌輸出MySQL variables 'innodb_rollback_on_timeout' is not consistent,the current value is ON；
3.read_only，引數說明如下：
如果主儲存節點的引數read_only=1，計算節點將拒絕啟動，動態載入失敗；
如果從機的引數read_only=1且配置了切換到該從機的配置規則，計算節點可以啟動，RELOAD失敗；
如果從機的引數read_only=1且沒有配置切換到該從機的配置規則，計算節點可以啟動，reload如果無其它錯誤則成功；
要求所有節點配置一致的引數
對於下列儲存節點例項的引數，計算節點要求儲存節點間的引數值設定為一致：
- autocommit
- transaction_isolation
- div_precision_increment
若以上引數在儲存節點間配置不一致，計算節點將給出警告資訊。對於transaction_isolation引數，計算節點以設定的最高隔離級別為準，若最高配置的值高於REPEATABLE-READ，將使用SERIALIZABLE；若最低配置的值低於REPEATABLE-READ，計算節點將使用REPEATABLE-READ模式。
要求不能超過計算節點配置的引數
考慮到客戶端傳送超大SQL會有威脅到計算節點的可能（目前尚未發現實際案例），計算節點可以配置MAX_ALLOWED_PACKET，控制客戶端傳送給計算節點的SQL最大包大小，該引數可在server.xml中透過引數名maxAllowedPacket預置，如果計算節點的maxAllowedPacket預設值大於1024M，日誌會給warning提示，且管理平臺配置校驗會給出提示。
管理端資訊監控
HHDB Server為客戶提供了一套功能完善、操作便捷的資訊監控、統計與服務管理功能。使用者可以透過MySQL Client登入計算節點的監控管理端檢視詳細資訊，詳細說明請參考計算節點管理命令文件。
管理端命令
使用者可以登入管理端（預設埠：3325）使用show @@help命令檢視支援的管理端命令和相應的作用。
root> mysql -uroot -proot -P3325 -h192.168.200.201
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 992081
Server version: 5.7.42 HHDB-14.0.0 HHDB Server
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql> show @@help;
+-------------------------------------------+------------------------------+
| statement | description |
+-------------------------------------------+------------------------------+
| check @@datasource_config | 檢查儲存節點引數配置資訊 |
| check @@route [db_name.tb_name | tb_name] | 檢測分片表資料路由正確性 |
| kill @@connection [connection_id] | 將某個指定的連線關閉 |
| onlineddl "[DDLSTATEMENT]" | 執行onlineddl |
| rebuild @@pool | 重建所有節點當前可用儲存節點 |
| reload @@config | 重新讀取配置資訊 |
...省略更多內容，可自行登陸檢視...
管理端操作
使用者可以輸入相應的命令以監控計算節點的服務情況，如顯示儲存節點資訊：
mysql> show @@datasource;
|----+----+-----------------------+------+--------+-------------+------+--------+--------+------+------+--------------------+--------------+--------+-------------+-----------------+
| dn | ds | name | type | status | host | port | schema | active | idle | size | unavailable_reason | flow_control | idc_id | listener_id | listener_status |
| ---| ---| --------------------- | ---- | ------ | ----------- | ---- | ------ | ------ | ---- | ---- | ------------------ | ------------ | ------ | ----------- | --------------- |
| 17 | 17 | 10.10.0.140_3313_db01 | 1 | 1 | 10.10.0.140 | 3313 | db01 | 0 | 45 | 45 | NULL | 0/64 | 1 | 8 | 1 |
...省略更多內容，可自行登陸檢視...
前端連線數限制
計算節點支援限制前端連線數功能，出現訪問過載時可輔助限制流量。使用方法為：在server.xml中進行配置：
<property name="maxConnections">5000</property><!-- 前端最大連線數 -->
<property name="maxUserConnections">0</property><!--使用者前端最大連線數, 0為不限制-->
- maxConnections為前端最大連線數，預設5000；
- maxUserConnections為前端最大使用者連線數，預設0為不限制；
同時支援具有super許可權的使用者在服務埠set global max_connections=1; set global max_user_connections=0;進行修改。
可以用SHOW VARIABLES來檢視當前的連線數限制情況。
後端連線池管理
計算節點啟動及執行過程中會與儲存節點之間建立連線，在新增儲存節點時，可透過四個配置控制連線數：
- 最大連線數：計算節點與儲存節點之間可建立的最大連線數，超過即SQL無法正常執行；
- 初始連線數：計算節點與儲存節點之間建立的初始連線數；
- 最小空閒連線數：計算節點與儲存節點之間建立的最小空閒連線數；
- 最大空閒連線數：計算節點與儲存節點之間建立的最大空閒連線數。
當定時檢測執行緒發現連線池裡面空閒連線小於最小空閒，建立連線；大於最大空閒，關閉連線。即：最小空閒≤連線池的空閒連線個數≤最大空閒，最大、最小空閒連線數主要控制連線池內的空閒連線數在一定範圍內。
例如：
以單個計算節點舉例（多計算節點服務各自限制連線數，也即極端情況下，儲存節點連線數可能達到N倍），儲存節點配置： 最大連線數4200，初始化連線數是32， 最小空閒連線數64 ，最大空閒連線數：512
那麼計算節點在啟動的時候，會與每個儲存節點建立32個後端連線，定時檢測執行緒檢測時發現當前連線數不夠最小空閒即增加到最小空閒連線64個；
此時若有一個2048併發的場景對計算節點壓測，會發現連線池可用連線數不夠用，計算節點會自動增加與儲存節點的連線數。
當壓測結束後，這些連線不會立即銷燬，會等到空閒檢測週期檢測：如果空閒狀態（即管理端show @@backend標記為Idle狀態）的連線大於512 ，則銷燬多餘的連線到512個；如果小於512 就保持原樣。
若需要空閒連線狀態回到初始化狀態，可以在計算節點執行過程中，參考計算節點管理命令文件重建連線池rebuild @@pool 相關章節重建連線池，即恢復到初始連線狀態。
磁碟空間使用限制
因磁碟空間不足會導致計算節點無法正常執行等諸多問題，計算節點在自動部署時會檢測計算節點安裝目錄所在磁碟的剩餘空間是否大於10G，同時，在寫臨時檔案時也會檢測磁碟的剩餘空間，具體如下：
使用者建立會話後執行例如複雜跨庫JOIN等操作時，必要時會在計算節點安裝目錄下寫入臨時檔案。寫入臨時檔案的同時，計算節點若檢測發現安裝目錄所在磁碟的剩餘空間不足，則終止當前會話並報錯與記錄日誌。
計算節點日誌記錄error級別日誌如下，終止會話時提示資訊與之相同：
2019-06-10 18:03:24.423 [ERROR] [DISKSPACE] [Employee-2] cn.hotpu.hotdb.mysql.nio.handler.MultiNodeHandler(88) - session[1606] was killed,due to less than 1G space left on device,and the size of temp-file is larger than the usable space.
etl使用者（用於資料抽取）
配置了etl的使用者較普通使用者在資料抽取時可降低記憶體消耗，具有更高的穩定性和資料抽取效率，具體使用配置說明如下：
- 在管理平臺資料庫使用者中新增使用者
計算節點配置庫新增使用者為etl使用者（etl_users和ETL使用者列表為固定引數值，只需修改test_user@%）。
insert into hotdb_config_info values('etl_users','test_user@%','ETL使用者列表');
-
開啟引數enableCursor，動態載入使配置生效
-
使用etl使用者做資料匯出（以mysqldump為例）
mysqldump -utest_user -pyy123456 -P3323 -h192.168.171.21 --set-gtid-purged=OFF --no-tablespaces --skip-triggers --single-transaction --default-character-set=utf8 --no-create-info --complete-insert --compact --skip-tz-utc hotdb customer_auto >/usr/local/etl_temp/etl_auto.sql
錯誤碼
若要了解計算節點錯誤碼詳情，請參考計算節點錯誤碼文件。
若要了解管理平臺錯誤碼詳情，可以點選"幫助中心">>"API介面說明"頁面中的【狀態碼】檢視錯誤碼詳情。
動態載入（RELOAD）
計算節點可在不重啟服務的情況下，線上載入配置資訊。透過"動態載入"功能可立即生效的引數請參考計算節點引數說明。
動態載入有兩種方式，一種是登入管理端（3325）執行：reload @@config命令；一種是登入管理平臺，點選選單欄右上角"動態載入"按鈕，將新增配置專案動態載入到計算節點中進行使用。如下圖所示：
為了保證計算節點正確載入配置資訊，在執行動態載入前，可先校驗配置資訊。動態載入過程中，若遇到主備配置庫、主備儲存節點切換，提示使用者並提供強制停止切換並動態載入和取消動態載入兩種選擇方案。
配置校驗
登入管理平臺，選擇"配置"->配置校驗進入配置校驗皮膚，點選"開始校驗"按鈕，將校驗關係叢集資料庫視覺化管理平臺中配置校驗選單中的配置項，若有配置項不正確，可根據錯誤提示，修改相應的配置：
透過計算節點管理端執行reload @@config命令動態載入時，預設也會先進行配置校驗，校驗透過後才允許動態載入。
死鎖檢測
在關係叢集資料庫系統中，若死鎖發生在兩個資料節點下的儲存節點間，儲存節點的死鎖檢測機制將無法檢測到死鎖。
下面表格中的操作，描述了兩個資料節點產生死鎖的過程。會話一與會話二分別在兩個資料節點上執行DELETE操作：
| 會話一 | 會話二 | |
|---|---|---|
| 會話一開啟事務 | start transaction; | |
| 會話二開啟事務 | start transaction; | |
| 會話一在DNID為15的資料節點上執行DELETE語句 | delete from customer where dnid=15 and id=1; | |
| 會話二在DNID為13的資料節點上執行DELETE 語句 | delete from customer where dnid=13 and id=4; | |
| 會話一在DNID為13的資料節點上執行DELETE語句；DELETE操作將被會話二阻塞 | delete from customer where dnid=13 and id=4; | |
| 會話二在DNID為15的資料節點上執行DELETE語句；此操作將被會話一阻塞；因會話一被會話二阻塞，會話二也被會話一阻塞，此時將產生死鎖 | delete from customer where dnid=15 and id=1; |
上述情況中，會話一與會話二互相被阻塞，將產生死鎖。因是在兩個資料節點下的儲存節點間，儲存節點無法檢測到死鎖的存在。
在HHDB Server關係叢集資料庫系統中，計算節點可檢測到多個資料節點下的儲存節點間的死鎖，並回滾開銷最少的事務。
在計算節點的配置檔案server.xml中，將死鎖檢測週期設定為大於0的值，將開啟死鎖的自動檢測功能。預設情況下，死鎖檢測是開啟狀態，檢測週期為3000ms。
<property name=" deadlockCheckPeriod ">3000</property>
當deadlockCheckPeriod值設定為0時，將不啟動死鎖檢測功能。
在開啟計算節點的死鎖檢測時，再次執行上述的DELETE操作：
會話一，開啟事務：
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
會話二，開啟事務：
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
會話一，在DNID為15的資料節點上執行DELETE語句：
mysql> delete from customer where dnid=15 and id=1;
Query OK, 1 row affected (0.00 sec)
會話二，在DNID為13的資料節點上執行DELETE 語句
mysql> delete from customer where dnid=13 and id=4;
Query OK, 1 row affected (0.00 sec)
會話一，在DNID為13的資料節點上執行DELETE語句；DELETE操作將被會話二阻塞：
mysql> delete from customer where dnid=13 and id=4;
會話二，在DNID為15的資料節點上執行DELETE語句；此操作將被會話一阻塞；因會話一被會話二阻塞，會話二也被會話一阻塞，此時將產生死鎖。
mysql> delete from customer where dnid=15 and id=1;
Query OK, 1 row affected (1.59 sec)
計算節點檢測到死鎖，回滾了會話一的事務：
mysql> delete from customer where dnid=13 and id=4;
ERROR 1213 (HY000): Deadlock found when trying to get lock; try restarting transaction
注意
由於儲存節點5.7及以上版本，事務中出現死鎖回滾後，不會立即開啟新事務。參考官方BUG連結：https:// bugs.mysql.com/bug.php?id=98133。HHDB
Server針對上述BUG做了相容處理：對鎖超時、死鎖檢測、後端連線斷開，儲存節點5.7及以上版本會根據前端連線autocommit判斷是否要開啟新事務。
SQL報錯日誌記錄
若執行SQL時返回以下情況的報錯資訊，計算節點會將其記錄到計算節點日誌（hotdb-unusualsql.log）中：
- 主鍵唯一鍵衝突或外來鍵約束不滿足導致的ERROR資訊（即儲存節點錯誤碼1062、1216、1217、1451、1452、1557、1761、1762、3008）；
- 資料溢位（即儲存節點錯誤碼1264、1690、3155、3669）和資料型別轉換或隱式轉換導致資料截斷（即儲存節點錯誤碼1265、1292、1366）的情況；
- 涉及binlog不安全語句（即儲存節點錯誤碼1418、1592、1663、1668、1669、1671、1673、1674、1675、1693、1714、1715、1716、1719、1722、1724、1727、1785、3006、3199、3570、3571、MY-010908、MY-013098）；
- 對分片欄位不是自增欄位的分片表做INSERT操作時，由外部指定自增值的INSERT的情況；
- UPDATE語句中出現MATCH和AFFECT不相符的情況；
- DELETE出現刪除0行的情況；
- UPDATE或DELETE AFFECT超過10000行的情況；
- 在HINT語句中使用了INSERT、UPDATE、DELETE和DDL語句的情況；
- DDL語句執行出現報錯資訊的情況；除此之外，在以下兩種情況下會有額外日誌記錄：
- CREATE TABLE或ALTER TABLE時指定的表的字符集或欄位的字符集，與儲存節點的字符集或連線使用的字符集不一致時。
- CREATE TABLE或ALTER TABLE分片表，主鍵或唯一鍵不包含分片欄位，且沒有使用全域性唯一約束來保證欄位唯一性時。
- 發生部分提交的情況，即部分節點已經發出COMMIT後，其餘節點沒有發出COMMIT但連線斷開的情況，或其餘部分後端連線發出COMMIT後無響應且連線斷開的情況，會記錄整個事務到計算節點日誌；
- 發生語法錯誤的情況；
- 執行因缺少路由規則無法路由的SQL的情況，例如INSERT不存在的ROUTE規則；
- 執行被SQL防火牆攔截的SQL的情況；
- 執行超時的SQL的情況；
- 發生死鎖被殺的事務的情況；
- 發生因儲存節點切換等原因被殺掉的事務的情況；
- 執行鎖超時回滾的SQL的情況；
- 執行KILL命令後KILL掉的SQL的情況；
- 發生被ROLLBACK的SQL的情況；
- 前端連線異常斷開回滾的SQL的情況；
- 後端連線異常斷開或其它異常導致回滾的情況；
- 計算節點意外拋異常的情況。
如果上述記錄的SQL過長導致SQL語句被擷取，還會額外記錄WARNING資訊。
例如，執行一條出現主鍵衝突的SQL如下：
mysql> insert into table01 (id,title,author,submission_date) values (3,"apple", "apple pie", '2019-10-11-20-05');
ERROR 1062 (23000): Duplicate entry '3' for key 'PRIMARY'
檢視計算節點日誌（hotdb-unusualsql.log）：
2019-10-12 15:27:45.051 [INFO] **[UNUSUALSQL]** [$NIOREACTOR-7-RW] cn.hotpu.hotdb.mysql.nio.MySQLConnection(415) - ERROR 1062:Duplicate entry '3' for key 'PRIMARY' [frontend:[thread=$NIOREACTOR-7-RW,id=453,user=root,host=192.168.210.225,port=3323,localport=65442,schema=DBY]; backend:null; frontend_sql:insert into table01 (id,title,author,submission_date) values (3,"apple", "apple pie", '2019-10-11-20-05');backend_sql:null]
又如，執行一條被SQL防火牆攔截SQL如下：
mysql> select * from test;
ERROR 1064 (HY000): Intercepted by sql firewall, because: not allowed to execute select without where expression
檢視計算節點日誌（hotdb-unusualsql.log）：
2019-10-14 15:41:42.246 [INFO] **[UNUSUALSQL]** [$NIOExecutor-1-2] cn.hotpu.hotdb.route.RouteService(415) - ERROR 10029:not pass sql firewall [frontend:[thread=$NIOExecutor-1-2,id=1433,user=root,host=192.168.210.225,port=3323,localport=64658,schema=DBY]; backend:null; frontend_sql:null; backend_sql:null] [DBY.count]=33
注意
儲存節點錯誤碼解釋可參考官方文件：https:// dev.mysql.com/doc/refman/8.0/en/server-error-reference.html
該類日誌資訊預設儲存在計算節點安裝目錄logs/extra/unusualsql目錄下的hotdb_unusualsql.log檔案中。若日誌未記錄至檔案，可檢查計算節點安裝目錄conf目錄下的log4j2.xml下，是否存在以下配置：
<RollingFile
name="Unusualsql"
filename="${sys:HOTDB_HOME}/logs/extra/unusualsql/hotdb-unusualsql.log"
filepattern="${sys:HOTDB_HOME}/logs/extra/unusualsql/hotdb-unusualsql-%d{yyyy-MM-dd-HH-mm-ss}.log">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-4p] [%marker] [%t] %c(%L) - %msg%n"/>
<Policies>
<SizeBasedTriggeringPolicy size="100 MB"/>
</Policies>
<!-- 只記錄unusual sql日誌 -->
<filters>
<MarkerFilter marker="UNUSUALSQL" onMatch="ACCEPT" onMismatch="DENY"></MarkerFilter>
</filters>
<DefaultRolloverStrategy max="1000"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Unusualsql"/>
</Root>
</Loggers>
只讀計算節點例項
計算節點支援開啟只讀模式（instanceReadOnly）來平衡當前主計算節點的壓力，或使用只讀計算節點例項抽取資料做資料分析，一般適用於備計算節點或災備模式下的災備機房計算節點。
計算節點開啟只讀方式
修改server.xml中的instanceReadOnly為1開啟只讀計算節點，重啟計算節點後生效；
管理端執行online_readonly直接開啟計算節點只讀模式，online_readwrite可直接關閉計算節點只讀模式；
root@192.168.210.79:(none) 8.0.30 03:50:51> online_readonly;
Query OK, 1 row affected, 1 warning (0.03 sec)
Info (Code 10260): Online_readOnly command executed successfully and the instanceReadOnly parameter has been set to 1.
online_readwrite命令在HA模式下等同於online，在災備模式主節點下相當於online_dr，會導致計算節點高可用切換或機房切換，業務需謹慎使用
可透過show @@server介面中的mode欄位檢視是否開啟了只讀
開啟只讀的計算節點服務端只可執行DQL語句、SET會話級引數、show語句等；管理端涉及寫操作的命令都不能執行，如全域性表一致性修復、kill @@connection、stop @@heartbeat等操作，如：
服務端操作：
root@192.168.210.79:hotdb 8.0.30 04:24:51> create database test;
ERROR 1289 (HY000): Command CREATE_DATABASE not allowed in Read-Only mode.
root@192.168.210.79:hotdb 8.0.30 04:24:56> create table test(id int);
ERROR 1289 (HY000): Command CREATE_TABLE not allowed in Read-Only mode.
root@192.168.210.79:hotdb 8.0.30 04:25:02> insert into test values(1);
ERROR 1289 (HY000): Command INSERT not allowed in Read-Only mode.
管理端操作：
root@192.168.210.79:(none) 8.0.30 04:27:24> reload @@config;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
root@192.168.210.79:(none) 8.0.30 04:27:27> stop @@heartbeat;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
root@192.168.210.79:(none) 8.0.30 04:27:40> kill @@connection 11;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
普通模式下（含災備模式的中心機房）只讀計算節點預設讀優先順序最高的從庫，優先順序最高的從庫不可用或從庫複製延遲大於maxLatencyForReadOnly的值時，讀次優先順序的從庫，從庫都不可用則讀主庫；
災備模式的災備機房只讀計算節點讀災備機房的主庫，主庫不可用時拒絕讀取；
特定場景下的只讀模式釋放；
- HA模式下，計算節點發生高可用切換會釋放備的只讀屬性；
- 災備模式下，發生機房切換後，災備機房當前主會釋放只讀屬性；
事務內開啟只讀，未結束的事務依舊可以讀寫，直到事務提交/回滾/超時。
多計算節點叢集只讀模式下，開啟引數allowReadConsistentInReadOnly、enableListener和enableXA且部署了監聽元件後，可保證讀一致性。
計算節點例項級別的只讀模式讀從庫的優先順序高於使用者級別的讀寫分離。
主備模式下備計算節點若開啟只讀，則每10秒去主上同步最新配置資訊；也可透過配置計算節點的叢集引數實時同步配置（serverId、clusterSize、clusterNetwork、clusterHost、clusterPort）。
叢集模式下，只讀計算節點不參與選主。如：備計算節點均開啟了只讀，主計算節點故障後會因無法選主導致叢集不可用（僅管理埠可連線）。
HA模式下開啟只讀計算節點需要手動將keepalived指令碼check_hotdb_process.sh中的online改為online_readwrite，否則高可用切換後，不會釋放只讀屬性。
主計算節點不建議設定為只讀模式，reload會跳過只讀計算節點例項，主計算節點開啟只讀可能會對業務造成影響。