tiup server /data1/deploy/tiup-console/mirror --addr 0.0.0.0:8899 --upstream=""
Fetch local manifest: unknown component
Failed to load component manifest, create a new one
Error: Unknow error from server, response code: 500 response body: {"status":"INTERNAL ERROR","message":"an internal error happened"}
rm -rf ~/.tiup/manifests/
rm -rf ~/.tiup/bin
$(pwd)/mirror-test
sh -x local_install.sh
source /home/tidb//.bash_profile
tiup mirror publish hello v0.0.1 hello.tar.gz hello.sh --os=any --arch=any --desc="hello world example"
报错:
Fetch local manifest: unknown component
Failed to load component manif…
看看tikv-details/Thread-cpu/raft-store-cpu 的情况,如果不高年后处理没问题
我这边一个集群空region百万级也是运行了一段时间调优的
可供选择的方案:
改造为 hash 表
Load Base Split
Follower Read
可结合业务进行选择使用
1333 // OverflowShardBits checks whether the recordID overflow `1<<(typeBitsLength-shardRowIDBits-1) -1`.
1334 func OverflowShardBits(recordID int64, shardRowIDBits uint64, typeBitsLength uint64, reservedSignBit bool) bool {
1335 var signBit uint64
1336 if reservedSignBit {
1337 sig…
手动拉起看看呢
systemctl daemon-reload && systemctl start pd-2379.service
对于大表,统计信息失真,校准需要用户参与并且耗时较长(大表),这个后续有优化计划嘛
产品使用过程中遇到的问题及建议
问题:
1.执行计划突然改变导致业务出问题(频率较高影响较大)
2.Tiflash查询优化,Tiflash查询前需要同步所有数据,保证读取到最新的数据,会影响查询效率
3.tidb insert优化,目前在生产环境遇到过一些瓶颈,希望insert能更快
4. 关于调度,没配置label,我这边扩容之后新节点磁盘降的很慢(调大store limit会加快),老节点磁盘还在快速下降(重点),并且集群稳定后,各节点磁盘使用量并不平衡
5. 集群中有tikv节点磁盘爆掉之后drop partition未执行
6. cdc下游配置mysql/tidb时,…
我没测过,但是官方当时建议过我这么干,后来我这边只迁移了少量核心业务,数据量不大,就直接用mysqldump了
如果region-merge已开启,empty-region仍然降不下去,请参考https://asktug.com/t/topic/34419处理
数据量大的话还可以试试 Dumpling + Lightning
我上次迁的是tidb-v1.0.8

这个事情我也干过,mydumper对低版本的tidb兼容性不太好,我最后是用的mysqldump