查询报错：Failed to get scan range, no queryable replica found in tablet: xxxx
这种情况是因为对应的 tablet 没有找到可以查询的副本，通常原因可能是 BE 宕机、副本缺失等。可以先通过
show tablet tablet_id 语句，然后执行后面的 show proc 语句，查看这个 tablet 对应的副本信息，检查副本是否完整。同时还可以通过 show proc "/cluster_balance" 信息来查询集群内副本调度和修复的进度。
关于数据副本管理相关的命令，可以参阅 数据副本管理。tablet writer write failed, tablet_id=27306172, txn_id=28573520, err=-235 or -215 or -238
这个错误通常发生在数据导入操作中。错误码为 -235 或 -238。
-235 错误的含义是，对应 tablet 的数据版本超过了最大限制（默认500，由 BE 参数 max_tablet_version_num 控制），后续写入将被拒绝。例如问题中这个错误，即表示 27306172 这个 tablet 的数据版本超过了限制。通常是因为导入的频率过高，大于后台数据的 Compaction 速度，导致版本堆积并最终超过了限制。此时，可以先通过
show tablet 27306172 语句，然后执行结果中的 show proc 语句，查看tablet各个副本的情况。结果中的 versionCount 即表示版本数量。如果发现某个副本的版本数量过多，则需要降低导入频率或停止导入，并观察版本数是否有下降。如果停止导入后，版本数依然没有下降，则需要查看对应 BE 节点的 be.INFO 日志，搜索 tablet id 以及 Compaction 关键词，检查 Compaction 是否正常运行。-238 错误通常出现在同一批导入数据量过大的情况，从而导致某一个 tablet 的 Segment 文件过多（默认 200，由 BE 参数 max_segment_num_per_rowset 控制）。此时建议减少一批次导入的数据量，或者适当提高 BE 配置参数值来解决。
tablet 110309738 has few replicas: 1, alive backends: [10003]
这个错误可能发生在查询或者导入操作中。通常意味着对应 tablet 的副本出现了异常。
此时，可以先检查 BE 节点是否有宕机，如 isAlive 字段为 false，或者 LastStartTime 是最近的某个时间（表示最近重启过）。如果 BE 有宕机，则需要通过工单联系我们排查问题。如果没有 BE 节点宕机，则需要通过
show tablet 110309738 语句，然后执行结果中的 show proc 语句，查看 tablet 各个副本的情况，进一步排查。disk xxxxx on backend xxx exceed limit usage
通常出现在导入、Alter 等操作中。这个错误意味着对应 BE 的对应磁盘的使用量超过了阈值（默认95%）此时可以先通过
show backends 命令，其中 MaxDiskUsedPct 展示的是对应 BE 上，使用率最高的那块磁盘的使用率，如果超过95%，则会报这个错误。您可选择手动删除部分数据释放空间，或者扩容云盘解决此问题。若磁盘使用率异常增高，可通过工单联系我们具体排查。-214 错误
在执行导入、查询等操作时，可能会遇到如下错误：
failed to initialize storage reader. tablet=63416.1050661139.aa4d304e7a7aff9c-f0fa7579928c85a0, res=-214, backend=192.168.100.10
-214 错误意味着对应 tablet 的数据版本缺失。例如上述错误，表示 tablet 63416在192.168.100.10这个 BE 上的副本的数据版本有缺失。（可能还有其他类似错误码，都可以用如下方式进行排查和修复）。
通常情况下，如果您的数据是多副本的，那么系统会自动修复这些有问题的副本。可以通过以下步骤进行排查：
1. 通过
show tablet 63416 语句并执行结果中的 show proc xxx 语句来查看对应 tablet 的各个副本情况。通常我们需要关心 Version 这一列的数据。
正常情况下，一个 tablet 的多个副本的 Version 应该是相同的。并且和对应分区的 VisibleVersion 版本相同。2. 您可以通过
show partitions from tblx 来查看对应的分区版本（tablet 对应的分区可以在 show tablet 语句中获取。）3. 同时，您也可以访问
show proc 语句中的 CompactionStatus 列中的 URL（在浏览器打开即可）来查看更具体的版本信息，来检查具体丢失的是哪些版本。
如果长时间没有自动修复，则需要通过 show proc "/cluster_balance" 语句，查看当前系统正在执行的 tablet 修复和调度任务。可能是因为有大量的 tablet 在等待被调度，导致修复时间较长。可以关注 pending_tablets 和 running_tablets 中的记录。4. 更进一步的，可以通过
admin repair 语句来指定优先修复某个表或分区，具体可以参阅 help admin repair。如果依然无法修复，那么在多副本的情况下，我们使用
admin set replica status 命令强制将有问题的副本下线。具体可参阅 help admin set replica status 中将副本状态置为 bad 的示例。（置为 bad 后，副本将不会再被访问。并且会后续自动修复。但在操作前，应先确保其他副本是正常的）。Not connected to 192.168.100.1:8060 yet, server_id=384
在导入或者查询时可能遇到这个错误。如果您去对应的 BE 日志中查看，也可能会找到类似错误。这是一个 RPC 错误，通常有两种可能：
1. 对应的 BE 节点宕机。
2. rpc 拥塞或其他错误。
如果是 BE 节点宕机，则需要查看具体的宕机原因。此处针对 rpc 拥塞的问题给出建议：
一种情况是 OVERCROWDED，即表示 rpc 源端有大量未发送的数据超过了阈值。BE 有两个参数与之相关：
1.
brpc_socket_max_unwritten_bytes：默认 1GB，如果未发送数据超过这个值，则会报错。可以适当修改这个值以避免 OVERCROWDED 错误。（但这个治标不治本，本质上还是有拥塞发生）。2.
tablet_writer_ignore_eovercrowded：默认为 false。如果设为true，则会忽略导入过程中出现的 OVERCROWDED 错误。这个参数主要为了避免导入失败，以提高导入的稳定性。第二种是 rpc 的包大小超过 max_body_size。如果查询中带有超大 String 类型，或者 bitmap 类型时，可能出现这个问题。可以通过修改以下 BE 参数规避：
brpc_max_body_size：默认 3GB。
