报错中找不到的列 _tidb_rowid 是非索引组织表的隐藏列,用作自动分片使用,也就是KV的key值。
可以核对下sorting_center.applet_user这张表备份出来的数据行数与库中记录数是不是一致,确保备份数据没有丢失。
一般来说备份工具不需要备份隐藏列的值,这里可能是产品bug。
使用 lightning 的 local backend 导入的数据时,会 compaction 数据并将多个小 SST 文件合并为一个大 SST 文件
BR 新增的日志备份和恢复功能将支持本地存储和对象存储
据悉 6.2.0 将会包含完全基于 BR 的 PiTR 功能,同时支持本地存储和 S3。
低峰期使用下面系统变量提高 analyze 速度
set @@session.tidb_distsql_scan_concurrency=60;
set @@session.tidb_index_serial_scan_concurrency=10;
set @@session.tidb_build_stats_concurrency=60;
除悲观锁下 select for update 是当前读,其他情况的 select 都是快照读,不加锁的。
这个是完整的灾难恢复流程,详情可以看上面链接中的灾难恢复手册
强制恢复单副本 PD(两中心按 3:2 部署了 5 个 PD 的场景,可以任选其中一个 PD 进行恢复,容灾中心另一个 PD 将被弃用)
调整 Placement-Rules 将 Learner 副本转为 Voter,即恢复后的集群为 2 副本模式
关闭 DR Auto-Sync 功能,转为默认的 Majority 模式
使用 pd-ctl 在线清除主中心所有 TiKV
使用 pd-recover 使 PD allocate-id +100000000,确保后续分配的 region id 等不会发生回退
不需要的,tso 生成的时候是什么时区,转出来的就是就是什么时区
tso 由 46 位物理 bit 和 18 位逻辑 bit 构成,也就是说一个物理时间对应着 2^18 个 tso,pd-ctl 中 logic 是这 18 个 bit 转换为十进制后的值。
时间转 tso(取第一个逻辑值)
select conv(concat(bin(unix_timestamp(‘2022-01-13 17:19:32’)*1000),‘000000000000000001’),2,10);
tso 转时间(多对一)
select from_unixtime(conv(left(bin(‘430457637306368001’),41),2,10)/1000);
select from_unixtime(conv(left(bin(‘430457637459197954’),41),2,10)/1000);
tidb 的查询请求到达 tikv 后,region 分裂了,导致用旧的 region 元信息访问不到数据,就会报这个错误。通过 tidb 访问 tikv 很少见到这个报错是因为 tidb 实现了 backoff 机制,可以在 region leader 调度、region 分裂、region 合并等元信息发生变化后拉取 pd 中的最新元信息,并使用原本的 startTS 再次访问 tikv,可以一定程度上避免客户端报错,客户端感受到的只是延迟升高。
目前增量文件备份就是采用 drainer 的 file 输出模式,也就是 db-type = file
dumpling 是类似 mydumper 的逻辑备份工具。你是说 pump 需要 3 个节点吧?目前是这样的,等待后续版本 BR 实现了增量文件备份功能,整个 pitr 功能就只由 BR 一个工具来覆盖了。
全量备份与全量恢复:BR 或 dumpling
增量备份:drainer 的 file 模式输出(tidb-binlog)
增量恢复:reparo
全量增量对接时间戳在 BR 和 dumpling 的备份目录中的 meta 文件上都有记录
首先需要在字段上创建索引。
TiDB 4.0 引入了 index merge(Oracle 中称作 index_combine,Db2 中称作 multiple index access)机制用于优化 or 语句的查询性能,这个参数从 5.0 开始默认打开,在 4.0 版本中可以使用下面语句开启。
set @@global.tidb_enable_index_merge=ON;