最近配置了下服务器的mongo的replica(实际使用的是tokumx 1.5.x),配置方法也很简单(比如参考这里),因为服务器空闲很多,所以配置了一个primary两个secondary. 在客户端配置的时候,read preference使用的是nearest. 因为在同一区域,所以client会从三台机器上负载均衡地读取信息.
周一演示的时候,发现系统有点问题.老的数据还可以,新增的修改则非常奇怪,查询结果有时候是改之前的,有时候是之后的.replica同步的delay是0,设置复制集的同步时间是3秒,但实际上想要查询结果稳定,那差不多已经好几分钟后了.
检查后台,并没有发现什么异常,只是某个secondary从primary同步,另一个从第一个secondary同步.这看起来也非常合理.随便去掉一个secondary,换成一primary,一secondary,一arbiter格局.发现同步就没有问题了.
总之,很遗憾的,没有发现错误的根源,只是workaround了下.但还是作为一个记录,保留一下.
5 Comments
eliteYang · April 27, 2015 at 18:19
@yuik 我主要还是想用更快的mysql,redis毕竟查询方面受限还是很多,所以我看了下tukudb,貌似就是查询快了,tokuMX是给MongoDB用的,我倒是没接触MongoDB,不了解,不过他们两作为客户端,应该还是比较好的
yu · April 27, 2015 at 18:51
@eliteYang mongo和mysql相比,没有关联查询,但本身就可以做成复杂结构.
mongo支持的数据规模和速度都很不错,至少目前单表70M的规模看起来还是非常轻松.
toku的确主要是对查询做了优化,但是其实还有一些奇怪的问题,比如查询xx.count()本来是获得结果的数量.mongo是秒出,但toku若调用这个function瞬间卡死了就…我们当时选用toku纯粹是mongo占用的硬盘太大的囧.
eliteYang · April 25, 2015 at 14:08
tukuDB有测试过吗?怎么样?我一直没测试过,MongoDB我暂时还用不上,都是用redis
yu · April 25, 2015 at 19:29
@eliteYang toku和mongo基本可以无缝移动迁移,代码的client代码基本不需要修改.速度很快–当然不能跟redis比啦.
toku一个很好的地方是index索引优化了,占用硬盘空间比mongodb小很多.
我们需要储存一大堆结构化的数据,redis不太够放.
另外,我们把东西丢SSDB去了,它是基于leveldb的,速度看起来不比redis慢,而且可以存放更多的东西,以前redis重启一下要半天,简直要杀人….
yu · April 25, 2015 at 19:31
@eliteYang ssdb的接口和redis还是有很多区别的,迁徙需要花费一点精力.