南北有不同的公共接入monodb如何部署？
大神好，我最近接手一个别人弄的项目或叫平台，是用于监控公司各服务（主要是http接口的一些QPS,5xx,延迟等指标）并生成报表的。 指标数据是用mongodb储存的，其实叫 tokumx （是不是对mongodb有优化目前我还不确定）。他的部署方案我感觉有点不可思议，想拿出来跟大神们看下，并说下优化方案。
现在的部署是 南北有两个IDC各有 3台机，南北各部署一个独立的mongodb副本集群，也就是单边是 1 个master, 1个 secondary ,1 个仲裁。 广州房机作为全量数据中心，（北京的只存储最近）。不可思议的地方是 两边数据同步不是靠mongodb同步机制的(因为不是跨机房副本集群)，而是北京的写入后再代码里显式调用 接口把数据写到广州的。 这个问题貌似也不大，大的问题是广州的这个副本集作为全量数据中心（业务的查询都在这并且只查master，副本没开启读），造成负载超高，磁盘IO的写入超高。随时都要死掉的节奏。
这个业务监控数据延迟不允许超过1分钟，因为监控就是分钟级上报的。所以我推测他们只允许查master就是基于这个原因，但我查看了延迟情况，很好，几乎不存在延迟。
所以：我想彻底的优化这个东西，大神们，方案应该是如何 的？
回答：
首先TokuMX不是MongoDB的产品，它最早是基于MongoDB 2.4的开源代码独立出来的一个分支，由TokuMX团队维护（现在已经被Percona收购）。但是TokuMX应用并不是非常广泛（无意贬低同行），个人对它了解有限。从最初版本到最近（去年？）被Percona收购期间TokuMX没有太多的动作，不过收购之后倒是有推出一个基于MongoDB Storage API的新版本。所以，先查清楚你是用的哪个版本，如有必要先升级以避免一些基本的bug。
然后从MongoDB的角度而言，上面的场景是一个很典型的多中心写，一中心读的Geo Distributed MongoDB集群。相关的内容太多无法在这里很清楚地解释，大致原理是说每个中心放一个分片，这些分片又各自通过复制集复制到集中那个数据中心，这样你的广州机房就具有全量数据可供查询。整个过程不用程序，接口调用，完全是基于MongoDB本身的运行机制。这个架构的具体细节在MongoDB的白皮书：MongoDB Multi Datacenter Deployments中有详细的讲解，建议阅读。
最后说说IO高的问题。按照前面的描述多个数据中心的数据最终都集中到广州，那它的压力自然是北京广州的总和，比较高是正常的。至于是不是太高以致于影响性能，上面的描述中没有提供任何相关指标，所以无法判断。通常的步骤应该是先进行查询、写入的优化，如果压力还是无法满足需求，则考虑分片。虽然用程序把数据从其他数据中心复制到广州来的做法欠妥，但是也没到不可接受的程度。而且既成事实，它没有明显的缺陷的话还是以优化为主。如果对数据的时效性不是那么敏感，可以考虑开启副本读，但要警惕总压力过大。如果每个结点的压力超过66.67%，你就将失去高可用，也就是说失去一个结点后其他结点也会一起当机。
补充：关于压力的问题，因为图上的读写IO不知道是怎么得来的，不知道是不是我理解的那样。如果是MongoDB，我会用mongotop看一下实例花在读写上的时间，确定到底是读压力大还是写压力大。如果是Linux系统可以看一下iowait确定读写压力有多高再做判断。对MongoDB而言如果写上面花的时间多，再加上iowait大，那瓶颈在写IO上，可能能做的事情不多。如果是缺少索引造成的CPU压力，应该是读IO大才对，这种情况你优化索引才会有意义。当然现在是在看TokuMX，情况是怎样我也没法下结论。
假设确实是缺少索引引起的压力问题，建索引是必须的。最安全也是最快的建索引办法是之前的问题中跟你提到的，把每个结点（先从后主）拆下来建索引再加回去，用这种方式逐一把索引建完就算解决了。30G的collection并不算大，建索引没有问题。但是在压力大的集群中，强烈建议使用上述逐一加索引的方式做。索引不止会带来CPU的压力，更重要的是它会遍历整个集合，破坏你内存中的热数据，同时很大幅度增加磁盘IO，光从负载70%以下这点是不能保证加索引一定不会影响线上运行的。
回答：
非常感谢您在我连续多个提问中给出相当高质量的回复，从你的回复中加深了我对mongo理解，
我接下来的优化手段只是在广州这个全量数据中心下手，北京的节点负载不高，广州中心master和secondary机子负载我贴个图：其中上图是master 过去 24小时的负载，下图则是secondary的负载
我第一阶段的优化就先开启secondary的读，然后业务查询切换到secondary上，看master负载下降，如果能下降到 load 70左右，CPU 70%左右，我就直接给所有大collectoins无索引的加索引，索引加完预计负载还会再次下降。因为负载高我觉得很大原因是慢查询多造成的，虽然写入也高。先解决慢查询，10秒甚至更长的查询很多，几乎是大collect无索引。
目标是要下降到 70%水平以下。但有个别collection体积相当巨大，30G，我认为是很大的，给它加索引风险多大？
第二阶段，如果第一阶段不理想，就就考虑做分片存储，用时间作为片键。具体方法到时再想。
以上，你觉得如何？
另外，他们在广州服务器上用的是 tokumx-e-2.0.2-linux-x86_64，而北京的则是tokumx-1.5.1-linux-x86_64。
好不可思议
以上是 南北有不同的公共接入monodb如何部署？ 的全部内容， 来源链接： utcz.com/p/196535.html
