yuan

same question

here are my config. Is it my wrong configuration by cause? m3db version: 1.1.0 m3coordinator.yml ``` listenAddress: 0.0.0.0:7201 logging: level: info clusters: - namespaces: - namespace: default retention: 720h type:...

@BertHartm Thank you very much，I get it。

@mengxifl 哥们哪个公司的啊，我们也是m3+grafana，技术栈很相似，一起交流交流呀

@wesleyk It seems that coordinator can connect to m3DB normally. After namespace is set to ready with force params, the cluster can also read and write data normally. Everything seems...

@gibbscullen same problem，version: m3_1.1.0 need help

> @yackushevas -- thanks for following up on this. For the time being, use the placement set API on the coordinator to manually move the shards from initializing to available....

same question, Have you solved your problem yet？how？


@TendisDev 感谢您细致的答疑。 关于`cluster-node-timeout`，Redis Cluster好像有个这样的注意点： > 一些阻塞命令（flushall, del key1 key2 …）会造成redis在‘cluster-node-timeout’时间内无法响应其他节点的ping请求， 从而导致其他节点都把该redis标记出了pfail状态，进而产生failover Tendis是多线程的，应该不存在这个问题吧？ 另外，我还有一些问题，我发现Tendis在kill时会丢失一部分写入成功的数据，以下是我的测试步骤： 1. 三主三从集群，version：2.3.1-rocksdb-v5.13.4 2. 持续写入新数据，并记录下写入成功的数据 3. kill 其中一个master。此时Tendis自动failover，部分写请求失败 4. 使用step 2写入成功的key来获取数据，发现部分数据读取的结果为null 5. 启动被杀掉的老master，并手动failover使其重新成为主，再次获取step 4获取失败的key，仍然为null 6. 以上步骤应该可以证明，在自动failover期间，Tendis丢失了一部分返回给客户端OK的数据 我们可以接受kill -9丢失一部分数据，但是kill时数据丢失是否可以规避？