Elasticsearch 通过索引阻塞实现数据保护深入解析

川长思鸟来 2024-04-24 20:43 39阅读 0赞

> ❤️作者主页：[小虚竹][Link 1]
> 
> ❤️作者简介：大家好,我是小虚竹。2022年度博客之星评选TOP 10?，Java领域优质创作者?，CSDN博客专家?，华为云享专家?，掘金年度人气作者?，阿里云专家博主?，51CTO专家博主?
> 
> ❤️技术活，该赏
> 
> ❤️点赞 ? 收藏 ⭐再看，养成习惯

老规矩，文末有送书的规则~~

#### 文章目录 ####

*  前言
 *  1、索引阻塞的种类
 *  2、什么时候使用阻塞？
 *   *  场景1：进行系统维护场景。
     *  场景2：保护数据不被随意更改场景。
     *  场景3：优化资源使用的场景。
     *  场景4：遵守安全规则场景。
 *  3、添加索引阻塞API
 *  4、解除设置 API
 *  5、小结
 *  6、参考
 *  7、粉丝福利
 *   *  福利0

## 前言 ##

[Elasticsearch][] 是一种强大的搜索和分析引擎，被广泛用于各种应用中，以其强大的全文搜索能力而著称。

不过，在日常管理 Elasticsearch 时，我们经常需要对索引进行保护，以防止数据被意外修改或删除，特别是在进行系统维护或者需要优化资源使用时。

Elasticsearch提供了一种名为“ **索引阻塞** （Index blocks）”的功能，让我们能够限制对某个索引的操作类型。

![97ac7b97f98250937ed6075a37b02970.png][]

Elasticsearch的索引阻塞功能在早期版本中就已存在，用于管理对索引的访问和操作。随着 Elasticsearch 版本的更新，该功能也在不断得到改进和扩展。

参见官方文档：[https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-blocks.html][https_www.elastic.co_guide_en_elasticsearch_reference_current_index-modules-blocks.html]

**大白话**——"索引阻塞"就是给我们的索引加把锁，防止别人随意修改。

## 1、索引阻塞的种类 ##

Elasticsearch中的索引阻塞可以根据需要，限制对索引的读取、写入或元数据操作。

所谓的元数据，可以理解为索引的基本信息和设置，比如索引包含哪些字段，这些字段是什么类型的等等。

这些阻塞可以通过动态索引设置添加或移除，也可以通过专门的API来添加，这样做的好处是能确保在添加写入阻塞后，所有索引的分片都正确地应用了阻塞，比如确保在添加写入阻塞后，所有正在进行的写入操作都已完成。

以下是一些动态索引设置，用于确定索引上存在的阻塞类型：

*  index.blocks.read\_only：设置为 true 使索引及索引元数据只读，设置为false则允许写入和元数据更改。
 *  index.blocks.read\_only\_allow\_delete：类似于index.blocks.read\_only，但也允许删除索引以释放更多资源。
 *  index.blocks.read：设置为 true 以禁用对索引的读取操作。
 *  index.blocks.write：设置为 true 以禁用对索引的数据写入操作。与read\_only不同，这个设置不影响元数据。例如，你可以调整带有写入阻塞的索引的设置，但不能调整带有read\_only阻塞的索引的设置。
 *  index.blocks.metadata：设置为true以禁用索引元数据的读写操作。

<table> 
 <thead> 
  <tr> 
   <th align="left">设置名称</th> 
   <th align="left">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left"><code>index.blocks.read_only</code></td> 
   <td align="left">设置为<code>true</code>使索引及索引元数据只读，设置为<code>false</code>则允许写入和元数据更改。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>index.blocks.read_only_allow_delete</code></td> 
   <td align="left">类似于<code>index.blocks.write</code>，但也允许删除索引以释放更多资源。磁盘基础的分片分配器可能会自动添加和移除这个阻塞。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>index.blocks.read</code></td> 
   <td align="left">设置为<code>true</code>以禁用对索引的读取操作。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>index.blocks.write</code></td> 
   <td align="left">设置为<code>true</code>以禁用对索引的数据写入操作。与<code>read_only</code>不同，这个设置不影响元数据。例如，你可以调整带有写入阻塞的索引的设置，但不能调整带有<code>read_only</code>阻塞的索引的设置。</td> 
  </tr> 
  <tr> 
   <td align="left"><code>index.blocks.metadata</code></td> 
   <td align="left">设置为<code>true</code>以禁用索引元数据的读写操作。</td> 
  </tr> 
 </tbody> 
