root賬號的ssl_type修改為ANY后無法登錄、
場景描述
在控制臺以root帳號通過DAS登錄實例時，報錯Access denied。
原因分析
- 查看mysql.user表中的root帳號信息，排查客戶端IP范圍是否正確、是否使用SSL。
SELECT * FROM mysql.user WHERE User='root';
如果發現root帳號的ssl_type被設置為 ANY ，表明root帳號需要使用SSL連接。
- 查看SSL開啟情況。
show variables like '%ssl%';
發現該實例未開啟SSL：
因此，問題原因是自行修改root帳號的ssl_type為ANY后，導致無法登錄。
解決方案
將root帳號的ssl_type修改為空即可，參考命令：
update mysql.user set ssl_type='' where user = 'root';
如果要將其他所有用戶帳號的ssl_type修改為空，參考命令：
update mysql.user set ssl_type='' where user not like 'mysql%';
SSL使用與介紹
場景描述
使用SSL無法連接上數據庫。
原因分析
優先檢查網絡是否已經連通，如果不帶SSL的連接方式可以連接，則可能是mysql client或對應的數據庫驅動的版本不兼容。
解決方案
TaurusDB是兼容社區8.0以上版本的，需要使用8.0及以上版本的mysql client或數據庫驅動。
SSL(Secure Socket Layer：安全套接字層)使用數據加密、身份校驗和消息完整性校驗，為連接提供安全性保證。
SSL提供的功能主要包含 ：
- 加密數據傳輸：利用對稱密鑰算法對傳輸的數據進行加密。
- 身份校驗：基于證書使用數字簽名的方法對客戶端與服務器進行身份驗證。
- 消息完整性校驗：消息傳輸過程中使用MAC算法來檢驗消息的完整性。
注意
當服務端的SSL開啟時，客戶端的身份驗證是可選的，即：即使服務端開啟了SSL，客戶端也可以不通過SSL的方式連接服務端，此時也可以正常通信，只是數據不會被加密。
如果不是通過SSL的方式，那么其在網絡中的傳輸數據會以明文進行，存在安全隱患。
TaurusDB數據庫服務端會默認開啟服務端會默認開啟SSL，客戶業務使用時可以在客戶端自行選擇是否使用SSL。
對各個IP地址的解釋說明
購買TaurusDB實例后獲得了多個IP地址，以1主1只讀為例，在實例基礎信息中最多共能找到4個IP，業務可以按自己的需要連接對應的IP。
說明對于節點讀內網地址，如果出現節點故障，故障恢復前IP不可訪問。
對于節點讀內網地址，如果出現節點故障，故障恢復前IP不可訪問。
- 主節點讀內網地址（不推薦使用）
IP與節點綁定，可以從內網（同VPC網絡內）直接連接IP做讀寫操作，如果發生故障倒換，節點變為只讀節點，則該IP將只能做讀操作，不能做寫操作。對該IP的操作實際會落到對應的節點上。
- 只讀節點讀內網地址（不推薦使用）
IP與節點綁定，可以從內網（同VPC網絡內）直接連接IP做讀操作，如果發生故障倒換，節點變為主節點，則該IP將能做讀寫操作。對該IP的操作實際會落到對應的節點上。
- 讀寫內網地址
浮動IP，IP永遠與主節點綁定，可以內網（同VPC網絡內）直接連接IP做讀寫操作。如果發生故障倒換，該IP會浮動到新的主節點，依然可以做讀寫操作。對該IP的操作永遠會落到當時的主節點上。
- 讀寫公網地址(創建實例后需要單獨綁定)
創建并綁定公網IP后，可以從公網連接IP做讀寫操作。與浮動IP相同，也是一直與主節點綁定，且一直可以做讀寫操作。對該IP的操作永遠會落到當時的主節點上。
說明故障倒換：
TaurusDB默認最少為2個節點，1主（可讀可寫）1只讀（只可讀不可寫），主節點僅允許有一個，只讀節點可以有多個。
當主節點遇到故障時，高可用系統會迅速發現，并選擇一個只讀節點將其升級為主節點，并將原主節點修復為只讀節點，這個過程叫故障倒換。
客戶端TLS版本MySQL不一致導致SSL連接失敗
場景描述
某業務客戶端連接到云上TaurusDB失敗，但是連接到自建環境或其他環境可以成功，均使用了SSL連接。
原因分析
排查步驟：
- 查看TaurusDB的錯誤日志，觀察到如下報錯：
2021-07-09T10:30:58.476586+08:00 212539 [Warning] SSL errno: 337678594, SSL errmsg: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol2021-07-09T10:30:58.476647+08:00 212539 [Note] Bad handshake2021-07-09T10:32:43.535738+08:00 212631 [Warning] SSL errno: 337678594, SSL errmsg: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol2021-07-09T10:32:43.535787+08:00 212631 [Note] Bad handshake2021-07-09T10:50:03.401100+08:00 213499 [Warning] SSL errno: 337678594, SSL errmsg: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol2021-07-09T10:50:03.401161+08:00 213499 [Note] Bad handshake2021-07-09T10:53:44.458404+08:00 213688 [Warning] SSL errno: 337678594, SSL errmsg: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol2021-07-09T10:53:44.458475+08:00 213688 [Note] Bad handshake
- 從報錯信息unsupported protocol可以看出，很可能和TLS版本相關，使用如下命令，分別查看TaurusDB和自建MySQL的TLS版本。
show variables like '%tls_version%';
發現TaurusDB為TLS v1.2版本，自建MySQL為TLS v1.1版本，存在差異。進一步確認客戶端TLS版本，與自建MySQL一致，因此出現連接自建MySQL成功，連接云上TaurusDB失敗。
解決方案
客戶端升級TLS版本到TLS v1.2。
如果使用官方JDBC驅動 mysql-connector/J ，可參考，配置方法：
TaurusDB建立連接慢導致客戶端超時
場景描述
業務在高峰期時，客戶端經常出現向MySQL建立連接超時，導致系統登錄需要十幾秒。
原因分析
- 查看TaurusDB的錯誤日志，觀察是否有如下信息：connection xxx is established slowly。示例：
有上述日志，說明存在某些連接超過一定時間仍未被MySQL處理，客戶端的超時時間大于該時間，就會報錯。
- 進一步查看線程池配置（默認開啟），可以在控制臺查看。
可以看出，threadpool_size為1，threadpool_stall_limit為500ms，threadpool_oversubscribe為3，線程池處理連接等待的時間主要與上述3個參數相關：
- 當線程池所有線程在忙碌，線程池中的調度線程會每隔500ms（threadpool_stall_limit）創建一個新線程，所以此時，每個線程組平均每500ms才能處理一個新的連接。如果隊列太長，很可能導致客戶端超時；
- 所有線程都在忙碌是指，工作線程達到線程池總線程數，在大量建立連接時，總線程數計算方法：threadpool_size*(threadpool_oversubscribe+1))
解決方案
對于存在大量新建連接，建議調大threadpool_oversubscribe增加線程總數。
減少線程重復創建與銷毀部分的開銷，提高性能，同時它也限制了MySQL的runing線程數，關鍵時刻可以保護系統，防止雪崩。
正常情況下，線程池適用于大量短連接的場景，如果客戶是長連接，并且連接數量不多（客戶端使用了連接池等情況），線程池的作用不大，此時調整threadpool_size和threadpool_oversubscribe兩個參數擴大線程總數，或者直接關閉線程池。
連接數據庫報錯Access denied
場景描述
客戶端連接數據庫異常，返回錯誤：Error 1045: Access denied for user xxx
處理方法
- 連接了錯誤的主機
問題原因：業務連接了錯誤的數據庫主機，該主機上相應用戶或客戶端IP沒有權限訪問。
解決方案：仔細檢查要連接的數據庫主機名，確保正確。
- 用戶不存在
問題原因：客戶端連接時，使用的用戶不存在。
解決方案：
- 使用管理員帳戶登錄數據庫，執行如下命令檢查目標用戶是否存在。
SELECT User FROM mysql.user WHERE User='xxx';
- 如果用戶不存在，創建相應用戶。
CREATE USER 'xxx'@'xxxxxx' IDENTIFIED BY 'xxxx';
- 用戶存在，但客戶端IP無訪問權限
問題原因：客戶端使用的用戶存在，但是客戶端IP沒有該數據庫的訪問權限。
解決方案：
- 使用管理員帳戶登錄數據庫，執行如下命令，檢查目標用戶允許哪些客戶端IP連接。
SELECT Host, User FROM mysql.user WHERE User='xxx';
- 如果上述查詢出的Host不包含客戶端IP所在網段，則需要賦予相應訪問權限。例如，賦予test用戶192.168.0網段訪問權限。
GRANT ALL PRIVILEGES ON *.* TO'root'@'192.168.0.%' IDENTIFIED BY 'password' WITH GRANT OPTION;
FLUSH PRIVILEGES;
- 密碼錯誤
問題原因：用戶對應的密碼錯誤，或忘記密碼
解決方案：
- 確定目標密碼是否錯誤，由于密碼用于身份驗證，因此無法從MySQL以明文形式讀取用戶密碼，但可以將密碼的哈希字符串與目標密碼的“PASSWORD”函數值進行比較，確定目標密碼是否正確，示例SQL語句：
mysql> SELECT Host, User, authentication_string, PASSWORD('12345') FROM mysql.user WHERE User='test';
+-----------+------+-------------------------------------------+-------------------------------------------+
| Host | User | authentication_string | PASSWORD('12345') |
+-----------+------+-------------------------------------------+-------------------------------------------+
| % | test | *6A23DC5E7446019DC9C1778554ED87BE6BA61041 | *00A51F3F48415C7D4E8908980D443C29C69B60C9 |
+-----------+------+-------------------------------------------+-------------------------------------------+
2 rows in set, 1 warning (0.00 sec)
2 rows in set, 1 warning (0.00 sec)
從上面例子可以看出，PASSWORD('12345')的哈希值與authentication_string列不匹配，這表明目標密碼“12345”是錯誤的。
- 如果需要重置用戶密碼，參考如下SQL語句：
set password for 'test'@'%' = 'new_password';
- 密碼包含特殊字符被Bash轉義
問題原因：Linux默認的Bash環境下，使用命令行連接數據庫，用戶密碼中包含特殊字符會被環境轉義，導致密碼失效。
例如，在Bash環境下，用戶test的密碼為“test$123”，使用命令mysql -hxxx -u test -ptest$123，連接數據庫會報錯ERROR 1045 (28000): Access denied。
解決方案：通過用單引號將密碼括起來，防止Bash解釋特殊字符。
mysql -hxxx -u test -p'test$123'
- 用戶設置了REQUIRE SSL，但客戶端使用非SSL連接
排查思路：
- 排查報錯用戶名是否強制使用SSL連接，執行：show create user 'xxx'，如果出現“REQUIRE SSL”屬性，說明該用戶必須使用SSL連接。
- 排查是否使用過如下類似語句給用戶授權。
GRANT ALL PRIVILEGES ON . TO 'ssluser'@'localhost' IDENTIFIED BY ' password ' REQUIRE SSL;
- 檢查目標用戶的ssl_type值，如果不為空，說明該用戶需要使用SSL連接。
SELECT User, Host, ssl_type FROM mysql.user WHERE User='xxx';
解決方案：
- 客戶端使用SSL方式數據庫連接。
- 去除用戶SSL連接權限，參考命令：ALTER USER 'username'@'host' REQUIRE NONE;
mariadb-connector SSL方式連接數據庫失敗
場景描述
使用jdbc無法連接數據庫，報如下錯誤：
unable to find certification path to requested target
原因分析
從錯誤截圖中可以看出，使用的是mariadb的jar包，而非MySQL的官方驅動包，而mariadb與官方的使用方法略有區別。
解決方案
對于mariadb的連接串應該為：
String url = "jdbc:mysql://xxx.xxx.xxx.xxx:xxxx/mysql?useSsl=true&serverSslCert=D:\\ca.pem&disableSslHostnameVerification=true";
注意：TaurusDB實例不支持hostname校驗，因此需要設置disableSslHostnameVerification=true，不同mariadb jar包版本設置方式不同，可查看對應版本的。
使用root帳號連接數據庫失敗
場景描述
使用root帳號連接數據庫失敗。
原因分析
- 查看內核日志error.log，確認是否有拒絕連接的日志。
- 查看root權限，發現有兩個root帳號，其中一個root限制host必須是IP必須是192開頭。
解決方案
聯系技術支持協助刪除多余的root帳號。
客戶端連接實例后會自動斷開
故障描述
MySQL客戶端連接實例后，會自動斷開，報錯信息：“ERROR 2013：Lost connection to MySQL server during query”。
解決方案
ERROR 2013是MySQL常見錯誤，一般為配置錯誤導致。
- “wait_timeout”：服務器關閉非交互連接之前等待活動的秒數。
- “interactive_timeout”：服務器關閉交互連接之前等待活動的秒數。
步驟 1 查看實例狀態是否處于正常狀態。
經查看實例狀態正常，繼續排查其他問題。
步驟 2 查看錯誤日志。
步驟 3 使用MySQL命令行客戶端連接數據庫，執行status命令，確認數據庫實例是否頻繁重啟。
Uptime代表實例的運行時間，從排查結果可知，數據庫并沒有頻繁重啟，因而，客戶端連接被斷開，不是因數據庫重啟引起的。
步驟 4 查看“wait_timeout”和“interactive_timeout”參數設置，MySQL會自動斷開超時的空連接。
步驟 5 您可根據實際應用需求量，修改“wait_timeout”和“interactive_timeout”參數值，無需重啟實例。
步驟 6 恢復結果確認，等到10分鐘左右，再次執行show databases命令，確認連接是否正常。
如圖所示，說明連接正常。
istio-citadel證書機制導致每隔45天出現斷連
場景描述
業務側發現數據庫每隔45天同一時間，多臺數據庫實例的連接數驟降。查看服務端連接數監控指標如下：
客戶端出現大量報錯如下：
原因分析
- 排查業務側是否有間隔45天的定時任務。
- 客戶端如果使用了istio等證書加密機制，分析證書相關日志，是否有如下類似信息。如果有，說明是證書過期導致。
客戶端istio-citadel證書每隔45天過期，導致主動發起數據庫斷連請求。
解決方案
- 客戶端設置合理的istio-citadel證書過期時間，并在過期發生時，主動規避操作。
- 客戶端排查是否有其他證書過期問題。
