下次更新时间为:2020 年 1 月 15 日
课件和 Demo 地址
https://github.com/geektime-geekbang/geektime-mongodb-course
作者回复: 各个分片的数据理论上是互不重叠的,所以如果配置服务器坏的话,你将无法组成一个新的分片集群,但是你的数据可以合并起来组成非分片的集群。
当然,考虑到分片集群某一时间点会有正在分片之间迁移的数据,这个数据合并还是有点风险。
所以你的配置服务器,也是需要3个节点来保证数据的可靠性。
作者回复: 一般原则是不需要。
如果你的应用场景用不到数据合并(连统一报表都不需要),并且数据量级在10亿级以上,可以考虑作为一个特殊优化手段做分表。
作者回复: 棒棒的!
作者回复: 官方的建议不管读还是写,都用分片来解决。百万级的并发算是很大了,如果是点查为主的读操作占绝大多数,那么一个节点理论上支撑10万以上并发是可以的,当然必须是那种32/64 核高CPU的物理服务器。 Oppo的同学分享过单集群支撑100万+并发,该集群由14个分片组成,14x3共42台机器
作者回复: 我可以执行。。。
MacBook-Pro-4:tmp tjworks$ mongodump -d local -c oplog.rs -q '{ts:{$lt:Timestamp(1415928580, 1),$gt: Timestamp(1415928529, 1000)}}'
2020-01-16T08:01:22.401+0800 writing local.oplog.rs to
2020-01-16T08:01:22.414+0800 done dumping local.oplog.rs (0 documents)
MacBook-Pro-4:tmp tjworks$
作者回复: 当你使用read majority的时候,mongo会在主节点有额外的一些状态记录。他会根据这个这些信息来决定返回哪个版本的值给你,并不需要去请求多个节点。
作者回复: 你给个例子好一点,不用100个,就2个
作者回复: 我先mark一下你的问题,在更新完所有课程后我会考虑追加一些内容。
作者回复: 4.2 开始支持分片事务了。
作者回复: 能否提供一个比较具体的场景我可以针对性的回答?
作者回复: 请看后续章节
作者回复: 谢谢!
作者回复: 谢谢您的认可!再接再厉!