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

現(xiàn)象描述

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

如果業(yè)務(wù)的請求量比較少，臟連接被淘汰的時間會持續(xù)的比較久，報錯也會持續(xù)的比較久。

處理建議

• 緊急情況急需恢復(fù)時，可以將控制臺上的socket_timeout參數(shù)調(diào)大1，PolarDB-X 1.0會重建連接池。

• 將實例升級至PolarDB-X 2.0，即可主動感知到DN節(jié)點的主備切換，并自動重建連接池。

版本范圍

PolarDB-X 1.0的所有版本。

RDS主機宕機引發(fā)主備切換后PolarDB-X 1.0的SQL存在卡住的風險

現(xiàn)象描述

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

處理建議

• 緊急情況急需恢復(fù)時，可以將控制臺上的socket_timeout參數(shù)調(diào)大1，PolarDB-X 1.0會重建連接池。

• 將實例升級至PolarDB-X 2.0，即可主動感知到DN節(jié)點的主備切換，并自動重建連接池。

版本范圍

PolarDB-X 1.0的所有版本。

RDS進行可用區(qū)遷移、VPC切換等操作時PolarDB-X 1.0無法連接RDS

現(xiàn)象描述

當RDS進行網(wǎng)絡(luò)變更（包括可用區(qū)遷移、VPC切換等操作）時，PolarDB-X 1.0無法感知到網(wǎng)絡(luò)變化，導致連接RDS失敗。

處理建議

• 在PolarDB-X 1.0控制臺使用連接修復(fù)功能，重建PolarDB-X 1.0與RDS之間的網(wǎng)絡(luò)通路。

• 將實例升級至PolarDB-X 2.0。

版本范圍

PolarDB-X 1.0的所有版本。

大批量KILL同時執(zhí)行打滿線程池導致PolarDB-X 1.0無響應(yīng)

現(xiàn)象描述

大批量KILL請求在同一時間內(nèi)并行執(zhí)行，會有占滿PolarDB-X 1.0線程池的風險, 其表現(xiàn)為所有其它的SQL請求因線程資源耗盡而無響應(yīng)。

處理建議

業(yè)務(wù)側(cè)要盡量避免短時間內(nèi)大量高頻地向PolarDB-X 1.0發(fā)送KILL指令。

版本范圍

PolarDB-X 1.0的所有版本。

NOW函數(shù)結(jié)果被事務(wù)連接緩存導致SQL結(jié)果不正確

現(xiàn)象描述

SQL中的Now函數(shù)的計算結(jié)果在事務(wù)中或連續(xù)事務(wù)中會被意外地保持著一個值不變，該Now函數(shù)只會在前端連接被重置或非事務(wù)請求完成后才會重新刷新（重新計算）。

處理建議

將實例升級至5.4.12的最新版本。

版本范圍

5.4.9系列的所有版本。

PolarDB-X 1.0大量線程有可能在獲取元數(shù)據(jù)時被阻塞導致業(yè)務(wù)SQL執(zhí)行無響應(yīng)

現(xiàn)象描述

當PolarDB-X 1.0里有多個邏輯庫時，在控制臺手動執(zhí)行刪庫操作時，有概率導致PolarDB-X 1.0的元數(shù)據(jù)管理的工作程線程池被銷毀，導致其它正常邏輯庫的正常查詢的大量線程，在獲取元數(shù)據(jù)時會被長時間的阻塞，并導致業(yè)務(wù)查詢無響應(yīng)并超時報錯。

處理建議

將實例升級至5.4.12的最新版本。

版本范圍

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

SQL Limit參數(shù)被錯誤緩存導致SQL查詢結(jié)果不正確

現(xiàn)象描述

SQL limit參數(shù)被緩存，導致下發(fā)的物理SQL沒有按預(yù)期查詢出正確結(jié)果。

處理建議

將實例升級至5.4.12的最新版本。

版本范圍

5.4.11-*~5.4.12-*

BLOB字段被Update時有概率出現(xiàn)亂碼風險

現(xiàn)象描述

非下推update語句對Set子句中的BLOB類型數(shù)據(jù)處理存在問題，導致非下推update語句寫入BLOB類型數(shù)據(jù)時按照Char類型進行了類型轉(zhuǎn)換，產(chǎn)生不符合預(yù)期的結(jié)果。

處理建議

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

版本范圍

PolarDB-X 1.0所有版本。

PolarDB-X 1.0執(zhí)行計劃中拆分參數(shù)有概率被污染導致物理SQL下發(fā)到了錯誤分片

現(xiàn)象描述

