vinchen
vinchen
可以尝试先将pika迁移到redis 再从redis迁移到tendis，可参考https://github.com/Tencent/Tendis/issues/7
https://github.com/Qihoo360/pika/wiki/pika%e5%88%b0pika%e3%80%81redis%e8%bf%81%e7%a7%bb%e5%b7%a5%e5%85%b7 从官方文档中，pika提供工具迁移到redis，理论上也可以迁移到tendis
jeprof文件是tendis基于jemalloc的内存画像 如果发生crash，会产生core文件，错误日志也应该有对应core的堆栈信息，可以提供相关信息
你好 默认lockdbxwaittimeout为1，如果这个提示超时，表示slave在提升为主的时候，正在apply的binlog无法在1s内执行成功，因此，锁超时。当这个参数调整为500后，可以成功，说明apply时间足够了。 另外，这个超时可能说明这个时候slave apply一个比较大的binlog，或者slave响应很慢。 请提供一下你当前的配置参数，可以执行`config get *`获得以及`info all` 另外，提供一下，调整lockdbxwaittimeout后，切换成功slave的相关日志。 此时，master执行了一些什么操作，重点关注 1. 是否存在大key 2. 是否存在时间复杂度O(N)的操作，详看 http://tendis.cn/#/Tendisplus/%E6%95%B4%E4%BD%93%E4%BB%8B%E7%BB%8D/redis%E5%85%BC%E5%AE%B9%E6%80%A7
tendis是`冷热混合存储`的关键组件之一，混合存储相关文档内容较多，还在整理中
How to repeat it?
If a slave improve to be a master, there are conditions: 1. slave is online 2. slave is not behind master too much More details in https://github.com/Tencent/Tendis/blob/dev-2.2/src/tendisplus/cluster/cluster_manager.cpp#L2601 You can see...
 可以把这个参数变小
这个情况应该是执行了正常shutdown的行为，资源回收，并刷盘等操作还在执行，并且gossip通讯相关线程仍在工作，所以其他节点没有及时对这个节点判死 可以尝试使用kill -9终止进程 收到shutdown指令，gossip 相关线程尽快退出应该可以加快这种情况的HA，我们评估下
可以看下shutdown逻辑，将cluster相关的线程退出提前，编译一个版本看看效果