可以的,先把snapshot回退到原表在的时间点,然后导出对应表,取消snapshot之后,重新导入原来的表即可
tiflash强烈建议不要和其他节点混合部署,tiflash对应资源的需求量非常大,很容易和其他节点产生资源争用。
/flash/tidb-data/tiflash-9000/metadata/db_161619/t_124444.sql这个文件不存在?你看下这个目录和文件的状态正常吗?
CREATE TABLE CLUSTER_LOG (
TIME VARCHAR(32) DEFAULT NULL,
TYPE VARCHAR(64) DEFAULT NULL,
INSTANCE VARCHAR(64) DEFAULT NULL,
LEVEL VARCHAR(8) DEFAULT NULL,
MESSAGE LONGTEXT DEFAULT NULL
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
这是CLUSTER_LOG的表结构,你把他当成普通表就行
默认会预留20%左右给系统的,不然系统都直接夯了。。。。
系统变量最低都是session级别的。。。没有库级别的。。。
整个sql和执行计划发出来,不然没法判断。
例如select a from t where b>10 limit 100如果b上没索引的话,不是只能全表扫到100行b>10的数据才行吗?那扫多少数据不是完全取决于你的数据是如何存放的?
你在什么场景下用到了 DDL ?
新上功能需要新建表,新建字段;
提升效率新增索引;
DDL 任务的执行是模式有什么规律么?例如周期一批处理 DDL 任务,还是租户自行提交 DDL 变更任务。哪类 DDL 任务是你任务急需提升执行效率的语句,能描述一下具体痛点场景么?
新增字段和新增索引。大表的话可能会很慢
你觉得应该如何提升 DDL 的并发执行能力?
是不是可以新增关键字,让他在后台跑,同时可以hint指定并发度之类的。。。
你觉得 DDL 还需要在哪些层面上做优化?
同上
你explain analyze 执行下看看, 可能是explain执行计划有偏差,3000W数据过滤60W+就全表扫不太对
SELECT DISTINCT a.ti_jgywlb check_value FROM tcsjsjg a
UNION ALL
SELECT ‘TGZX’ check_value COLLATE gbk_bin FROM dual
先试一下
都是和pd节点来进行交互的,pd来管理tikv各个节点之间的状态
拓扑图在发一下吧,这个说的不太清楚,其实主要看看时候不是tidb和tikv有混布,混布的话,看下内存的使用情况。。。
[image]
哪有20240501。。。我瞎了?
tikv不支持一个节点配置多个目录,tiflash才支持
P20240501这个分区的stats healthy是啥样的,看着你应该这个分区统计信息收集成功了