緩存的執(zhí)行計劃被污染，導致在客戶的并發(fā)場景中，執(zhí)行計劃sharding計算的表達式部分會有小概率被修改為一個固定值，從而引起后續(xù)請求的訪問只會下發(fā)到一個固定的分片，繼而導致結(jié)果不正確。

處理建議

• 臨時解決方案：清理baseline/plancache或摘除有問題節(jié)點的權(quán)重。

• 長期處理方案：將實例升級至5.4.12的最新版本。

版本范圍

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

查詢分片缺失及查詢數(shù)據(jù)不正確問題

現(xiàn)象描述

在小于等于負整數(shù)的范圍查詢場景中，當分庫分表列的類型是整數(shù)時，對于類似id<-2的范圍查詢，分庫分表路由結(jié)果會有概率出現(xiàn)個別分表缺失，導致數(shù)據(jù)掃描不全。

處理建議

• PolarDB-X 1.0分庫分表使用整數(shù)并且哈希分區(qū)時，盡量避免范圍查詢以及使用含負數(shù)的范圍查詢。

• 將實例升級至PolarDB-X 2.0，使用AUTO模式的數(shù)據(jù)庫。

版本范圍

PolarDB-X 1.0的所有版本。

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

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

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

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

• PolarDB-X 1.0不支持collation，其跨分片的排序結(jié)果和MySQL的collation可能不一致，導致聚合、排序等查詢結(jié)果錯誤。

處理建議

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

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

• 字符串類型需要匹配數(shù)據(jù)庫中的存儲長度，避免出現(xiàn)被MySQL截斷的情況。

• 避免在PolarDB-X 1.0上對于包含非ascii字符的列進行排序、聚合等操作。

• 將實例升級至PolarDB-X 2.0，使用AUTO模式的數(shù)據(jù)庫。

版本范圍

PolarDB-X 1.0所有版本及PolarDB-X 2.0中的DRDS模式數(shù)據(jù)庫。

部分時間類型的拆分函數(shù)路由后有概率出現(xiàn)分片缺失的現(xiàn)象

現(xiàn)象描述

當分庫分表列的類型是date/datetime/timestamp，且使用YYYYMM/YYYYWEEK/YYYYDAY/MMDD/MM/DD等拆分函數(shù)進行水平分區(qū)時，對于諸如col > time1 and col < time2的區(qū)間范圍查詢，有概率出現(xiàn)路由后部分分區(qū)缺失導致查詢結(jié)果不完整的問題。

處理建議

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

版本范圍

5.2.x~5.3.11-15622313

LOCK TABLE導致鎖表等異常

現(xiàn)象描述

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

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

2. 執(zhí)行LOCK TABLE的物理連接無法訪問其他表。

處理建議

PolarDB-X 1.0中，避免使用LOCK TABLE語句。特別的，Mysqldump等工具生成的腳本中默認會包含LOCK TABLE語句，需要通過設(shè)置--skip-lock-tables參數(shù)避免生成LOCK TABLE語句。

版本范圍

5.1.x~5.3.x

廣播表出現(xiàn)不一致或延遲等

現(xiàn)象描述

PolarDB-X 1.0中的廣播表，是為了滿足以下業(yè)務(wù)場景：

1. 應(yīng)用對一致性要求不高的表。

2. 很少發(fā)生變動的表。

實現(xiàn)方式有Binlog異步復(fù)制和XA協(xié)議兩種。這兩種方式均無法保證數(shù)據(jù)的強一致性，均有可能出現(xiàn)數(shù)據(jù)不一致、數(shù)據(jù)延遲等問題。

處理建議

• 將實例升級至PolarDB-X 2.0。

• PolarDB-X 1.0中的廣播表是弱依賴的，應(yīng)用需要能接受廣播表數(shù)據(jù)出現(xiàn)不一致等情況。

• 廣播表盡可能減少增刪改，以查詢?yōu)橹鳌?/p>

版本范圍

PolarDB-X 1.0所有版本。

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

現(xiàn)象描述

PolarDB-X 1.0中的白名單是實例級的。每個數(shù)據(jù)庫的管理頁面中，都有修改白名單的入口，實際上修改的是實例的白名單，修改一個數(shù)據(jù)庫的白名單就等價于修改所有數(shù)據(jù)庫的白名單。

處理建議

• 用戶應(yīng)謹慎執(zhí)行此項操作。

• 將實例升級至PolarDB-X 2.0，擁有更完善的權(quán)限管理能力。

版本范圍

PolarDB-X 1.0所有版本。

