如果当时prewrite的节点活着,确实事务太大的话,会一直执行txn_heartbeat延长ttl的。有个check_txn_status,如果这个锁超期了(说明最开始执行prewrite的节点挂了),这个锁就会被其他节点清理掉。
拿tiup先跑起来试试,然后再对应的看看视频课程,课程还是不错的。
ssh 的密钥
就是用这个sshkey登录目标机器。一般目标机器对这个sshkey做免密。
关键的一点在于扩缩容方便,平时把水位压的高高的,业务高峰期提前扩容,用完后再缩回来。虽说扩缩一个节点一两天,但是不需要停机,不影响业务。
key is locked 那里,有个key,看看那个key属于的region:
pd-ctl region keys --format=hex 7AXXXXXXXX
能查出来属于哪个region
然后去information_schema里面找找属于哪张表。知道表能大概定位出来吗?别的办法我也不会了。
这个没试过,你如果tikv重启label不变应该就可以了。
你这个tp99真是不容乐观。业务这么能忍吗?
主要看store limit,如果你这个压力很大,那还是悠着点。
不影响,打上标以后应该会自动调度的。调度速度看着性能调吧,别影响性能。
大概率有的,几十k个region,不分组交叉的乱套了都。
能找到阿里的机架信息就按机架信息分组,这样更安全。找不到就自己逻辑上分组就行了。不分组混着来只能挂2个。
对tikv分组。告诉tikv(0-9)是一组,tikv(10-19)是一组,tikv(20-29)是一组,这样的话,组内只有1副本,组内随便挂几台都没问题,只要有2个组完整的运行,就不影响。
组可以从阿里看看有没有错误域之类的信息,把多台机器按错误域分组。比如说:同一个交换机,同一套电源,这就是一个错误域。
如果挂掉的2台对应的region只是普通的表,那就是这些region不能访问,如果这个region是meta信息,那tidb-server超过租期后获取不到meta信息,就整个集群不能访问了。
30多台机器还是建议分个组,按错误域调度。阿里应该有这种参数。
你有按机架分组码?如果没有,按host调度的话,任意挂两台都会导致一些region的双副本丢失,就没法提服务了。
一定等region变成tombstone才可以删除。否则就丢副本,然后期间再故障一台机器就不能正确提供服务了。
store limit all 200,完事儿。
如果影响性能比较多,就 store limit 15 改回默认值。
1t怎么也得8小时左右吧。不怕影响性能的话 store limit 搞大一些,弄个200
我是说,某公司老板喊了一句:成本、效率、体验,然后公司各种背语录,任何产都向这些靠近。在这里看到感觉有些熟悉。
成本、效率 差一个体验