如果我对 Amazon Elasticsearch Service 集群进行配置更改,会发生什么情况?

上次更新日期:2021 年 4 月 1 日

我正在尽力缩短配置更改期间的停机时间。如果我对 Amazon Elasticsearch Service (Amazon ES) 集群进行配置更改,会发生什么情况?

解决方法

当您更改 Amazon ES 集群配置时,可触发蓝/绿部署。在蓝/绿部署期间,如果创建了新的 Amazon ES 域,集群状态会更改为“正在处理”。创建新域时,会发生以下情况:

  • 节点总数增加一倍。或者,节点总数等于新旧 Amazon ES 域中的节点数量之和。
  • 在旧的 Amazon ES 域节点终止之前,节点数量会翻倍。
  • 如果一项分区分配操作正在最终处理,则集群状态将返回“活动”。

注意:在蓝/绿部署期间,您可能会注意到一定的延迟。为避免任何延迟问题,最佳实践是在集群运行状况良好且网络流量较低时运行蓝/绿部署。

配置更改持续时间

根据集群大小、工作负载、分区大小和分区数量,您的配置更改实际需要的时间可能更长。使用 cat recovery 命令监控您的分区重新定位的状态。

要查看哪些分区仍在重新定位,请使用以下命令语法:

Curl  -X GET "cluster_endpoint/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | grep -v 100\.0\%

要按字节百分比列出分区重新定位,请使用以下命令语法:

Curl -X GET "https://<end_point>/_cat/recovery?v=true&pretty" | awk '/peer/ {print $1" "$2" "$3" "$4" "$18}' | tr -d "%" | sort -k 5 -n

注意:要按字节百分比(位于第五列中)对数据进行排序,必须为 -k 指定“5”。

如果您注意到分区重新定位的进度极慢,那么可能表示您的集群陷入了卡滞。

蓝/绿部署过程陷入卡滞的原因

由于以下原因,您的蓝/绿部署过程可能会陷入卡滞:

  • 在执行配置更改之前,集群运行状况不佳。
  • JVM 内存压力始终居高不下。请尽力将 JVM 内存压力保持在 75% 以下,以避免内存不足 (OOM) 问题。
  • CPU 利用率始终居高不下。请尽力将 CPU 利用率保持在 80% 以下。
  • Elasticsearch 集群上的分区太多或分区大小不正确。最佳实践是将您的分区数量控制在 10 GiB 到 50 GiB 之间。有关索引策略的更多信息,请参阅选择分区数量
  • 配置设置无效,或者同时执行的配置更改太多。务必验证您的配置设置,并等待首次配置操作完成之后再发送配置更改。
  • 磁盘空间或容量不足以支持重新定位过程或者请求的实例类型。
  • 对于 Virtual Private Cloud (VPC) 内的集群,所请求的子网可能没有 IP 可用。
  • 使用适合实例类型的卷大小。您的卷大小必须在限制范围内。
  • 使用索引设置,如“index.routing.allocation.require._name”或“NODE_NAME”或“index.blocks.write": true”。这些设置表示写入数据块。在继续操作之前,请务必从索引设置中删除这些设置。

有关更多信息,请参阅我的 Amazon Elasticsearch Service (Amazon ES) 域为什么卡在“正在处理”状态?


这篇文章对您有帮助吗?


您是否需要账单或技术支持?