【ES实战】Elacticsearch6开始的CCR的实践-Toy模板网

这篇具有很好参考价值的文章主要介绍了【ES实战】Elacticsearch6开始的CCR的实践。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Elacticsearch6的CCR的实践

基本流程

CCR 的主从索引的建立流程

按照上述流程的操作步骤

两个集群建立远程连接关系

在从索引所在的集群下执行以下命令。这样就可以知道远程集群的地址了。
```
PUT /_cluster/settings
{
  "persistent" : {
    "cluster" : {
      "remote" : {
        "leader" : { 
          "seeds" : [
            "127.0.0.1:9300" 
          ]
        }
      }
    }
  }
}
```
leader是对远程连接的命名，可以采用与远程集群名一样的名称，增加识别性。seeds配置的是远程集群的连接地址，支持多地址，使用,号分隔，"ip/域名:tcp端口","ip/域名:tcp端口"。

查询集群已配置远程关系
```
GET /_remote/info
```

创建主索引

在远程集群上创建常规索引index1，要求索引开启软删除。

PUT /twitter
{
  "settings" : {
    "index" : {
      "number_of_shards" : 1,
      "number_of_replicas" : 0,
      "soft_deletes" : {
        "enabled" : true 
      }
    }
  },
  "mappings" : {
    "_doc" : {
      "properties" : {
        "user" : {
          "type" : "keyword"
        },
        "post_date" : {
          "type" : "date"
        },
        "message" : {
          "type" : "keyword"
        }
      }
    }
  }
}

直接通过CCR的API，创建从索引，同时建立建立主从关系和开启复制。

在从索引所在的集群执行。

PUT /twitter-copy/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster" : "demo-ccr-2",
  "leader_index" : "twitter"
}

先创建与主索引一致的索引，之后再创建主从关系开启数据复制了。

创建待从索引（此时还是常规索引）

PUT /twitter-copy
{
  "settings" : {
    "index" : {
      "number_of_shards" : 1,
      "number_of_replicas" : 0,
      "soft_deletes" : {
        "enabled" : true 
      }
    }
  },
  "mappings" : {
    "_doc" : {
      "properties" : {
        "user" : {
          "type" : "keyword"
        },
        "post_date" : {
          "type" : "date"
        },
        "message" : {
          "type" : "keyword"
        }
      }
    }
  }
}

关闭待从索引
```
POST /twitter-copy/_close
```

建立主从关系，开启复制

PUT /twitter/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster" : "demo-ccr-1",
  "leader_index" : "twitter-copy"
}

CCR 的主从索引的建立效果图

当主从索引复制关系建立之后，主索引的mapping变化，从索引也是同样复制的，主索引支持读和写操作，从索引支持读操作。

CCR支持对复制进程进行管理

查询复制情况
```
GET /twitter-copy/_ccr/stats
```
暂停复制
```
POST /twitter-copy/_ccr/pause_follow
```
恢复复制
```
POST /twitter-copy/_ccr/resume_follow
```
解除主从复制关系，即从索引不再从主索引复制数据，支持读写操作。
CCR 的主从复制关系解除流程
1. 先暂停复制
```
POST /twitter-copy/_ccr/pause_follow
```
2. 在关闭从索引
```
POST /twitter-copy/_close
```
3. 解除主从关系
```
POST /twitter-copy/_ccr/unfollow
```
4. 打开从索引
```
POST /twitter-copy/_open
```

CCR应用场景分析

容灾备份场景

主要是了防止单一机房或集群不可用之后，可以快速的切换到备份的集群上恢复对外服务。借助CCR可以支持灾难恢复和高可用性。

容灾等级定义

级别	内容	说明
第一级	本地数据容灾	在服务器硬件故障后，恢复使用，但是无法保障业务的连续性，数据极大可能缺失，恢复耗时长。
第二级	本地应用容灾	应对计算机硬件层面的故障，应用系统可以快速切换，保障业务的连续性。理解为，部署多个应用，当其中一个应用故障，流量转向剩下的应用，保障业务连续可用。
第三级	异地数据冷备份	在本地将关键数据备份后，发送异地保存。发生故障后，将备份的数据进行恢复。问题是，存储介质难于管理。如果备份的数据量很大的话，难以及时恢复，对业务影响很大，损失的数据量也较大。
第四级	异地异步数据容灾	在异地建议一个数据备份点，通过网络以异步的方式进行数据备份。备份点指进行数据的备份，不进行业务的处理。在对待灾害的的容忍程度与第三级相同。由于使用网络进行数据备份，因此，两个数据点的同步程度比第三级高，数据损失少。
第五级	异地同步数据容灾	除了数据是以同步方式进行外，其他基本和第四级相同。出现故障时，数据的损失较少，基本可以做到零损失。但是系统恢复较慢，投入成本也大。同步数据容灾有距离限制，超过一定范围（10km~100km）后，性能下降明显。与第四级别有个相同的问题：没有备用应用系统，无法保障业务的连续性。
第六级	异地异步应用容灾	在异地建立一个与生产系统相同的备用系统，采用异步的方式进行数据复制。当主系统发生故障时，备用系统接替其工作，这个级别的容灾可以保障数据的少量丢失，又可以及时切换，保障业务的连续性。
第七级	异地同步应用容灾	在异地建立一个与生产系统相同的备用系统。采用同步的方式进行数据复制。当主系统发生故障时，备用系统接替其工作。此级别，发生灾难时，可以基本保障数据零丢失和业务的连续性。

数据的异步复制指定期将主存储的数据传到备份数据点，或者定期由备份点拉取主存储的数据。定期代表会有时间间隔，数据复制是以批处理的形式的。定期的周期长度基本是复制的延迟，主备的存在较大差异数据量。

数据的同步复制指实时或近实时的将主存储的数据传输到备份数据点，或者实时的由备份点拉取主存储的数据。实时传输，传输的数据采用小块或者流的形式，最小化网络和资源的使用，复制的延迟低。主备的差异数据量较小。

下面是两种数据备份架构方式（数据单向复制）

单一容灾数据中心

CCR 的单一容灾数据中心效果图

多地容灾数据中心

CCR 的多地容灾数据中心效果图

遗留问题

当主机房（主集群）发生故障之后

如果单纯的为了支持读，那么不需要接触主从复制关系，只需要暂停复制进行和切换读取的地址即可。当主集群恢复之后，重新开启复制进程和读取地址切回朱地址即可。
如果同时需要支持读与写操作。那么需要解除主从复制关系，将备用集群的从索引变为常规索引，这样才能支持读写操作。当主集群恢复之后，如果将故障期间的数据回写到主集群，并重新建立主从复制关系就需要进行特殊方案处理了。