你不会是程序猿吧?

ES容灾技术探讨和测试

yangmf2040 发表了文章 • 3 个评论 • 5648 次浏览 • 2021-10-27 13:33 • 来自相关话题

ES灾备技术调研


早就听说极限网关了,最近有个ES要做灾备,就搜集了下技术方案:

  1. 应用双写两个集群

  2. 跨集群复制CCR

  3. 极限网关

    三个方案的优缺点我也简单整理了下:

  4. 优点:自主研发,想怎样就怎样;缺点:难,水平、时间都是成本

  5. 优点:实施简单;缺点:需要license

  6. 优点:部署灵活,功能齐全;缺点:不熟悉,没用过



    貌似方案 3,比较理想。不熟悉,那就多用用,测试测试找找感觉。



    测试环境 笔记本


    | 主集群:A | 7.14.1 | 10.0.2.15:9214 | Rbac+tls | 节点数:1 |
    | --------- | ------ | -------------- | -------- | --------- |
    | 备集群:B | 7.13.2 | 10.0.2.15:9213 | Rbac+tls | 节点数:2 |
    | 极限网关 | 1.3.0 | 0.0.0.0:8000 | tls | 实例数:1 |

    wpsF088.tmp_.jpg




    wpsF089.tmp_.jpg




    网关下载


    先下载极限网关:http://release.elasticsearch.cn/gateway/snapshot/

    解压后,可看到有几个预定义的配置,方便大家快速上车。


    wpsF08A.tmp_.jpg




    网关配置


    这次是做灾备,应该就是在 dc-replica.yml的基础上改比较妥当,配置还是比较多的 300多行,很多都是为了保证两个集群数据一致性,解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息,还有网关也可选择tls,不用手工生成证书,非常方便。

    贴下我修改的地方

    wpsF08B.tmp_.jpg



    wpsF08C.tmp_.jpg





    启动网关


    wpsF08D.tmp_.jpg




    两个集群都是 available ,说明连接应该ok



    测试场景:围绕主备集群之间数据复制展开


    1. 主备集群间复制创建、写入、删除索引操作


    目的:对网关(A集群)创建索引test,对test索引写文档,能自动同步到B集群


    初始情况A、B无test

    wpsF09E.tmp_.jpg


    wpsF09F.tmp_.jpg



    手工put test索引到网关

    wpsF0A0.tmp_.jpg


    wpsF0A1.tmp_.jpg


    wpsF0A2.tmp_.jpg


    A,B集群都创建成功


    用loadgen写点文档进去吧,loadgen直接写网关

    wpsF0A3.tmp_.jpg



    wpsF0A4.tmp_.jpg



    wpsF0A5.tmp_.jpg



    都10000条写入成功,如果查看是0的话,先refresh下索引

    看下文档


    wpsF0A6.tmp_.jpg




    简单校验一下

    wpsF0A7.tmp_.jpg




    wpsF0A8.tmp_.jpg



    感觉没问题,删点文档看看,把那23个删了吧

    wpsF0A9.tmp_.jpg




    再看看

    wpsF0AA.tmp_.jpg




    wpsF0BA.tmp_.jpg




    更新524个文档看看

    wpsF0BB.tmp_.jpg



    wpsF0BC.tmp_.jpg



    wpsF0BD.tmp_.jpg



    增、删、改 完事



    2. 主集群故障的处理和恢复


    目的:主集群故障后,网关如何处理收到的请求:读、写


    Kill 掉 A 集群,模拟主集群故障

    网关直接有报错说连不上A集群

    此时对网关查询、写入数据都会报错


    wpsF0BE.tmp_.jpg




    重新启动主集群后,一切正常



    3. 备集群故障的处理和恢复


    目的:备集群故障,读、写主集群不受影响,备集群恢复后,自动追数据直到两边数据一致


    Kill 掉B集群,网关报错,B集群无法连接

    wpsF0BF.tmp_.jpg






    对A集群进行写入一个新文档,并查询下

    wpsF0C0.tmp_.jpg




    wpsF0C1.tmp_.jpg






    启动B集群,查看,已自动添加了新的文档

    wpsF0C2.tmp_.jpg





    4. 主集群容灾切换


    目的:主集群故障,短时间不可用,网关切换指向备集群作为主集群,A集群作为备集群;待A集群恢复后,自动追数据


    KILL A 集群 模拟A集群故障

    Kill 网关,切换配置:

    wpsF0C3.tmp_.jpg





    启动网关,B是主了,available

    wpsF0C4.tmp_.jpg






    写B集群,删除前面创建的 test 索引,新建test2索引,并插入文档

    wpsF0C5.tmp_.jpg




    wpsF0D6.tmp_.jpg






    启动A集群,检查数据,有test2索引,且文档一致

    wpsF0D7.tmp_.jpg





    5. 主集群故障恢复后,网关回切


    目的:假设A集群已经完全恢复,网关回切,A集群为主,B集群为备

    Kill网关,恢复配置,再启动网关

    再次测试写入test2 检查能否同步成功

    写网关

    wpsF0D8.tmp_.jpg




    查看A集群

    wpsF0D9.tmp_.jpg




    查看B集群

    wpsF0DA.tmp_.jpg




    两个集群数据一致,主备角色也恢复到最初了

    **测试环境变更


    中间工作比较忙,中断了测试,也就十来天吧

    不成想 网关更新了,我就下了新版本的gateway和ES-7.15.1 继续捣鼓

    环境 笔记本

    | 主集群:es-751primary | 7.15.1 | 10.0.2.15:7151 | No:Rbac、tls | 节点数:1 |
    | --------------------- | ------------------------ | -------------- | ------------- | --------- |
    | 备集群:es-751backup | 7.15.1 | 10.0.2.15:7152 | No:Rbac、tls | 节点数:1 |
    | 极限网关 | 场景6:1.4.0场景7:1.5.0 | 0.0.0.0:8000 | No:tls | 实例数:1 |



    wpsF0DB.tmp_.jpg






    网关不光版本升级了,配置文件也稍稍有些变化,新版本示例配置如下

    wpsF0DC.tmp_.jpg




    本着不会就猜的原则,我还是能做到见名之知意的

    我仅仅对 cross-cluster-replication.yml 做了简单的修改,就是和前面一样



    6. ES由代理暴露的能否正常工作


    目的:检验,比如由nginx代理ES的时候,网关能否正常工作


    使用 nginx 代理后端的ES

    80-->primary

    81-->backup

    wpsF0DD.tmp_.jpg




    测试下反向代理工作是否正常

    wpsF0DE.tmp_.jpg






    启动网关,网关里elasticsearch资源指向nginx,没错就改了下 url

    wpsF0DF.tmp_.jpg






    开始测试,增删改查 once more,还是对着网关操作

    创建索引

    wpsF0E0.tmp_.jpg




    PUT 文档

    wpsF0F0.tmp_.jpg




    抄家伙

    wpsF0F1.tmp_.jpg




    看看数量

    wpsF0F2.tmp_.jpg




    简单对比下

    wpsF0F3.tmp_.jpg


    给 code为500的文档增加一个字段 new_field

    wpsF0F4.tmp_.jpg




    直接通过代理查询,检验数据

    wpsF0F5.tmp_.jpg






    没问题,测试删除

    删除单条

    wpsF0F6.tmp_.jpg



    wpsF0F7.tmp_.jpg



    wpsF0F8.tmp_.jpg





    批量删除

    wpsF0F9.tmp_.jpg






    看看结果

    wpsF0FA.tmp_.jpg




    删除索引,并确认真的删除

    wpsF10B.tmp_.jpg





    关调backup集群,然后primary集群创建索引后,再启动backup集群,看能否自动追平

    wpsF10C.tmp_.jpg






    创建test2索引

    wpsF10D.tmp_.jpg




    顺手put个文档

    wpsF10E.tmp_.jpg




    Primary上查看

    wpsF10F.tmp_.jpg




    OK 启动backup

    wpsF110.tmp_.jpg




    妈的 奇迹



    7. 请求压缩功能如何


    目的:看看客户端和网关分别在不同的请求压缩配置下,是否工作正常


    在网关的配置中,看到了 compress 压缩,也设计几个场景测试下

    网关配置里面有个压缩的配置,意思是消费线程往ES发送请求的时候是否启用gzip压缩。

    默认是 true

    wpsF111.tmp_.jpg






    7.1 用压缩的方式写网关,但网关不启用压缩


    我们把网关配置中的true改成false

    wpsF112.tmp_.jpg






    启动网关

    wpsF113.tmp_.jpg






    开始写数据,写的过程中,随机停止backup集群,等待一会儿后再启动

    wpsF114.tmp_.jpg




    网关可看到 backup集群,从不可用到可用

    wpsF115.tmp_.jpg




    看看网关的队列情况,这时候backup队列应该堆积了不少请求

    wpsF116.tmp_.jpg




    等待队列被消费完后,我们对比数据。

    wpsF117.tmp_.jpg




    简单看看文档条数

    wpsF128.tmp_.jpg




    wpsF129.tmp_.jpg




    用网关对比下数据看看

    wpsF12A.tmp_.jpg




    妥妥的一致



    7.2 用压缩的方式写网关,网关也启用压缩


    就把前面网关贴图的false改成true

    启动网关

    wpsF12B.tmp_.jpg






    压缩写入

    wpsF12C.tmp_.jpg




    写入过程中,随机重启backup集群

    网关日志

    wpsF12D.tmp_.jpg




    等待网关backup队列消费完毕,后对比数据

    wpsF12E.tmp_.jpg



    wpsF12F.tmp_.jpg







    没得问题,下一场



    7.3 用不压缩的方式写网关,网关也不启用压缩


    网关配置compress: false,后启动网关

    wpsF130.tmp_.jpg




    不压缩请求

    wpsF131.tmp_.jpg




    中途随机重启backup集群

    wpsF132.tmp_.jpg



    队列消费完后对比数据

    wpsF133.tmp_.jpg




    数据一致



    7.4 用不压缩的方式写网关,网关backup队列的消费线程使用压缩


    wpsF134.tmp_.jpg




    写入过程中,停止backup集群,稍等一会儿后启动backup集群

    wpsF135.tmp_.jpg




    观察网关的backup 队列情况

    wpsF145.tmp_.jpg




    等消费完之后,我们对比数据

    数量一致

    wpsF146.tmp_.jpg



    wpsF147.tmp_.jpg






    用网关来对比下两个集群的test索引的数据

    wpsF148.tmp_.jpg






    至此,关于跨集群复制的场景测试可以告一段落了,功能大家也看到了确实强大,部署也很灵活,对环境无侵入,直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口,替换原有的协调节点,应用无感知。



    此外,极限网关还有很多别的使用场景和激动人心的功能,像在线修改查询、请求限流、请求流量分析,这都是保障ES集群稳定运行的手段。



    看到一款国产软件如此强大很欣慰,很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景,我们ES圈(论坛)多交流交流。让我也看看你们的场景和测试是怎样的。

    最后一个图,我也不知道咋回事,请忽略。

