幫助中心
首頁 PolarDB 雲原生資料庫PolarDB分布式版 PolarDB-X 1.0（DRDS） 常見問題 歷史版本常見問題

歷史版本常見問題

更新時間：
Copy as MD
產品

本文介紹了PolarDB-X 1.0歷史版本的常見問題以及處理建議。

RDS主備切換後PolarDB-X1.0會報錯一段時間

現象描述

PolarDB-X 1.0與RDS的串連使用了串連池，串連池中儲存了一部分串連。正常的RDS主備切換流程中，會對老的串連進行KILL操作，但PolarDB-X 1.0作為用戶端無法感知到這些串連被KILL，在該串連上第一次有SQL訪問的時候才能感知到。因此在RDS主備切換後的一段時間，通過PolarDB-X 1.0訪問該RDS的請求會有一定的機率失敗，每失敗一次，就會淘汰一個髒串連。

如果業務的請求量比較少，髒串連被淘汰的時間會持續的比較久，報錯也會持續的比較久。

處理建議

  • 緊急情況急需恢複時，可以將控制台上的socket_timeout參數調大1，PolarDB-X 1.0會重建串連池。

  • 將執行個體升級至PolarDB-X 2.0，即可主動感知到DN節點的主備切換，並自動重建串連池。

版本範圍

PolarDB-X 1.0的所有版本。

RDS主機宕機引發主備切換後PolarDB-X 1.0的SQL存在卡住的風險

現象描述

正常的RDS主備切換流程中，對老的串連會進行KILL操作，當PolarDB-X 1.0使用這些串連的時候，會立即報錯。但如果RDS主機宕機，串連可能無法被KILL，此時PolarDB-X 1.0無法感知到這些串連已斷開，由於TCP層的socket_timeout參數預設設定為900s，出現這種情況時，PolarDB-X 1.0發送到此RDS的SQL，可能需要等待至少900s的時間才會報錯。

處理建議

  • 緊急情況急需恢複時，可以將控制台上的socket_timeout參數調大1，PolarDB-X 1.0會重建串連池。

  • 將執行個體升級至PolarDB-X 2.0，即可主動感知到DN節點的主備切換，並自動重建串連池。

版本範圍

PolarDB-X 1.0的所有版本。

RDS進行可用性區域遷移、VPC切換等操作時PolarDB-X 1.0無法串連RDS

現象描述

當RDS進行網路變更（包括可用性區域遷移、VPC切換等操作）時，PolarDB-X 1.0無法感知到網路變化，導致串連RDS失敗。

處理建議

  • 在PolarDB-X 1.0控制台使用串連修複功能，重建PolarDB-X 1.0與RDS之間的網路通路。

  • 將執行個體升級至PolarDB-X 2.0。

版本範圍

PolarDB-X 1.0的所有版本。

大批量KILL同時執行打滿線程池導致PolarDB-X 1.0無響應

現象描述

大批量KILL請求在同一時間內並存執行，會有佔滿PolarDB-X 1.0線程池的風險, 其表現為所有其它的SQL請求因線程資源耗盡而無響應。

處理建議

業務側要盡量避免短時間內大量高頻地向PolarDB-X 1.0發送KILL指令。

版本範圍

PolarDB-X 1.0的所有版本。

NOW函數結果被事務串連緩衝導致SQL結果不正確

現象描述

SQL中的Now函數的計算結果在事務中或連續事務中會被意外地保持著一個值不變，該Now函數只會在前端串連被重設或非事務請求完成後才會重新重新整理（重新計算）。

處理建議

將執行個體升級至5.4.12的最新版本。

版本範圍

5.4.9系列的所有版本。

PolarDB-X 1.0大量線程有可能在擷取中繼資料時被阻塞導致業務SQL執行無響應

現象描述

當PolarDB-X 1.0裡有多個邏輯庫時，在控制台手動執行刪庫操作時，有機率導致PolarDB-X 1.0的中繼資料管理的工作程線程池被銷毀，導致其它正常邏輯庫的正常查詢的大量線程，在擷取中繼資料時會被長時間的阻塞，並導致業務查詢無響應並逾時報錯。

