(57)ElasticSearch重建索引且保证应用程序不用重启

  ElasticSearch中字段的类型一旦确定就不能修改,如果我们要修改其类型就要重新建mapping。然后把旧索引中的数据批量导入到新索引中。同时采用给索引起别名的方式使客户端应用程序不需要重启。

  1、演示字段类型一旦确定不能修改

  添加文档,同时默认创建了索引

PUT index1/type1/1
{
  "content":"2000-11-11"
}

  查询字段类型,content类型为date

GET index1/type1/_mapping
{
  "index1": {
    "mappings": {
      "type1": {
        "properties": {
          "content": {
            "type": "date"
          }
        }
      }
    }
  }
}

  添加字符串类型的文档报错。因为该字段已经映射成date类型了,要实现添加字符串类型的,那么必须把content的类型修改为string

PUT index1/type1/1
{
  "content":"I like Java"
}
{
  "error": {
    "root_cause": [
      {
        "type": "mapper_parsing_exception",
        "reason": "failed to parse [content]"
      }
    ],
    "type": "mapper_parsing_exception",
    "reason": "failed to parse [content]",
    "caused_by": {
      "type": "illegal_argument_exception",
      "reason": "Invalid format: \"I like Java\""
    }
  },
  "status": 400
}

  直接修改不成功,报错

PUT index1/_mapping/type1
{
  "properties": {
    "content":{
      "type":"text"
    }
  }
}
{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "mapper [content] of different type, current_type [date], merged_type [text]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "mapper [content] of different type, current_type [date], merged_type [text]"
  },
  "status": 400
}

  2、演示旧索引中的数据导入到新索引中

  在应用程序中,应用程序连接的是别名,我们只需要把别名关联不同的索引即可实现重建索引且保证应用程序不用重启

  1)给index1起别名为index2

PUT /index1/_alias/index2

  2)创建新索引

PUT /newindex
{
  "mappings": {
    "type1":{
      "properties": {
        "content":{
          "type":"text"
        }
      }
    }
  }
}

  3)执行先查询旧索引再导入到新索引操作

  由于旧索引中数据量可能很大,批量查询的时候,建议采用scroll api,并且采用多线程并发的方式来reindex数据,每次scroll就查询指定日期的一段数据,交给一个线程即可。

  示例:批量查询旧索引index1

GET /index1/type1/_search?scroll=1m
{
  "query": {
    "match_all": {}
  },
  "sort": ["_doc"],
  "size":2
}

  示例:批量导入新索引newindex

POST /_bulk
{"index":{"_index":"newindex","_type":"type1","_id":1}}
{"content":"1988-08-08"}

  4)删除index2与index1的别名关联,增加index2与newindex的别名关联

POST _aliases
{
  "actions": [
    {
      "remove": {
        "index": "index1",
        "alias": "index2"
      }
    },
    {
      "add": {
        "index": "newindex",
        "alias": "index2"
      }
  }
  ]
}

  5)查询验证

GET index2/type1/_search

  查询结果,可以看出index2关联的是新的索引(newindex中的数据是"content": "1988-08-08")

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 1,
    "max_score": 1,
    "hits": [
      {
        "_index": "newindex",
        "_type": "type1",
        "_id": "1",
        "_score": 1,
        "_source": {
          "content": "1988-08-08"
        }
      }
    ]
  }
}

原文地址:https://www.cnblogs.com/javasl/p/12686530.html

时间: 2024-07-30 12:22:57

(57)ElasticSearch重建索引且保证应用程序不用重启的相关文章

ELK学习总结(4-1)elasticsearch更改mapping(不停服务重建索引)

elasticsearch更改mapping(不停服务重建索引)原文 http://donlianli.iteye.com/blog/1924721Elasticsearch的mapping一旦创建,只能增加字段,而不能修改已经mapping的字段.但现实往往并非如此啊,有时增加一个字段,就好像打了一个补丁,一个可以,但是越补越多,最后自己都觉得惨不忍睹了.怎么办??这里有一个方法修改mapping,那就是重新建立一个index,然后创建一个新的mapping.你可能会问,这要是在生产环境,可行