从es读取数据的时候 也会从副本里面读取码?还是replicas 只是做一个数据备份的作用?

Charele 回复了问题 • 2 人关注 • 2 个回复 • 1886 次浏览 • 2021-10-27 15:58 • 来自相关话题

es master节点内存不断攀高问题

yuechen323 回复了问题 • 3 人关注 • 2 个回复 • 1786 次浏览 • 2021-11-01 19:08 • 来自相关话题

初次学习ES,字段前为何多了些符号?是否正确,望老师帮解决一下,谢谢

wanmony 回复了问题 • 2 人关注 • 3 个回复 • 1069 次浏览 • 2021-10-27 14:48 • 来自相关话题

Elasticsearch:从 Spring Boot 应用中连接 Elasticsearch

liuxg 发表了文章 • 1 个评论 • 1376 次浏览 • 2021-10-25 14:14 • 来自相关话题

我将使用库 spring-boot-starter-data-elasticsearch  来和 Elasticsearch 进行连接。这种方法非常简单直接。 https://elasticstack.blog.csdn ... 58680
我将使用库 spring-boot-starter-data-elasticsearch  来和 Elasticsearch 进行连接。这种方法非常简单直接。 https://elasticstack.blog.csdn ... 58680

elasticsearch bluk 之后搜索不到数据