處理建議

將執行個體升級至5.4.12的最新版本。

版本範圍

5.2.x-* ~ 5.2.8-15738106（不包含）

SQL Limit參數被錯誤緩衝導致SQL查詢結果不正確

現象描述

SQL limit參數被緩衝，導致下發的物理SQL沒有按預期查詢出正確結果。

處理建議

將執行個體升級至5.4.12的最新版本。

版本範圍

5.4.11-*~5.4.12-*

BLOB欄位被Update時有機率出現亂碼風險

現象描述

非下推update語句對Set子句中的BLOB類型資料處理存在問題，導致非下推update語句寫入BLOB類型資料時按照Char類型進行了類型轉換，產生不符合預期的結果。

處理建議

使用十六進位字串的形式寫入BLOB欄位，例如INSERT INTO t1 VALUES(0xFFFFFFFF)。

版本範圍

PolarDB-X 1.0所有版本。

PolarDB-X 1.0執行計畫中拆分參數有機率被汙染導致物理SQL下發到了錯誤分區

現象描述

緩衝的執行計畫被汙染，導致在客戶的並發情境中，執行計畫sharding計算的運算式部分會有小機率被修改為一個固定值，從而引起後續請求的訪問只會下發到一個固定的分區，繼而導致結果不正確。

處理建議

  • 臨時解決方案：清理baseline/plancache或摘除有問題節點的權重。

  • 長期處理方案：將執行個體升級至5.4.12的最新版本。

版本範圍

5.4.1-*~5.4.12-16444832（不包含）

查詢分區缺失及查詢資料不正確問題

現象描述

在小於等於負整數的範圍查詢情境中，當分庫分表列的類型是整數時，對於類似id<-2的範圍查詢，分庫分表路由結果會有機率出現個別分表缺失，導致資料掃描不全。

處理建議

  • PolarDB-X 1.0分庫分表使用整數並且雜湊分割時，盡量避免範圍查詢以及使用含負數的範圍查詢。

  • 將執行個體升級至PolarDB-X 2.0，使用AUTO模式的資料庫。

版本範圍

PolarDB-X 1.0的所有版本。

字串等類型作為分庫分表鍵時的注意事項

  • PolarDB-X 1.0字串類型的雜湊路由計算是強制區分大小寫，例如“ABC”與“abc”計算出來的分區是不同的。MySQL進行字串匹配的時候，預設是不區分大小寫，即在MySQL層，“abc”=“ABC”。此時需要注意，如果寫入的時候使用“ABC”，按照“abc”進行查詢時，由於這兩個條件會被路由到不同的分區，因此可能是查不到的。

  • 路由計算的時候不會去除收尾空格。但MySQL進行字串匹配的時候，會忽略收尾的空格。例如，對於“ABC”與“ ABC ”，其計算出來的分區是不同的，但對於MySQL來說，“ABC”=“ ABC ”。在PolarDB-X 1.0中，這兩個條件的查詢結果可能會不一樣。

  • MySQL層會按照列的類型定義對值進行截斷，這會導致儲存的值與路由時的值不同。例如，對於一個varchar(1)的列，寫入語句INSERT INTO t1 VALUES ("abc")，PolarDB-X 1.0會使用“abc”進行路由，但到了MySQL層，“abc”會被截斷為“a”進行儲存，最後導致寫入的資料無論使用WHERE column="abc"還是WHERE column="a"（a的路由結果和abc不同）都無法查詢到。

  • PolarDB-X 1.0不支援collation，其跨分區的排序結果和MySQL的collation可能不一致，導致彙總、排序等查詢結果錯誤。

說明

數字、時間戳記等類型作為分庫分表鍵時也需要注意上述問題。

處理建議

  • 字串類型需要保證寫、查詢使用的大小寫一致。

  • 字串類型需要避免前後有空格。

  • 字串類型需要匹配資料庫中的儲存長度，避免出現被MySQL截斷的情況。

  • 避免在PolarDB-X 1.0上對於包含非ascii字元的列進行排序、彙總等操作。

  • 將執行個體升級至PolarDB-X 2.0，使用AUTO模式的資料庫。