不支持對PolarDB-X 1.0的系統(tǒng)表進行修改

現(xiàn)象描述

PolarDB-X 1.0會在RDS上創(chuàng)建一些系統(tǒng)表（非業(yè)務(wù)表均為系統(tǒng)表，包括但不限于tddl_rule、tddl_sequence等）。任何時候，都不應(yīng)對PolarDB-X 1.0的系統(tǒng)表進行修改，否則導致的結(jié)果包括但不限于表丟失、數(shù)據(jù)錯亂、主鍵沖突等異常。

例如，使用DTS對兩個PolarDB-X 1.0下的RDS進行同步，應(yīng)當過濾掉PolarDB-X 1.0的系統(tǒng)表。

處理建議

避免對PolarDB-X 1.0的系統(tǒng)表進行修改。

版本范圍

PolarDB-X 1.0所有版本。

HASH/UNI_HASH對于Bigint Unsigned路由出錯

現(xiàn)象描述

早期PolarDB-X 1.0版本中，沒有及時限制使用Bighint Unsigned作為分區(qū)列，導致Bighint Unsigned在計算HashCode時，原始值的面值超過java long自身取值范圍（PolarDB-X 1.0的hash對于整數(shù)，是使用原始值計算哈希code）并產(chǎn)生溢出，導致路由出現(xiàn)錯誤。具體表現(xiàn)為數(shù)據(jù)插入后，按分區(qū)鍵點查查詢不出結(jié)果。

目前PolarDB-X 1.0的HASH/UNI_HASH不支持Bighint Unsigned作為分區(qū)列的路由。

處理建議

• 對于PolarDB-X 1.0實例，所有Bighint Unsigned的分區(qū)列改用Bighint Signed或遷移至PolarDB-X 2.0并使用AUTO模式數(shù)據(jù)庫；

• 對于PolarDB-X 2.0實例，建議改用AUTO模式數(shù)據(jù)庫進行水平分區(qū)。

版本范圍

PolarDB-X 1.0所有版本及2.0的DRDS模式數(shù)據(jù)庫。

UNI_HASH/RANGE_HASH/STR_HASH/RIGHT_SHIFT在部分場景下分區(qū)路由不均衡

現(xiàn)象描述

PolarDB-X 1.0使用UNI_HASH/RANGE_HASH/STR_HASH/RIGHT_HASH的哈希算法分庫分表時，如果分庫分表列是同一個列，有可能會出現(xiàn)個別物理分表沒有數(shù)據(jù)的現(xiàn)象。此現(xiàn)象符合預(yù)期，與具體的分庫數(shù)目以及分表數(shù)目，Java的HashCode計算以及上述幾類哈希函數(shù)所采用的分庫分表的路由算法有關(guān)。

• Java的HashCode計算

  Java的Interger/Long/String等類型的hashcode算法的混淆性不好，當分區(qū)列的取值空間比較小時（例如原始數(shù)值出現(xiàn)連續(xù)的數(shù)字，且取值是1000以內(nèi)），容易產(chǎn)生比較多的哈希沖突；

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

  • dbIndex=hashCode%dbCount（物理分庫數(shù)）；

  • tbIndex=hashCode%tbCount（單個物理分庫內(nèi)的分表數(shù)）；

  例如一個分庫分表的哈希值是hashCode(xxx)，它的物理分庫數(shù)dbCount=2，單個物理分庫內(nèi)的分表數(shù)tbCount=2，那么，必然會得到：

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

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

由于以上原因，可能會出現(xiàn)個別分表（例如1號分庫的0號分表）沒有數(shù)據(jù)，從而表現(xiàn)為個別分表數(shù)據(jù)分布不均衡。

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

處理建議

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

• 將實例遷移至PolarDB-X 2.0使用AUTO模式的HASH分區(qū)。

版本范圍

PolarDB-X 1.0的所有版本及2.0的DRDS模式數(shù)據(jù)庫。

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

現(xiàn)象描述

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

當業(yè)務(wù)的Insert在極短時間內(nèi)突然并發(fā)增高時，Simple Sequence在數(shù)據(jù)庫內(nèi)比較容易出現(xiàn)因高并發(fā)更新Sequence而引起的預(yù)計內(nèi)的鎖爭搶，并進一步導致Sequence請求線程因鎖等待大量排隊，從而容易引起Insert相關(guān)的性能瓶頸。

處理建議

• 使用Group Sequence。

• 將實例遷移至PolarDB-X 2.0使用New Sequence。

版本范圍

PolarDB-X 1.0的所有版本。