HAproxy解决nginx-gridfs在MongoDB副本集选举后的读取问题

发表于 | 更新于

接上回，自从搭建起副本集之后，很嗨，再也不担心单机挂了之后数据丢失了。应用往MongoDB副本集写也做了相应配置。

在做nginx读取MongoDB副本集数据测试中，发现了新问题

按照 https://github.com/mdirolf/nginx-gridfs 中连接副本集的配置例子，如下：

1
2
3
4
5
6
location /gridfs/ {
    gridfs my_app field=filename type=string;
    mongo "foo"
          10.7.2.27:27017
          10.7.2.28:27017;
}

在主节点关闭后，其设置的第二个节点是不起作用的（我设置了五个，均不起作用，nginx读取MongoDB节点中的文件报错）

由此可见nginx-gridfs插件这里是有问题的，但是我们的web服务器已经在使用了这个插件，不能轻易更换，只能另寻他法。

经过测试，发现副本集在原主节点挂掉后，余下节点（包括新选举的主节点和从节点）都可以使用直连模式来读取文件。

于是一个大胆的想法浮现了，何不在nginx和副本集之间加个负载均衡器？ 嗯，我选了HAproxy。

HAproxy的介绍百度一大堆，我就不重复了，直接上配置文件（部分以变量代替）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
global
    maxconn 50000 #默认最大连接数,需考虑ulimit-n限制
    log 127.0.0.1 local0

defaults
    mode tcp #四层反向代理，不受套接字文件数量限制
    timeout connect 20s #haproxy将客户端请求转发至后端服务器所等待的超时时长
    timeout client 30s #客户端非活动状态的超时时长
    timeout server 30s #客户端与服务器端建立连接后，等待服务器端的超时时长
    timeout check 10s #健康状态监测时的超时时间，过短会误判，过长资源消耗\
    timeout http-keep-alive 60s  #长连接超时
    #option redispatch #当使用了cookie时，haproxy将会将其请求的后端服务器的serverID插入到cookie中，以保证会话的SESSION持久性
    #retries 3 #后端服务器的失败重连次数，链接失败次数超过此处值会将对应后端服务器标记不可用

frontend mongo-in
        bind *:29000
        log global #使用全局日志配置
        #option tcplog
        #option dontlognull 
        default_backend mongo  #定义默认转发的后端服务器

backend mongo #定义后端服务群default_servers
    balance roundrobin #分发策略,这里是轮询模式
    
    #check启用健康监测，监测MongoDB的服务端口，每个2秒监测一次，失败3次标记为不可用，成功2次恢复为可用
    server mongo_rs1 $MONGODB_RS1_IP:$MONGODB_PORT check port $MONGODB_PORT inter 2s rise 2 fall 3  
    server mongo_rs2 $MONGODB_RS2_IP:$MONGODB_PORT check port $MONGODB_PORT inter 2s rise 2 fall 3
    server mongo_rs3 $MONGODB_RS3_IP:$MONGODB_PORT check port $MONGODB_PORT inter 2s rise 2 fall 3
    server mongo_rs4 $MONGODB_RS4_IP:$MONGODB_PORT check port $MONGODB_PORT inter 2s rise 2 fall 3
    server mongo_rs5 $MONGODB_RS5_IP:$MONGODB_PORT check port $MONGODB_PORT inter 2s rise 2 fall 3

上了之后，问题解决，哈哈哈哈哈。。。。。。。。。。。。。。。。。

总结

  1. 如果用HAproxy转发HTTP连接，须考虑Linux的open files限制，如果是tcp的代理，可以忽略，其在内核就完成转发了。
  2. 多看官方文档。
  3. 任何解决方案都要考虑业务场景的真实需求。
  4. 这里因为对从节点的数据实时性要求不是即时同步，首要需求是数据的多份拷贝的完整性和服务的高可用。
0%