版本範圍

PolarDB-X 1.0所有版本及PolarDB-X 2.0中的DRDS模式資料庫。

部分時間類型的拆分函數路由後有機率出現分區缺失的現象

現象描述

當分庫分表列的類型是date/datetime/timestamp，且使用YYYYMM/YYYYWEEK/YYYYDAY/MMDD/MM/DD等拆分函數進行水平資料分割時，對於諸如col > time1 and col < time2的區間範圍查詢，有機率出現路由後部分分區缺失導致查詢結果不完整的問題。

處理建議

升級PolarDB-X 1.0至5.4.12最新版本。

版本範圍

5.2.x~5.3.11-15622313

LOCK TABLE導致鎖表等異常

現象描述

使用LOCK TABLE時，在同一個串連上無法釋放鎖，導致物理串連上遺留鎖，有以下影響：

  1. LOCK TABLE中的表無法被其他串連訪問；

  2. 執行LOCK TABLE的物理串連無法訪問其他表。

處理建議

PolarDB-X 1.0中，避免使用LOCK TABLE語句。特別的，Mysqldump等工具產生的指令碼中預設會包含LOCK TABLE語句，需要通過設定--skip-lock-tables參數避免產生LOCK TABLE語句。

版本範圍

5.1.x~5.3.x

廣播表出現不一致或延遲等

現象描述

PolarDB-X 1.0中的廣播表，是為了滿足以下業務情境：

  1. 應用對一致性要求不高的表。

  2. 很少發生變動的表。

實現方式有Binlog非同步複製和XA協議兩種。這兩種方式均無法保證資料的強一致性，均有可能出現資料不一致、資料延遲等問題。

處理建議

  • 將執行個體升級至PolarDB-X 2.0。

  • PolarDB-X 1.0中的廣播表是弱依賴的，應用需要能接受廣播表資料出現不一致等情況。

  • 廣播表儘可能減少增刪改，以查詢為主。

版本範圍

PolarDB-X 1.0所有版本。

對PolarDB-X 1.0白名單生效行為的說明

現象描述

PolarDB-X 1.0中的白名單是執行個體級的。每個資料庫的管理頁面中，都有修改白名單的入口，實際上修改的是執行個體的白名單，修改一個資料庫的白名單就等價於修改所有資料庫的白名單。

處理建議

  • 使用者應謹慎執行此項操作。

  • 將執行個體升級至PolarDB-X 2.0，擁有更完善的許可權管理能力。

版本範圍

PolarDB-X 1.0所有版本。

不支援對PolarDB-X 1.0的系統資料表進行修改

現象描述

PolarDB-X 1.0會在RDS上建立一些系統資料表（非業務表均為系統資料表，包括但不限於tddl_rule、tddl_sequence等）。任何時候，都不應對PolarDB-X 1.0的系統資料表進行修改，否則導致的結果包括但不限於表丟失、資料錯亂、主鍵衝突等異常。

例如，使用DTS對兩個PolarDB-X 1.0下的RDS進行同步，應當過濾掉PolarDB-X 1.0的系統資料表。

處理建議

避免對PolarDB-X 1.0的系統資料表進行修改。

版本範圍

PolarDB-X 1.0所有版本。

HASH/UNI_HASH對於Bigint Unsigned路由出錯

現象描述

早期PolarDB-X 1.0版本中，沒有及時限制使用Bighint Unsigned作為分區列，導致Bighint Unsigned在計算HashCode時，原始值的面值超過java long自身取值範圍（PolarDB-X 1.0的hash對於整數，是使用原始值計算雜湊code）併產生溢出，導致路由出現錯誤。具體表現為資料插入後，按分區鍵點查查詢不出結果。

目前PolarDB-X 1.0的HASH/UNI_HASH不支援Bighint Unsigned作為分區列的路由。

處理建議

  • 對於PolarDB-X 1.0執行個體，所有Bighint Unsigned的分區列改用Bighint Signed或遷移至PolarDB-X 2.0並使用AUTO模式資料庫；

  • 對於PolarDB-X 2.0執行個體，建議改用AUTO模式資料庫進行水平資料分割。

