作者回复: 数据会根据文档id并结合相应的hash算法将数据分发到不同的分片。所以，不同的shard上的数据肯定是不一样的。如果你说的是primay和replica上数据count不一样，那确实是有这样的可能。如果数据量不大，p和r上的数据应该会很快一致，如果数据量很小，数据从p到r需要很久，你需要检查集群是否存在性能问题

2019-11-11



4

朝伟

问老师两个问题 1、选主的过程会不会阻塞客户端请求? 2、故障转移期间客户端可以进行读写操作吗？如果以上2点都有影响、有没有什么方法可以平滑些

作者回复: 选主的过程应该很短，这个期间，如果有创建index或者分片reallocation有可能会出错。故障转移期间，如果只是黄色变绿，应该不影响读写，因为副本会提升为主分片。集群变红，代表有主分片丢失，这个时候会影响读写

2019-08-22



3

未成年

老师您好，对故障转移这一页ppt （图二），我有个疑问：会不会有这种情况，node1 在断开之前新进来了数据，这个时候node2，node3，去ping发现node1没了，p0的数据还没同步到r0，这个是时候r0升级位p0时数据就少了，这时候应该怎么办

作者回复: node如果丢失，如果没有落盘。就有丢失的可能。如果节点重新回来，会从translog中恢复没有写入的数据。

2019-08-05

2

3

文斌

老师你好，对于视频中的例子，如果节点id较小的node1后面又自动恢复了，那master会不会漂移到node1上

作者回复: active master节点在正常的情况下，一般就是固定一台，不会随意切换。其他的master节点主要用来确保系统的高可用

2020-02-16



2

踮脚时光

为什么我关掉 master 节点后直接访问不了集群了呢？节点 2 和节点 3 后台有打印重新分配、集群状态变更的信息，但是 http://127.0.0.1:9200/ 访问不了

作者回复: 报什么错？2和3都有相应日志，说明节点之间网络也没有问题啊

2019-10-26

3

1

Anthony

老师，故障转移的过程是不是就可以理解成，「副本分片提升为主分片的过程」

作者回复: 嗯可以

2020-04-21





超威丶

所以，老师，7之后的分片默认为1，这个能应用到生产环境？

作者回复: 几百万数据量的索引，一个主分片也是够的，需要设置一个副本分片，确保数据的安全。关于分片数的设定，后面有专门的一节。

2019-08-03





勁

老师你好，这里有个疑问，既然分片是datanode，一台机器出故障，然后两个分片又分配到其他两个节点，那这个数据也会转移吧

作者回复: 会转移的

2019-08-03

4



钱

这节有意思，看评论有些同学已经问了我想问的问题，我整理一下，加深印象： 1：选主的过程中可能存在问题的场景？选主的过程应该很短，这个期间，如果有创建index或者分片reallocation有可能会出错。 2：故障转移期间可能会出现问题的场景？故障转移期间，如果只是黄色变绿，应该不影响读写，因为副本会提升为主分片。集群变红，代表有主分片丢失，这个时候会影响读写。 3：故障转移，数据重新分配，消耗性能的避免方式？例如一个主分片不可用了。只要设置了副本分片，其中一个副本分片立即会将自己提升为主分片。同时会将自己的数据分配到一个新的replica上，有时候，我们只是重启一台机器，可以让这个reallocation的动作延迟一段时间再做，从而避免无谓的数据拷贝。老师，主分片挂啦，他的其中一个副本会立刻将自己提升为主。有个疑问，假如有两个副本怎么决定那个副本提升为主？会不会存在误判的情况，副本以为主挂了，其实没挂，但将自己提升为主啦？ 4：故障转移可能存在数据丢失的场景嘛？ node如果丢失，如果没有落盘。就有丢失的可能。如果节点重新回来，会从translog中恢复没有写入的数据。

2019-09-21



3

收起评论