</table>

解释一下：index.blocks.read\_only 和 index.blocks.write **区别**？

如下设置了禁止写入，但是可以修改索引的设置，比如：副本数的调整，这个是允许的。

PUT test-001/_settings
    {
      "blocks.write": true
    }
    
    PUT test-001/_settings
    {
      "number_of_replicas": 2
    }

但是换成这样：

PUT test-002
    PUT test-002/_settings
    {
      "blocks.read_only": true
    }
    
    PUT test-002/_settings
    {
      "number_of_replicas": 2
    }

如上的 read\_only 设置后，如果再进行修改索引设置的设置就会报错。

{
      "error": {
        "root_cause": [
          {
            "type": "cluster_block_exception",
            "reason": "index [test-002] blocked by: [FORBIDDEN/5/index read-only (api)];"
          }
        ],
        "type": "cluster_block_exception",
        "reason": "index [test-002] blocked by: [FORBIDDEN/5/index read-only (api)];"
      },
      "status": 403
    }

简而言之，index.blocks.write 允许你保护索引内容的稳定性，同时仍然可以调整索引的配置来应对不同的需求或进行优化。而 index.blocks.read\_only 则是一种更为严格的保护，确保索引在某段时间内完全不被更改。

## 2、什么时候使用阻塞？ ##

### 场景1：进行系统维护场景。 ###

比如，当你需要升级系统或者做一些关键的维护工作时，可能不希望在这期间有任何索引结构的变化。通过阻止别人修改索引的元数据，确保索引的设置保持不变，维护索引设置的稳定性。

### 场景2：保护数据不被随意更改场景。 ###

举例：如果咱们的业务数据是非常关键的，比如已经归档的日志或者历史记录，这些数据通常是不允许被更改的。防止关键数据被随意更改或删除，确保数据的完整性和准确性。

### 场景3：优化资源使用的场景。 ###

举例：有时候某个索引可能占用了太多资源，你可能暂时不想让它继续增长。通过控制索引的读写操作，帮助管理系统资源，避免因为资源过度使用而导致系统变慢或崩溃。

### 场景4：遵守安全规则场景。 ###

举例：对于一些敏感数据，可能要求严格的访问控制，不希望随便被读取或更改。对于需要严格控制的敏感数据，通过设置阻塞来限制数据的访问和修改，保障数据安全。

## 3、添加索引阻塞API ##

使用范例参考：

PUT /<index>/_block/<block>

*  <index>：（可选，字符串）逗号分隔的索引名列表或通配符表达式，用于限制请求。
 *  <block>：（必需，字符串）要添加到索引的阻塞类型。

举例，如下 API 用于给索引添加一个**阻塞**写入。

PUT /my-index-000001/_block/write

设置禁止写入后，如果再写入就会报错。

"reason": "index [my-index-000001] blocked by: [FORBIDDEN/8/index write (api)];"

![cc12ee1646589ccc78b70e0f263b2a48.png][]

通过执行 PUT /my-index-000001/\_block/write命令，我们可以向名为my-index-000001的索引添加一个写入阻塞。成功执行此命令后，任何试图写入该索引的操作都将被阻止，直到该阻塞被显式移除。

除此之外，最常用的一个锁叫做 blocks.metadata。当我们把这个设置开启（设置为true）后，别人就不能修改索引的元数据了。