Elasticsearch系列---实战零停机重建索引

前言 我们使用Elasticsearch索引文档时,最理想的情况是文档JSON结构是确定的,数据源源不断地灌进来即可,但实际情况中,没人能够阻拦需求的变更,在项目的某个版本,可能会对原有的文档结构造成冲击,增加新的字段还好,如果要修改原有的字段,只能重建索引了. 概要 本篇以实战方式讲解如何零停机完成索引重建的三种方案. 外部数据导入方案 整体介绍 系统架构设计中,有关系型数据库用来存储数据,Elasticsearch在系统架构里起到查询加速的作用,如果遇到索引重建的操作,待系统模块发布新版本后

MongoDB索引管理——创建索引,查看索引,删除索引,重建索引

先给users集合插入两条记录,然后用users集合来进行索引管理的演示: > user1={"name":"liming","age":20,"gender":"F"} { "name" : "liming", "age" : 20, "gender" : "F" } > db.users.in

ES重建索引(reindex)性能优化建议

Reindex官方文档 https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html Reindex简介 5.X版本后新增Reindex.Reindex可以直接在Elasticsearch集群里面对数据进行重建,如果你的mapping因为修改而需要重建,又或者索引设置修改需要重建的时候,借助Reindex可以很方便的异步进行重建,并且支持跨集群间的数据迁移.比如按天创建的索引可以定期重建合并到以

elasticsearch的索引自动清理及自定义清理

近发现elasticsearch近期索引文件大的吓人,清理了下之前的索引文件,发现服务器性能大大的减轻了一半,想一直保留近一个月的索引文件,但是又不想每个月手动清楚,在此写了一个小脚本 一. 手动删除 rm -rf *2016-07-* 二.api删除 curl -XDELETE 'http://127.0.0.1:9200/logstash-2016-07-*' 清理掉了所有 7月份的索引文件,我发现curl 删除比rm删除要快出很多 三.脚本加api删除(推荐) cat es-index-c

重建索引时,一些数值

重建索引,表记录1.4亿条,晚上九点半左右执行,几个数值,记录下来供参考 ALTER INDEX IX_IndustryIdLv2_UpdateTime ON dbo.Product_Info REBUILD WITH (ONLINE = ON)--晚上21:30执行用时11:17 ALTER INDEX IX_UserId_UpdateTime ON dbo.Product_Info REBUILD WITH (ONLINE = ON)--晚上21:30执行用时06:05 执行时,user c

对比:重建索引与更新统计

最近经常被问到的一个问题是关于在数据库维护过程,重建索引与更新统计的执行先后次序.通常,需要考虑以下几点,这里注意的是有两种统计:索引统计.列统计. 1)默认情况下,UPDATE STATISTICS 将会更新索引统计和列统计,如果语句中仅使用了COLUMNS选项,则只更新列统计,若仅使用了INDEX选项,则只更新索引统计 2)默认情况下,UPDATE STATISTICS语句仅采样表的一部分数据,使用UPDATE STATISTICS WITH FULLSCAN则会扫描全表 3)重建索引(如使

移动表到新表空间后重建索引

将某个表空间内的多个数据库表移动到另一个表空间后,由于没有处理索引,导致到新库中查询.插入等操作时,oracle报错: ORA-01502: 索引 'WWYSBI41.SYS_C0027004' 或这类索引的分区处于不可用状态 原因是仍用了之前表空间的索引,解决办法是重建这些索引. 对单个表索引, alter index <index_name> rebuild (online) 注:上面的index_name外面的<和>只是表示这是一个变量,并不是真的要加<与>. 对

SQLServer 重建索引前后对比

在做维护项目的时,我们经常会遇到索引维护的问题,通过语句,我们就可以判断某个表的索引是否需要重建. 执行一下语句:先分析表的索引 分析表的索引建立情况:DBCC showcontig('Table') DBCC SHOWCONTIG 正在扫描 'Table'' 表...表: 'Table'' (53575229):索引 ID: 1,数据库 ID: 14已执行 TABLE 级别的扫描.- 扫描页数................................: 228- 扫描区数........