嗯,可以手动切走,之前也特意问过官方除非是一些极端情况,正常pd切换出现的概率还是很小的
物理机的话不混部确实有点浪费,我们的3台pd配置也都是112C,512G 3T NVME的SSD,单独给一个非leader的pd用太浪费。。。
我们是和pd的非leader节点混部了,怕影响到业务,pd的非leader节点反正也不提供服务。如果是leader节点,从影响范围上来看可能pd出问题影响更大,那部署到tidb节点可能更好一点,最多只影响这一个tidb节点。
admin recover index只能修复二级索引吧
mysqldump没办法直接到S3吧,可以用dumpling导出成csv用-o参数推送到S3。
至于逻辑备份还是物理备份看你数据量大小,数据量大就BR,小就dumpling
是的,用DM上游得是MySQL、MariaDB这种,看报错是执行类似SHOW SLAVE HOSTS这种命令报错了,不支持这种语法
上游是tidb,那得用ticdc吧,dm是从mysql到tidb的
docker部署很方便,考虑下直接用docker部署呢
NVMe硬盘的 IO Util高似乎不能代表磁盘已经到瓶颈了,加大并发写入线程看看还能提高QPS吗
tiup看下pump组件的数据目录在哪,默认是在data.pump里
备份是必须的,不过当数据量到达一定的规模后也是个难题。异地灾备主要是成本太高,我们正在做,这个还得比较高层的领导推动才行,不然没预算。
group_concat_max_len调整下这个参数看看
像是gc导致的,不过没有写入的集群也是一样的效果,没有大量DML
tikv_gc_run_interval是10分钟,为啥会影响心跳呢,就算是没有写入的集群也是这种情况。