MongoDB Secondary 延时高（同步锁）问题分析
背景介绍
MongoDB 复制集里 Secondary 不断从主上批量拉取 oplog，然后在本地重放，以保证数据与 Primary 一致。同步原理参考MongoDB复制集同步原理解析
Secondary 拉取到一批 oplog 后，在重放这批 oplog 时，会加一个特殊的 Lock::ParallelBatchWriterMode 的锁，这个锁会阻塞所有的读请求，直到这批 oplog 重放完成。
MongoDB WiredTiger 存储引擎cache_pool设计 (上) -- 原理篇
## 1. MongoDB 多引擎体系 -- WiredTiger
MongoDB v.3.0之前的版本，默认使用`MMAP(MMap引擎)`方式对内存中的数据进行写盘存储，遭受了很多诟病。比如`并发受限的表锁、不支持压缩、不可控的IO`操作等，MMAP甚至不能称作一个完整的存储引擎(笔者的个人观点)，对数据(Btree的数据页、索引页)的操作甚至要依赖os的mmap(in_page_ca
MongoDB Secondary同步慢问题分析(续)
在MongoDB Scondary同步慢问题分析文中介绍了因Primary上写入qps过大，导致Secondary节点的同步无法追上的问题，本文再分享一个case，因oplog的写入被放大，导致同步追不上的问题。
MongoDB用于同步的oplog具有一个重要的『幂等』特性，也就是说，一条oplo
MongoDB副本集回滚那些事
回滚（rollback）操作是MongoDB副本集发生一些异常主备切换后可能发生的现象。回滚操作会撤销在当前节点上已执行的一些修改操作。
什么时候会触发回滚
MongoDB副本集节点上有个同步线程，负责拉取需要同步的oplog。被拉取oplog的节点称作同步源。那么，要回滚，首先要有一个同步源。
MySQL与MongoDB绝非替代
各位老铁们，不知道大家喜欢不喜欢看宫廷类的剧，都是后宫嫔妃之间的尔虞吾诈，勾心斗角，有你没我，有我没你的残酷事实。胜者为王，败者为寇这种思想好像从古代就一直延续到今日。非要分出个胜负，分出个谁好，谁坏才罢休。