zhuyangping 回复了问题 • 2 人关注 • 2 个回复 • 1026 次浏览 • 2021-10-25 11:38 • 来自相关话题

关于tokenizer与synonym tokenfilter执行顺序的问题

nofearinmyheat 回复了问题 • 2 人关注 • 2 个回复 • 1157 次浏览 • 2021-10-31 22:39 • 来自相关话题

bulk update更新,存在小部分数据未更新成功。版本是5.6.3,更新field为null 的操作,求解。

God_lockin 回复了问题 • 3 人关注 • 1 个回复 • 1579 次浏览 • 2021-10-27 09:46 • 来自相关话题

cat/indices 查看有nested对象的index文档数量有延迟

Charele 回复了问题 • 2 人关注 • 1 个回复 • 1196 次浏览 • 2021-10-22 16:35 • 来自相关话题

elasticsearch源码测试用例怎么跑

回复

zekaifeng 回复了问题 • 2 人关注 • 1 个回复 • 1936 次浏览 • 2021-10-31 22:39 • 来自相关话题

Segment 和 倒排索引的关系

Kevin_23 回复了问题 • 2 人关注 • 2 个回复 • 1970 次浏览 • 2021-10-28 08:50 • 来自相关话题

path.repo 配置了多个路径后 仓库切换出现错误

