Ceph Monitor源码机制分析（二）—— 初始化

Ceph Monitor源码机制分析（二）—— 初始化

2 Monitor的初始化
Monitor的启动过程，相对比较简单，具体过程参见ceph_mon.cc这个源码文件。大概可以分为以下几部分：

介绍ceph_mon命令能够处理的参数以及使用方法
根据配置文件指定的mon_data目录创建名为store的MonitorDBStore实例并且打开数据目录。判断当前数据目录的使用情况是否超过报警限制。并且读出store的magic number确保store是正常的。
mon第一次启动时，会执行mkfs操作构建monmap，之后的启动从store中读出monmap，并从中获取mon的ip地址以后Messengerbind使用以及mon的rank值。所以如果第一次mon配置错误，后续修改mon的配置文件，重新再启动mon是不会生效的。
创建一个Monitor数据通信的Messenger，并且设置messager的policy以及throttler。
创建并初始化Monitor实例mon。初始化分为两个阶段preinit()和init()，在preinit()阶段主要初始化了paxos和各个paxosservice以及health_monitor，在init()阶段主要是初始化timer定时器、将monitor添加到dispatcher列表中并进行bootstrap()。从bootstrap()开始也就进入了Monitor的选举流程，这个会在下一节详细介绍。
Monitor进程只创建了一个Messenger，也就意味着它只有一个dispatch_queue和一个dispatcher线程，所有的请求都会排队。另外，Monitor还会初始化一个timer，其会创建一个线程用来处理所有的消息超时event，包括probe、propose、lease等消息，所以这些消息也是串行处理的。这事Monitor中两个真正做事的线程。所以当你在集群中执行命令半天不返回时，八成是因为Monitor的dispatch队列堵有消息排队了，而根本原因可能是Monitor store数据更新缓慢造成的，这有可能是磁盘有问题，也有可能是LevelDB/RocksDB有大量冗余数据导致读取缓慢。
————————————————
原文链接：https://blog.csdn.net/scaleqiao/article/details/52242345