他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)elasticsearch 不小心把建好的索引删除了还能恢复吗_百度知道
elasticsearch 不小心把建好的索引删除了还能恢复吗
我有更好的答案
localhost:9200/_snapshot/my_backup" target="_blank">http://localhost:9200/_snapshot/my_backupSnapshot and restore 模块允许创建单个索引或者整个集群的快照到远程仓库. 在初始版本里只支持共享文件系统的仓库，但是现在通过官方的仓库插件可以支持各种各样的后台仓库，就可以只用下面的命令去获取这个仓库的信息$ curl -XGET '{
&type&://localhost。下面的这个命令注册了 一个名为my_backup 的共享文件系统仓库，快照将会存储在 &#47。快照根据集群中的唯一名字进行区分。 在仓库 my_backup 里创建一个名为snapshot_1 的快照可以通过下面的命令:$ curl -XPUT &quot:9200/_snapshot/my_backup/snapshot_1;mount/<a href="http。这个参数指明了每块的字节数;backups/index_1,index_2&,
&ignore_unavailable&: &true&,
&include_global_state&: false
&partial&: &false&}&#39;上述命令中通过 indices 参数指定快照包含的索引，这个参数支持同时配置多个索引 multi index syntax. 快照请求同样支持 ignore_unavailable 选项。把这个选项设置为 true 的时候在创建快照的过程中会忽略不存在的索引。默认情况下， 如果没有设置 ignore_unavailable 在索引不存在的情况下快照请求将会失败。通过设置 include_global_state 为false 能够防止 集群的全局状态被作为快照的一部分存储起来。默认情况下，如果快照中的1个或多个索引不是全部主分片都可用会导致整个创建快照的过 程失败。 通过设置 partial 为 true 可以改变这个行为。索引创建快照的过程是增量的。在给索引创建快照的过程中，Elasticsearch会分析存储在仓库中的索引文件并且只会复制那些自从上次快照 之后新建或有所更新的文件。这使得多个快照以一种紧凑的方式存储在同一个仓库里。创建快照的过程是以非阻塞方式执行的。一个索引在创 建快照的同时能够被检索和查询。尽管如此，快照保存的是在开始进行创建快照的那个时间点的索引的视图。所以，在开始创建快照之后的记 录不会出现在这个快照里。在主分片启动之后创建快照的过程就会立即开始，并且之后不会改变位置。在1.2.0版本之前如果集群重新定位或者 新加入快照的索引初始化主分片会导致快照操作失败。从1.2.0版本开始，Elasticsearch会等待重新定位和初始化分片然后再创建快照。除了给每个索引创建拷贝快照还能存储集群的全局元数据，包括集群的设置和模板。临时的设置和已经注册的快照仓库不会被作为快照的一部 分来存储。任何时候在集群里只能有一个创建快照的操作在执行。当一个分片正在创建快照的时候，这个分片就不能被迁移到别的节点，因为这会影响重 新平衡和分配过滤的过程。一旦这个分片的快照建立完成，这个分片就可以根据现有的分配过滤和重新平衡算法被迁移到别的节点上。如果快照已经建立，我们可以通过如下的命令去获得快照的信息：$ curl -XGET &localhost:9200/_snapshot/my_backup/snapshot_1&通过如下的命令可以把仓库里所有的快照列出来：$ curl -XGET &localhost:9200/_snapshot/my_backup/_all&可以通过如下的命令将仓库里的某个快照删除：$ curl -XDELETE &localhost:9200/_snapshot/my_backup/snapshot_1&当一个快照从仓库里删除之后，Elasticsearch会把所有和这个快照相关并且不被其它快照使用的文件删除。如果对正在创建的某个快照执行 删除操作，则创建快照的过程会被取消，并且会把创建过程中所有已经创建的文件删除。因此，删除操作可以用来取消那些由于误操作引起的 长时间运行的快照操作。恢复快照可以使用如下的操作来恢复：$ curl -XPOST &localhost:9200/_snapshot/my_backup/snapshot_1/_restore&默认情况下，快照中的所有索引以及集群状态都会被恢复。在恢复请求中可以通过 indices 来指定需要被恢复的索引，同样可以使用 include_global_state 选项来防止恢复集群的状态。 indices 支持配置多个索引multi index syntax.rename_pattern 和 rename_replacement 选项可以在恢复的时候使用正则表达式来重命名index。详见 这里.$ curl -XPOST &localhost:9200/_snapshot/my_backup/snapshot_1/_restore& -d &#39;{
&indices&: &index_1,index_2&,
&ignore_unavailable&: &true&,
&include_global_state&: false,
&rename_pattern&: &index_(.+)&,
&rename_replacement&: &restored_index_$1&}&#39;恢复操作可以在正在运行的集群上操作。尽管如此，已经存在的index只有在关闭之后才能被恢复。恢复操作会自动打开关闭的恢复的索引， 并且创建新的索引如果索引不存在。如果集群状态也是恢复的，如果恢复的模板不存在会被新建，如果同名的模板已经存在则会被覆盖代替。 恢复的持久性设置会被增加到现存的持久性设置里。快照状态新增于[1.1.0]正在运行的快照的详细信息可以通过如下的命令来获取：$ curl -XGET &localhost:9200/_snapshot/_status&在这种格式下，这个命令将会返回所有正在运行的快照的信息。通过指明仓库名字，能够把结果限定到具体的一个仓库。$ curl -XGET &localhost:9200/_snapshot/my_backup/_status&如果仓库名字和快照id都指明了，这个命令就会返回这个快照的详细信息，甚至这个快照不是正在运行。$ curl -XGET &localhost:9200/_snapshot/my_backup/snapshot_1/_status&同样支持多个快照id：$ curl -XGET &localhost:9200/_snapshot/my_backup/snapshot_1,snapshot_2/_status&监控快照/恢复进度有多种方法去监控运行时快照和恢复的进度。这2个操作都支持 wait_for_completion 参数，如果这个了这个参数将会阻塞客户端直到 操作完成。这是最简单的用来获取操作完成的通知的方法。快照操作的进度也可以通过定时的调用下面的命令去获得：$ curl -XGET &localhost:9200/_snapshot/my_backup/snapshot_1&注意，获取快照信息的操作和快照操作使用相同的资源和线程池。所以，执行获取快照信息的操作的时候如果大量的分片正在做快照操作， 在获取快照新的操作返回结果之前需要先等到资源可用才行。如果分片太大，等待的时间会挺长。要获取更多的及时和完整的关于快照的信息，可以使用如下的快照状态命令。$ curl -XGET &localhost:9200/_snapshot/my_backup/snapshot_1/_status&获取快照信息的方法只返回关于快照进度的基本信息， 快照状态命令会返回正在做快照的每个分片的具体信息。恢复进度是装在Elasticsearch的标准恢复机制里的。所以，标准恢复监控服务能够被用来监控恢复的状态。当恢复操作在集群里执行的时候， 集群通常会变成 红色 状态。可能是因为恢复操作是从恢复被恢复的索引的主分片开始的。在恢复操作期间主分片变的不可用使得集群处于 红色 状态。一旦主分片的恢复完成，Elasticsearch会切换到标准复制过程，在这个过程会创建需要的复制个数，并且集群状态变为 黄色 。一旦所有的复制分片创建完成，集群会变成 绿色 状态。集群健康操作只提供恢复过程的大致状态。可以通过 indices recovery 和 cat recovery APIs 获取恢复过程当前状态的更详细的信息。停止正在运行的快照和恢复操作快照和恢复框架只允许同一时刻每次运行1个快照或恢复操作。如果正在运行的一个快照是误操作导致的或者运行的时间太长，可以用快照删除 操作去终止正在执行的快照操作。快照删除操作会检查要删除的快照是否正在运行，如果是，删除操作先停止这个快照操作，然后再将它从仓库 里删除。恢复操作是用用标准的分片回复机制。因此，任何正在运行的恢复操作可以通过删除正在恢复的索引来取消。注意，所有被删除的索引的数据也 会被从集群里删除。://true&,
&settings& : {
&compress& : &quot?pretty&#39;{
}}如果没有指定仓库名字;my_backup&://my_backup 这个目录。$ curl -XPUT &#39;/_all&#39;wait_for_completion 参数指定创建snapshot的请求是否等待快照创建完成再返回。 默认情况下:9200/_snapshot/my_backup&#39; -d &#39;{
&indices&quot: &fs&) 是使用共享的文件系统去存储快照。 在 location 参数里指定的具体存储路径必须和共享文件系统里的位置是一样的并且能被所有的数据节点和master节点访问。 另外还支持如下的一些参数设置：location
指定快照的存储位置。必须要有compress
指定是否对快照文件进行压缩. 默认是 true.chunk_size
如果需要在做快照的时候大文件可以被分解成几块，集群中所有打开和启动的索引是自动创建快照的: &fs&。max_restore_bytes_per_sec
每个节点恢复数据的最高速度限制. 默认是 20mb/smax_snapshot_bytes_per_sec
每个节点做快照的最高速度限制。默认是 20mb/: {
&location&;compress&quot。默认是 null (表示不限制块大小);settings&quot。也可用不同的单位标识。 比如，1g,
}}&#39;一旦仓库被注册了;: &quot?wait_for_completion=true&s只读URL仓库URL仓库(&quot:9200/_snapshot&#39;or$ curl -XGET &#39;
采纳率：92%
来自团队：
为您推荐：
其他类似问题
&#xe675;换一换
回答问题，赢新手礼包&#xe6b9;
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)&&&#187;&& &&&#187;&& Elasticsearch的备份和恢复
Elasticsearch的备份和恢复
On 日 Views: 14,822
距离上次讲已经快一个半月了，作为一个半路出家的前端开发，简单的使用中也体验到了Elasticsearch的强大。目前在一个自己开发的小站点中，使用Elasticsearch索引了近200W简单数据，占用资源极小，搜索速度极快。下一步打算优化一下分词（目前使用的是标准分词器），所以想先备份一下，于是有了今天的文章。
Elasticsearch的一大特点就是使用简单，api也比较强大，备份也不例外。简单来说，备份分两步：1、创建一个仓库。2、备份指定索引。下面一步一步来：
1、创建一个仓库（creating the repository）
备份数据之前，要创建一个仓库来保存数据，仓库的类型支持Shared filesystem, Amazon S3, HDFS和Azure Cloud。下面以文件系统为例：
PUT http://127.0.0.1:9200/_snapshot/my_backup
"type": "fs",
"settings": {
"location": "/mount/backups/my_backup"
上面的代码，我们创建了一个名叫my_backup 的备份，存放在本地的/mount/backups/my_backup 目录下。除了location 参数外，还可以通过max_snapshot_bytes_per_sec 和max_restore_bytes_per_sec 来限制备份和恢复时的速度，如下：
POST http://127.0.0.1:9200/_snapshot/my_backup/
"type": "fs",
"settings": {
"location": "/mount/backups/my_backup",
"max_snapshot_bytes_per_sec" : "50mb",
"max_restore_bytes_per_sec" : "50mb"
注意：第一段代码用的是PUT 请求，用来创建repository，第二段代码用的是POST 请求，来修改已经存在的repository。
2、备份索引
仓库创建好之后就可以开始备份了。一个仓库可以包含多个快照（snapshots），快照可以存所有的索引，部分索引或者一个单独的索引。可以给索引指定一个唯一的名字：
PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1
上面的代码会将所有正在运行的索引，备份到my_backup仓库下一个叫snapshot_1的快照中。上面的api会立刻返回，然后备份工作在后台运行。如果你想api同步执行，可以加wait_for_completion 标志：
PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true
上面的方法会在备份完成后才返回，如果数据量大的话，会花很长时间。
如果只想备份部分索引的话，可以加上indices 参数：
PUT http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2
"indices": "index_1,index_2"
3、删除备份
不要手动删除文件（Elasticsearch一贯主张使用api操作，尤其是大集群中），删除snapshot_2：
DELETE http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2
如果备份正在后台进行，也可以直接删除来取消此次备份。
4、查看备份信息
直接使用GET 请求即可：
GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_2
返回类似下面的值：
"snapshots": [
"snapshot": "snapshot_2",
"indices": [
".marvel_",
"state": "SUCCESS",
"start_time": "T13:01:43.115Z",
"start_time_in_millis": 5,
"end_time": "T13:01:43.439Z",
"end_time_in_millis": 9,
"duration_in_millis": 324,
"failures": [],
"shards": {
"total": 10,
"failed": 0,
"successful": 10
如果要查看所有索引的信息，使用如下api：
GET http://127.0.0.1:9200/_snapshot/my_backup/_all
另外还有个一api可以看到更加详细的信息：
GET http://127.0.0.1:9200/_snapshot/my_backup/snapshot_3/_status
具体不说了，自己玩一下就知道了，详细内容可以查看
备份好后，恢复就更容易了，恢复snapshot_1里的全部索引：
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
这个api还有额外的参数：
POST http://127.0.0.1:9200/_snapshot/my_backup/snapshot_1/_restore
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
参数indices&设置只恢复index_1索引，参数rename_pattern 和rename_replacement 用来正则匹配要恢复的索引，并且重命名。和备份一样，api会立刻返回值，然后在后台执行恢复，使用wait_for_completion&标记强制同步执行。
另外可以使用下面两个api查看状态：
GET http://127.0.0.1:9200/_recovery/restored_index_3
GET http://127.0.0.1:9200/_recovery/
如果要取消恢复过程（不管是已经恢复完，还是正在恢复），直接删除索引即可：
DELETE http://127.0.0.1:9200/restored_index_3
更多内容参看。
原文链接：
转载请保留原文链接
按日期查看
2018年二月
12131415161718
19202122232425ElasticSearch 导入数据的一个坑，肯定不止我一人中招
· Ruby China
今天使用 ES 时，碰到一个坑，估计其他同学或许也会碰到，特此分享一下。
step 1 Model
BetOrder 是一个订单的 model，搜索时我打算使用 term query。我把 mapping 设置为
index: 'not_analyzer' ，故意不分词，以便精确搜索。
Gem 用的是
# model/bet_order.rb
# Set up index configuration and mapping
# Searching tokens exactly
settings do
mappings do
indexes :title,
index: 'not_analyzed'
indexes :nickname,
index: 'not_analyzed'
indexes :user_key,
index: 'not_analyzed'
indexes :out_trade_no, index: 'not_analyzed'
indexes :trade_no,
index: 'not_analyzed'
indexes :buyer_email,
index: 'not_analyzed'
step 2 导入数据
BetOrder.import
step3 悲剧了，导入数据后 mapping 不对
然后是debug 呀，debug。。。。。
翻来覆去的找，没找到原因，最后去翻了翻 elasticsearch-rails 的源码，原来导入数据的时候需要加上参数 force: true,才会根据 mapping 创建索引。
BetOrder.import force:true
源码地址：
问题解决，上一个正常 mapping
顺便请教一个问题：为什么第一次 import 数据时，作者不根据 model 中定义的 mapping 创建。这算不算一个bug？
昨天也遇到这个, 这应该算是文档没写清楚吧 , 我学得按照model定义创建 mapping。另外，想请教下有没有用中文分词，用的哪个？谢谢
可以先BetOrder.elasticsearch.create_index!来创建索引，这个时候会按照map来配置。然后可以index各个document。
直接导入没有具体测试，确定import前没有建立index mapping哦。
model里面我是直接用
mapping do
settings do
mappings do
不知具体什么区别？
我测过了，直接 import 时创建的 mapping 是错误的。
中文分词我用的 mmseg_analyzer，效果还不错。
分词以前一直用mmseg，从sphinx到es。不过最近代码里面产品只需要sql like的程度就够，还没有去配置分词。
这个问题之前我也遇到过，还是得读源码。另外使用ik进行处理性能不高，会出现HTTP timeout。后来换成mmseg了。
问下，mapping时比如标签列表tags: [''abc','def']去存储，
当index not_analyzed时候，可以用filter查询查找到
当默认string analyzed时候，可以query match来，这个时候用filter搜索不到
如何让他可以filter又可以在搜索时候被match到，是怎么mapping的
我也被坑了，3q
后方可回复, 如果你还没有账号请点击这里 。
共收到 8 条回复}