takenliu(Liurui)
takenliu(Liurui)
## Description 现象： 1.进程持有较多的socket句柄没有释放，通过下面的命令统计，结果为几个到几万个不等。 $ lsof -p $pid -K|grep "protocol: TCP"|wc -l 2.即使业务请求量很低的时候，可能消耗cpu单个核的100%。 top命令：%CPU 100.0 同时通过perf命令查看，主要消耗在于NetworkAsio::timeoutProcess()函数。 ## Expected Behavior ## Current Behavior ## Possible Solution ## Steps to Reproduce (for...
## tendis用户收集 感谢社区用户对tendis长期以来的支持，为了了解用户的使用现状，了解大家的使用需求，更好的为社区服务，在此向大家收集用户使用情况。 ## 用户信息 您可以在此issue下回复相关使用情况。可以包括不限于如下方面： 1）公司/组织/学校名称，行业，LOGO（选填） 2）国家和地区（选填） 3）联系方式（选填） 4）主要使用场景，主要使用命令等（选填） 5）集群量，数据量，吞吐等（选填） 6）使用中觉得好用的地方，需要改善的地方（选填） 7）希望tendis支持什么功能（选填） 8）其他（选填） 感谢您的反馈～🌹
## Description 配置文件里面配置rocks.max_open_files，rocks.max_background_jobs，不能生效 ## Expected Behavior ## Current Behavior ## Possible Solution ## Steps to Reproduce (for bugs) ## Context ## Your Environment * Operating System and version: * Machine...
## Description 出现上锁超时"Lock wait timeout"，无法定位具体是被谁占用了锁。 ## Expected Behavior ## Current Behavior ## Possible Solution ## Context
1. redis cluster可能会有两个集群信息融合的问题。 社区的issue和修复如下： https://github.com/redis/redis/issues/7287 https://github.com/redis/redis/pull/7330/commits/3984dc6539e35cbd5fd2fdd4fda3e56f35244beb tendisplus跟redis社区一样也有这个问题。 2. 分析 在我们整体的集群协议设计中，nodeid是节点之间建立互信的基石。所以几乎所有的ClusterMsg在处理前 都会检查发送方的nodeid，如果不认识sender，大多数消息包的内容会被接收方全部或部分忽略不处理。 但是MEET包是一个特例，即使接收方不认识MEET包的sender，它也会对包里面的内容(包括Gossip信息) 无条件信任，还会将sender也加入自己的node列表，将sender的信息往集群中扩散。 基于MEET包这样的特殊性，我们在设计中会刻意限制MEET包的使用场景，只有类似DBA/管控系统下发 CLUSTER MEET命令将新建节点加入集群的时候，节点之间才发送MEET包。 但是当前在PING包中的Gossip处理流程中打破了这样的限制，每次发现一个不认识的节点，都会直接发起 handshake，而handshake内部发送的是MEET包，如果某次HA过后集群中有残留的节点信息，它的地址 (ip,port)又被另一个集群中一个新创建的节点复用，这里就可能诱发两个集群之间元信息的污染。 举个例子来详细说明上述集群元信息污染问题触发的场景： 假设集群X中原本有3个节点：A,B,C，其中C发生了故障而下线，但是集群X清理C节点信息的时候有残留， A forget成功而B forget失败，等forget的有效期过后，B就会将C的信息通过gossip重新传播给A； A节点会对C节点handshake，此时因为C节点下线，建连就会失败，A会把C再次删除； 后面一直重复此过程，B将C传播给A，A对C做handshake超时，A将C删掉； 直到某一天，另一个集群Y中新创建了一个节点D，D刚好复用了C的(ip,port)；A基于C的(ip,port)发起的 handshake，实际上会发给D。此时D本身应该不信任A发送的ClusterMsg，但因为当前代码中A发送的 是特殊的MEET包，导致D信任了A，并将集群X中元数据和集群Y做了融合，造成元数据污染。 目前线上已经出现了类似上述例子的集群融合问题，为了避免问题再次发生，我们修改了Gossip的处理逻辑，...
## Description ### 问题 针对rocksdb的columnfamily的参数，在配置文件中配置"rocks.xxx y"，当前是对default_cf和binlog_cf同时生效。 通过"config set rocks.xxx y"，目前只对default_cf生效，需要改为对binlog_cf也生效。 ### 希望达到的效果： 以rocks.enable_blob_files为例。 配置文件： rocks.enable_blob_files 1 （default_cf和binlog_cf都生效） rocks.defaultcf.enable_blob_files 1 （default_cf生效）（当前版本处理不对） rocks.binlogcf.enable_blob_files 1 （binlog_cf生效） 动态修改： config set rocks.enable_blob_files 1 （default_cf和binlog_cf都生效）（当前版本处理不对） config...
## Description blobdb功能开启后，KVTtlCompactionFilter::FilterBlobByKey()需要读取value，进行string类型的过期判断，导致读压力较大，考虑优化相关性能。 ## Expected Behavior ## Current Behavior ## Possible Solution ## Context
## Description 整个过程流程较多，时间较长，之前中间某个过程出现问题，需要全部重做，不利于运维。通过重构，打印关键步骤的启动日志，过程改为可重入，使得该功能可以很方便的运维。 ## Expected Behavior ## Current Behavior ## Possible Solution ## Context
## Description 一些异常情况下，这里需要有终止的方法。 现场堆栈： ## Expected Behavior ## Current Behavior ## Possible Solution ## Steps to Reproduce (for bugs) ## Context ## Your Environment * Operating System and version: *...
## Description dump-file-keep-num和dump-file-keep-hour只在从节点生效。 假设主节点A和从节点B，起初没有设置这两个参数，B节点的dump目录已经有较多binlog文件。这时候发生主从切换，再设置这两个参数的时候，因为B节点提成了主节点，不会触发清理binlog文件的逻辑。 ## Expected Behavior ## Current Behavior ## Possible Solution ## Steps to Reproduce (for bugs) ## Context ## Your Environment * Operating System and version: *...