Charele 回复了问题 • 3 人关注 • 2 个回复 • 1820 次浏览 • 2021-10-21 15:58 • 来自相关话题

ES 大数据量,频繁聚合查询请求,导致集群异常?

laoyang360 回复了问题 • 4 人关注 • 4 个回复 • 2866 次浏览 • 2021-10-24 11:35 • 来自相关话题

使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求

medcl 发表了文章 • 7 个评论 • 4858 次浏览 • 2021-10-16 11:31 • 来自相关话题

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:http://极限网关.com/

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

    这两个集群都是 http 协议的。

    实现步骤


    今天用到的是极限网关的 switch 过滤器:https://极限网关.com/docs/references/filters/switch/

    网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

    定义两个集群资源


    ```
    elasticsearch:

    • name: v2
      enabled: true
      endpoint: http://192.168.3.188:9202
    • name: v7
      enabled: true
      endpoint: http://192.168.3.188:9206
      ``<br /> <br /> 上面定义了两个集群,分别命名为v2v7`,待会会用到这些资源。

      定义一个服务入口


      ```
      entry:

    • name: my_es_entry
      enabled: true
      router: my_router
      max_concurrency: 1000
      network:
      binding: 0.0.0.0:8000
      tls:
      enabled: true
      ``<br /> <br /> 这里定义了一个名为my_es_entry的资源入口,并引用了一个名为my_router的请求转发路由,同时绑定了网卡的0.0.0.0:8000也就是所有本地网卡监听 IP 的8000端口,访问任意 IP 的8000端口就能访问到这个网关了。<br /> <br /> 另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。<br /> <br /> 为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。<br /> <br /> 最后,通过设置max_concurrency` 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

      定义一个请求路由


      ```
      router:

    • name: my_router
      default_flow: cross-cluster-search
      ``<br /> <br /> 这里的名称my_router就是表示上面的服务入口的router参数指定的值。<br /> <br /> 另外设置一个default_flow来将所有的请求都转发给一个名为cross-cluster-search` 的请求处理流程,还没定义,别急,马上。

      定义请求处理流程


      来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

      ```
      flow:

    • name: v2-flow
      filter:
      • elasticsearch:
        elasticsearch: v2
    • name: v7-flow
      filter:
      • elasticsearch:
        elasticsearch: v7
        <br /> <br /> 然后,在定义额外一个名为 `cross-cluster-search` 的 flow,如下:<br /> <br />
    • name: cross-cluster-search
      filter:
      • switch:
        path_rules:
        • prefix: "v2:"
          flow: v2-flow
        • prefix: "v7:"
          flow: v7-flow
          <br /> 这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 `v2:`开头的请求,则转发给 `v2-flow` 继续处理,如果是 `v7:` 开头的请求,则转发给 `v7-flow` 来处理,使用的用法和 CCS 是一样的。so easy!<br /> <br /> 对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 `cross-cluster-search` 的 filter 最后再加上一个 `elasticsearch` filter,前面前缀匹配不上的都会走它,假设默认都走 `v7`,最后完整的 flow 配置如下:<br /> <br />
          flow:
    • name: v2-flow
      filter:
      • elasticsearch:
        elasticsearch: v2
    • name: v7-flow
      filter:
      • elasticsearch:
        elasticsearch: v7
    • name: cross-cluster-search
      filter:
      • switch:
        path_rules:
        • prefix: "v2:"
          flow: v2-flow
        • prefix: "v7:"
          flow: v7-flow
      • elasticsearch:
        elasticsearch: v7
        ```

        然后就没有然后了,因为就配置这些就行了。

        启动网关


        假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

        <br /> ➜ gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd<br /> [10-16 11:00:52] [INF] [app.go:228] initializing gateway.<br /> [10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0<br /> [10-16 11:00:52] [INF] [api.go:260] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br /> [10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]<br /> [10-16 11:00:52] [INF] [entry.go:225] auto generating cert files<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available<br /> [10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a><br /> [10-16 11:00:53] [INF] [app.go:309] gateway is running now.<br />

        可以看到网关输出了启动成功的日志,网关服务监听在 <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a>

        试试访问网关


        直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

        <br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000" rel="nofollow" target="_blank">https://localhost:8000</a> <br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />

        正如前面配置所配置的一样,默认请求访问的就是 v7 集群。


        访问 v2 集群


        <br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:/" rel="nofollow" target="_blank">https://localhost:8000/v2:/</a> <br /> {<br /> "name" : "Solomon O'Sullivan",<br /> "cluster_name" : "es-v246",<br /> "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",<br /> "version" : {<br /> "number" : "2.4.6",<br /> "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",<br /> "build_timestamp" : "2017-07-18T12:17:44Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "5.5.4"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
        查看集群信息:
        <br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:_cluster/health" rel="nofollow" target="_blank">https://localhost:8000/v2:_cluster/health</a>\?pretty<br /> {<br /> "cluster_name" : "es-v246",<br /> "status" : "yellow",<br /> "timed_out" : false,<br /> "number_of_nodes" : 1,<br /> "number_of_data_nodes" : 1,<br /> "active_primary_shards" : 5,<br /> "active_shards" : 5,<br /> "relocating_shards" : 0,<br /> "initializing_shards" : 0,<br /> "unassigned_shards" : 5,<br /> "delayed_unassigned_shards" : 0,<br /> "number_of_pending_tasks" : 0,<br /> "number_of_in_flight_fetch" : 0,<br /> "task_max_waiting_in_queue_millis" : 0,<br /> "active_shards_percent_as_number" : 50.0<br /> }<br />
        插入一条文档:
        <br /> ➜ loadgen git:(master) ✗ curl-json -k <a href="https://localhost:8000/v2:medcl/doc/1" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/doc/1</a> -d '{"name":"hello world"}'<br /> {"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}% <br />
        执行一个查询
        <br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:medcl/_search" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/_search</a>\?q\=name:hello <br /> {"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% <br />
        可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

        访问 v7 集群


        <br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v7:/" rel="nofollow" target="_blank">https://localhost:8000/v7:/</a><br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />

        Kibana 里面访问


        完全没问题,有图有真相:

        Jietu20211016-114041.jpg




        其他操作也类似,就不重复了。

        完整的配置


        ```
        path.data: data
        path.logs: log

        entry:

    • name: my_es_entry
      enabled: true
      router: my_router
      max_concurrency: 10000
      network:
      binding: 0.0.0.0:8000
      tls:
      enabled: true

      flow:
    • name: v2-flow
      filter:
      • elasticsearch:
        elasticsearch: v2
    • name: v7-flow
      filter:
      • elasticsearch:
        elasticsearch: v7
    • name: cross-cluster-search
      filter:
      • switch:
        path_rules:
        • prefix: "v2:"
          flow: v2-flow
        • prefix: "v7:"
          flow: v7-flow
      • elasticsearch:
        elasticsearch: v7

        router:
    • name: my_router
      default_flow: cross-cluster-search

      elasticsearch:
    • name: v2
      enabled: true
      endpoint: http://192.168.3.188:9202
    • name: v7
      enabled: true
      endpoint: http://192.168.3.188:9206
      ```

      小结


      好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

ES索引是否支持限制一个分片的最大segment数量?

tongchuan1992 回复了问题 • 3 人关注 • 2 个回复 • 1585 次浏览 • 2021-10-21 14:21 • 来自相关话题