备案控制台
文档
产品文档
输入文档关键字查找
首页 云原生数据库 PolarDB 云原生数据库PolarDB分布式版 PolarDB-X 1.0（DRDS） 常见问题 历史版本常见问题

历史版本常见问题

更新时间：
一键部署
产品详情
相关技术圈
我的收藏

本文介绍了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的所有版本。

文档推荐
  • 本页导读 （0）
文档反馈