weipatty
weipatty
图一：由于溢出，SetHoldPaxosLogCount设进去的值为300.  图二：溢出的函数  图三：相关函数  如图，由于GetOldestInstanceIDofFile这个函数返回值是int，会导致如果instanceid>int max时溢出，进而影响agentmonitor定时设SetHoldPaxosLogCount的值，这样会导致快照前保留的paxoslog只有300条， 结合这里： > 关于PhxPaxos在LoadCheckpointState后会进行自杀 > 首先这里自杀的目的是为了方便程序以新的Checkpoint状态机数据来进行重启，那么会涉及到如何重启的问题。PhxPaxos只负责自杀，不负责重启，开发者需要自行解决重启的问题。我们微信内部一般会通过守护进程的方式来自动拉起工作进程。 > > 其次当你使用到PhxPaxos多个Group的特性的时候，那么当多个Group整体落后非常多的时候，每个Group都需要各自进行Checkpoint的对齐，那么每个Group都要经历一次自杀的操作，想象如果有100个Group，那么程序可能要经过100次重启才能完成Checkpoint的对齐，效率非常低下。这时候开发者需要根据自己的业务特性，在LoadCheckpointState的函数过程中进行一些延缓等待操作，使得一次自杀可以完成更多Group的Checkpoint对齐。 对于业务的表现就是：如果有一个点落后一点点（5分钟），那么就会进入传输Checkpoint模式，这是一个重操作，5分钟内完成不了，那么导致落后5分钟，又进入checkpoint模式，循环
之前我们用了phxsql，然后也遇到了leveldb seek的问题，后面发现新版本做了修复。 看修复方法是先找缓存，这样是可以解决gtid_executed检查的问题。 我主要有以下几个疑问吧： 1. replication模块中也会有leveldb的seek操作吧，这样还是有概率会seek到标记删除但未实际删除的gtid？ 2. 所以为啥不是改掉seek操作，本意也不是遍历，而不是用get？我看seek匹配到之后也会check gtid匹配才算找到，没理解这个操作的用义 3.关于EventStorage的锁的问题，我们发现这个问题是paxos的io_loop线程在smexecute时在等这把锁，但它只是访问uuid_map。这把锁的本意应该是保护uuid_map吧？ 感觉锁的力度是否有点大，锁对整个过程加锁了（导致leveldb操作也阻塞了io_loop的内存操作），是否应该只在访问了互斥变量时才上锁。 我自己调查这个问题也一周了，想到的解法是改掉seek和锁力度只锁变量，但后面发现官方也遇到这个问题。。。所以想问下官方解法的考虑和我想的解法是否可行？
大概情况为： 三台机子，一台由于末知原因一直追同步不上。然后剩下两台选不出主(主信息过期，一直选不出)。集群不工作。 调查发现剩下的两台机子的agent_monitor线程都hang住了 一台估计hang在 ``` int Committer :: NewValueGetIDNoRetry(const std::string & sValue, uint64_t & llInstanceID, SMCtx * poSMCtx) { LogStatus(); int iLockUseTimeMs = 0; bool bHasLock = m_oWaitLock.Lock(m_iTimeoutMs, iLockUseTimeMs); if...