举个例子，如果你在管理一个多租户的SaaS应用，每个租户都有自己独特的索引设置和映射。你肯定不希望有一天突然有人改变了这些设置，导致系统运行不正常。这时候，就可以使用 blocks.metadata 这个锁来防止索引的元数据被修改。

PUT test
    
    
    PUT test/_settings
    {
      "blocks.metadata": true
    }

如下的所有操作都会报错：

GET  test
    GET  test/_settings
    GET  test/_mapping
    
    PUT test/_doc/1
    {
      "title": "1111"
    }

但是，如下检索是可以正常进行的。

GET test/_search
    {
      "query": {
        "match_all": {}
      }
    }

## 4、解除设置 API ##

要解除已经设置的索引阻塞，可以将相应的阻塞设置修改为false或使用 null来移除特定的阻塞。例如，要移除索引的 read\_only阻塞，可以使用以下命令：

PUT /<index>/_settings 
    { "index.blocks.read_only": false }

请注意，在进行此操作之前，确保已经解决了导致设置阻塞的原因，如磁盘空间不足等。

## 5、小结 ##

Elasticsearch的索引阻塞功能为数据提供了一层额外的保护，确保数据能够按照预期安全、正确地被处理和访问。这套功能在系统维护、数据保护、资源优化和安全增强等方面特别有用。通过熟悉Elasticsearch提供的各种索引阻塞设置，可以有效管理对索引的访问，保障数据完整性，高效利用资源，并加强数据的安全性。正确使用这些强大的工具需要深入理解它们的作用和应用场景。

## 6、参考 ##

[https://kulekci.medium.com/elasticsearch-index-blocks-a-deep-dive-into-data-protection-b2ecc4b780c8 ][https_kulekci.medium.com_elasticsearch-index-blocks-a-deep-dive-into-data-protection-b2ecc4b780c8]

[7 年+积累、 Elastic 创始人Shay Banon 等 15 位专家推荐的 Elasticsearch 8.X新书已上线][Elasticsearch]

![在这里插入图片描述][cd24e16dc1e04ef1a9bf509f6d520b62.jpeg]

## 7、粉丝福利 ##

回馈粉丝们的支持，送《一本书讲透Elasticsearch：原理、进阶与工程实践》实体书给3位粉丝。一起学习！

### 福利0 ###

虚竹哥直接送3本好书，参与好评送书~

参与好评送书：随机抽取3位幸运读者，各送一本《一本书讲透Elasticsearch：原理、进阶与工程实践》实体书

统计截止时间：2024/03/13 19:00:00

请中奖的读者统计截止时间过后7天内私信虚竹哥收货地址，过期奖励作废哈！

我是宠粉的虚竹哥，请继续支持我，哈哈哈~

[Link 1]: https://xiaoxuzhu.blog.csdn.net/
[Elasticsearch]: http://mp.weixin.qq.com/s?__biz=MzI2NDY1MTA3OQ==&mid=2247494702&idx=1&sn=85eaf3e1e127008b0b130ccd70652557&chksm=eaabc406dddc4d107da2b88f1da65920d021c41b127ee89c1f6aafb70036c4af29fdeb7be498&scene=21#wechat_redirect
[97ac7b97f98250937ed6075a37b02970.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/bf44f6a790e24b3c883eb4d2c2fb2e56.png
[https_www.elastic.co_guide_en_elasticsearch_reference_current_index-modules-blocks.html]: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-blocks.html
[cc12ee1646589ccc78b70e0f263b2a48.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/f8ee36b0683e4a72b3cd9c35297a1c2f.png
[https_kulekci.medium.com_elasticsearch-index-blocks-a-deep-dive-into-data-protection-b2ecc4b780c8]: https://kulekci.medium.com/elasticsearch-index-blocks-a-deep-dive-into-data-protection-b2ecc4b780c8
[cd24e16dc1e04ef1a9bf509f6d520b62.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/24/18b78b5058c0496982302355a7e29e7e.jpeg