版本範圍

PolarDB-X 1.0所有版本及2.0的DRDS模式資料庫。

UNI_HASH/RANGE_HASH/STR_HASH/RIGHT_SHIFT在部分情境下分區路由不均衡

現象描述

PolarDB-X 1.0使用UNI_HASH/RANGE_HASH/STR_HASH/RIGHT_HASH的雜湊演算法分庫分表時，如果分庫分表列是同一個列，有可能會出現個別物理分表沒有資料的現象。此現象符合預期，與具體的分庫數目以及分表數目，Java的HashCode計算以及上述幾類雜湊函數所採用的分庫分表的路由演算法有關。

  • Java的HashCode計算

    Java的Interger/Long/String等類型的hashcode演算法的混淆性不好，當分區列的取值空間比較小時（例如原始數值出現連續的數字，且取值是1000以內），容易產生比較多的雜湊衝突；

  • UNI_HASH/RANGE_HASH/STR_HASH/RIGHT_HASH分庫分表下標計算規則（分庫分表列相同）

    • dbIndex=hashCode%dbCount（物理分庫數）；

    • tbIndex=hashCode%tbCount（單個物理分庫內的分表數）；

    例如一個分庫分表的雜湊值是hashCode(xxx)，它的物理分庫數dbCount=2，單個物理分庫內的分表數tbCount=2，那麼，必然會得到：

    • hashCode(xxx)%2=1為奇數時，它只會路由到1號分庫的1號分表；

    • hashCode(xxx)%2=0為偶數時，它只會路由到0號分庫的0號分表。

由於以上原因，可能會出現個別分表（例如1號分庫的0號分表）沒有資料，從而表現為個別分表資料分布不均衡。

因此，PolarDB-X 1.0使用上述分區函數分庫分表（分庫分表列一樣），請保證分區列的取值空間要足夠大（即分區列的區分度要足夠好，且不同取值的數目最好能超過50W）。

處理建議

  • 如果分庫分表列是相同的，建議使用HASH（該雜湊演算法與上述幾類演算法的計算邏輯不同），可以減少此類問題。

  • 將執行個體遷移至PolarDB-X 2.0使用AUTO模式的HASH分區。

版本範圍

PolarDB-X 1.0的所有版本及2.0的DRDS模式資料庫。

PolarDB-X 1.0的Simple Sequnce的效能瓶頸風險

現象描述

PolarDB-X 1.0為了保證Simple Sequence的全域連續、有序、唯一的特性，需要保證業務的每個Sequence的擷取請求（例如Insert），都需要以持久化及加鎖的方式更新Sequnce表（例如update seq set val=val+1 where seq=xxx ），該操作在核心裡是一個全域單點的相互搶鎖的操作。

當業務的Insert在極短時間內突然並發增高時，Simple Sequence在資料庫內比較容易出現因高並發更新Sequence而引起的預計內的鎖爭搶，並進一步導致Sequence請求線程因鎖等待大量排隊，從而容易引起Insert相關的效能瓶頸。

處理建議

  • 使用Group Sequence。

  • 將執行個體遷移至PolarDB-X 2.0使用New Sequence。

版本範圍

PolarDB-X 1.0的所有版本。

PolarDB-X 1.0（DRDS）為什麼無法購買私人RDS

現象描述

建立PolarDB-X 1.0（DRDS）執行個體時無法一體化購買私人RDS執行個體。

處理建議

暫不支援一體化DRDS服務，您需要先建立對應的RDS MySQL執行個體或PolarDB MySQL版叢集，進行關聯使用。

說明

您建立的RDS MySQL執行個體或PolarDB MySQL版叢集需要與PolarDB-X 1.0（DRDS）引擎版本一致，即若DRDS為MySQL 8.0版本，則RDS MySQL執行個體或PolarDB MySQL版叢集也需要為8.0版本，以避免相容性問題。

版本範圍

PolarDB-X 1.0的所有版本。

上一篇：常見問題下一篇：分庫分表問題