跨集群复制

通过跨集群复制，您可以在集群之间复制索引以：

跨集群复制使用主动-被动模型。您向一个领导者索引进行索引，数据会被复制到一个或多个只读的追随者索引。在您可以将一个追随者索引添加到集群之前，您必须配置包含领导者索引的远程集群。

当主索引接收到写入操作时，从属索引会从远程集群的主索引中拉取变更。您可以手动创建从属索引，或者配置自动跟随模式以自动为新的时间序列索引创建从属索引。

您可以在单向或双向设置中配置跨集群复制集群：

在单向配置中，包含从属索引的集群必须运行相同或更新版本的Elasticsearch作为远程集群。如果更新，版本也必须如以下矩阵所述兼容。

使用跨集群复制在 Elastic Stack 中构建多个多集群架构：

观看 跨集群复制网络研讨会以了解更多以下用例。 然后，在您的本地机器上设置跨集群复制并完成研讨会中的演示。

灾难恢复为您的关键任务应用程序提供了对数据中心或区域中断的容忍能力。这是跨集群复制最常见的部署场景。您可以在不同的架构中配置集群，以支持灾难恢复和高可用性：

在这种配置中，数据从生产数据中心复制到灾难恢复数据中心。由于从属索引复制了主索引，因此如果生产数据中心不可用，您的应用程序可以使用灾难恢复数据中心。

您可以将数据从一个数据中心复制到多个数据中心。这种配置既提供了灾难恢复，也提供了高可用性，确保在主数据中心宕机或不可用时，数据会在两个数据中心之间复制。

在下图中，数据中心A的数据被复制到数据中心B和数据中心C，这两个数据中心都有数据中心A的领导者索引的只读副本。

您可以在多个数据中心之间复制数据，形成一个复制链。在下图中，数据中心A包含领导者索引。数据中心B从数据中心A复制数据，而数据中心C从数据中心B的跟随者索引复制数据。这些数据中心之间的连接形成了一个链式复制模式。

在双向复制设置中，所有集群都可以访问查看所有数据，并且所有集群都有一个索引可以写入，而无需手动实现故障转移。应用程序可以写入每个数据中心内的本地索引，并跨多个索引读取以获取所有信息的全球视图。

此配置在集群或数据中心不可用时不需要手动干预。在下图中，如果数据中心A不可用，您可以继续使用数据中心B而无需手动故障转移。当数据中心A重新上线时，集群之间的复制将恢复。

此配置对于仅索引的工作负载特别有用，其中不会对文档值进行更新。在此配置中，由Elasticsearch索引的文档是不可变的。客户端位于每个数据中心内，与Elasticsearch集群并置，并且不与不同数据中心的集群通信。

将数据更接近您的用户或应用程序服务器可以减少延迟和响应时间。这种方法在Elasticsearch中复制数据时也同样适用。例如，您可以将产品目录或参考数据集复制到全球20个或更多的数据中心，以最小化数据与应用程序服务器之间的距离。

在下图中，数据从一个数据中心复制到三个额外的数据中心，每个数据中心位于各自的区域。中央数据中心包含领导者索引，而额外的数据中心包含跟随者索引，这些索引在该特定区域复制数据。这种配置将数据更接近访问它的应用程序。

使用集中式报告集群在跨大型网络查询效率低下时非常有用。在这种配置中，您将数据从许多较小的集群复制到集中式报告集群。

例如，一家大型全球银行可能在全球拥有100个Elasticsearch集群，这些集群分布在不同地区的每个银行分行。通过使用跨集群复制，银行可以将所有100个银行的事件复制到一个中央集群，以便在本地分析和汇总事件以进行报告。银行可以使用跨集群复制来复制特定的索引，而不是维护一个镜像集群。

在下图中，来自不同区域三个数据中心的数据被复制到一个集中的报告集群。这种配置使您能够将数据从区域中心复制到中央集群，您可以在本地运行所有报告。

尽管您在索引级别设置了跨集群复制，但Elasticsearch在分片级别实现复制。当创建一个跟随者索引时，该索引中的每个分片都会从其对应的领导者索引中的分片拉取变更，这意味着跟随者索引具有与领导者索引相同的分片数量。领导者上的所有操作都会被跟随者复制，例如创建、更新或删除文档的操作。这些请求可以从领导者分片的任何副本（主分片或副本分片）提供服务。

当一个跟随者分片发送读取请求时，领导者分片会响应任何新的操作，这些操作受限于您在配置跟随者索引时建立的读取参数。如果没有新的操作可用，领导者分片会等待配置的超时时间以获取新的操作。如果超时时间已过，领导者分片会响应跟随者分片，告知没有新的操作。跟随者分片更新分片统计信息，并立即向领导者分片发送另一个读取请求。这种通信模型确保远程集群和本地集群之间的网络连接持续使用，避免被外部源（如防火墙）强制终止。

如果读取请求失败，会检查失败的原因。如果失败的原因被认为是可恢复的（例如网络故障），跟随者分片会进入重试循环。否则，跟随者分片会暂停 直到您恢复它。

您无法手动修改从属索引的映射或别名。要进行更改，您必须更新主索引。由于它们是只读的，从属索引在所有配置中都会拒绝写入。

例如，您在数据中心A中索引了一个名为doc_1的文档，该文档会复制到数据中心B。如果客户端连接到数据中心B并尝试更新doc_1，请求将失败。要更新doc_1，客户端必须连接到数据中心A并在主索引中更新文档。

当一个跟随分片从主分片接收操作时，它会将这些操作放入写缓冲区。跟随分片使用写缓冲区中的操作提交批量写请求。如果写缓冲区超过其配置的限制，则不会发送额外的读请求。此配置对读请求提供了反压，允许跟随分片在写缓冲区不再满时恢复发送读请求。

要管理从主索引复制的操作，您可以在创建追随者索引时配置设置。

对主索引的索引映射所做的更改会尽快复制到从属索引。此行为对于索引设置也是如此，但有一些设置是主索引本地的，不会被从属索引复制。例如，更改主索引上的副本数量不会被从属索引复制，因此可能无法检索到该设置。

如果你将一个非动态设置更改应用于领导者索引，而该更改是追随者索引所需的，追随者索引会关闭自身，应用设置更新，然后重新打开自身。在此周期内，追随者索引无法进行读取操作，也不能复制写入操作。

当您创建一个跟随者索引时，在它完全初始化之前，您无法使用它。远程恢复过程通过从领导者集群中的主分片复制数据，在跟随者节点上构建一个新的分片副本。

Elasticsearch 使用此远程恢复过程，通过从主索引中获取数据来引导从属索引。此过程为从属索引提供主索引当前状态的副本，即使由于 Lucene 段合并导致主索引上没有完整的更改历史记录。

远程恢复是一个网络密集型过程，它将所有Lucene段文件从主集群传输到从集群。从集群请求在主集群的主分片上启动恢复会话。然后，从集群同时从主集群请求文件块。默认情况下，该过程同时请求五个1MB的文件块。此默认行为旨在支持主集群和从集群之间具有高网络延迟的情况。

在包含从属索引的集群上使用恢复 API获取有关正在进行远程恢复的信息。因为 Elasticsearch 使用快照和还原基础设施实现远程恢复，所以在恢复 API 中运行的远程恢复被标记为类型 snapshot。

跨集群复制通过重放对主索引分片执行的单个写操作的历史记录来工作。Elasticsearch需要在主分片上保留这些操作的历史记录，以便它们可以被跟随者分片任务拉取。用于保留这些操作的底层机制是软删除。

软删除发生在现有文档被删除或更新时。通过保留这些软删除至可配置的限制，操作的历史记录可以在主分片上保留，并提供给跟随者分片任务，因为它重放操作的历史记录。

设置 index.soft_deletes.retention_lease.period 定义了在分片历史保留租约被视为过期之前保留它的最长时间。此设置决定了包含您的跟随者索引的集群可以离线的时间，默认为12小时。如果一个分片副本在其保留租约过期后恢复，但缺失的操作仍然在领导者索引上可用，那么Elasticsearch将建立一个新的租约并复制缺失的操作。然而，Elasticsearch不保证保留未租约的操作，因此也有可能一些缺失的操作已被领导者丢弃，现在完全不可用。如果发生这种情况，跟随者无法自动恢复，因此您必须重新创建它。

对于您希望用作领导者索引的索引，必须启用软删除。在 Elasticsearch 7.0.0 或更高版本上创建的新索引默认启用了软删除。

以下各节提供了有关如何配置和使用跨集群复制的更多信息：

跨集群复制旨在仅复制用户生成的索引，并且当前不复制以下任何内容：

如果您想复制这些数据中的任何部分，您必须手动将其复制到远程集群。

教程：设置跨集群复制

edit

使用本指南在两个数据中心的集群之间设置跨集群复制（CCR）。在数据中心之间复制数据具有以下几个优点：

• 将数据更接近您的用户或应用程序服务器，以减少延迟和响应时间
• 为您的关键任务应用程序提供容忍数据中心或区域中断的能力

在本指南中，您将学习如何：

• 配置一个带有领导者索引的远程集群
• 在本地集群上创建一个跟随者索引
• 创建一个自动跟随模式，以自动跟随在远程集群中定期创建的时间序列索引

您可以手动创建跟随索引以在远程集群上复制特定索引，或配置自动跟随模式以复制滚动时间序列索引。

如果您想在云中的集群之间复制数据，您可以 在Elasticsearch服务上配置远程集群。然后，您 可以 跨集群搜索 并设置跨集群复制。

先决条件

edit

要完成本教程，您需要：

• 本地集群上的manage集群权限。
• 两个集群上的许可证，包括跨集群复制功能。激活免费30天试用。
• 远程集群上的一个索引，包含您要复制的数据。本教程使用示例电子商务订单数据集。 加载示例数据。
• 在本地集群中，所有具有master 节点角色的节点还必须具有remote_cluster_client角色。本地集群还必须至少有一个同时具有数据角色和remote_cluster_client角色的节点。协调复制任务的个别任务根据本地集群中具有remote_cluster_client角色的数据节点数量进行扩展。

连接到远程集群

edit

要将远程集群（集群A）上的索引复制到本地集群（集群B），您需要将集群A配置为集群B的远程集群。

要在 Kibana 的 Stack Management 中配置远程集群：

1. 根据需要设置一个安全连接。
2. 从侧边导航中选择远程集群。
3. 指定Elasticsearch端点URL，或远程集群的IP地址或主机名（ClusterA），后跟传输端口（默认为9300）。例如，cluster.es.eastus2.staging.azure.foundit.no:9400或192.168.1.1:9300。

API示例

您还可以使用集群更新设置 API来添加远程集群：

PUT /_cluster/settings
{
  "persistent" : {
    "cluster" : {
      "remote" : {
        "leader" : {
          "seeds" : [
            "127.0.0.1:9300" 
          ]
        }
      }
    }
  }
}

指定远程集群中种子节点的主机名和传输端口。

您可以验证本地集群是否已成功连接到远程集群。

GET /_remote/info

API 响应表明本地集群已通过集群别名 leader 连接到远程集群。

{
  "leader" : {
    "seeds" : [
      "127.0.0.1:9300"
    ],
    "connected" : true,
    "num_nodes_connected" : 1, 
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s",
    "skip_unavailable" : true,
    "mode" : "sniff"
  }
}

本地集群连接到的远程集群中的节点数量。

配置跨集群复制的权限

edit

跨集群复制用户在远程集群和本地集群上需要不同的集群和索引权限。使用以下请求在本地和远程集群上创建单独的角色，然后创建具有所需角色的用户。

远程集群

edit

在包含主索引的远程集群上，跨集群复制角色需要read_ccr集群权限，以及主索引上的monitor和read权限。

如果请求使用API密钥进行身份验证，则API密钥需要在本地集群上具有上述权限，而不是远程集群。

如果请求是代表其他用户发出的，那么进行身份验证的用户必须在远程集群上具有run_as权限。

以下请求在远程集群上创建一个remote-replication角色：

POST /_security/role/remote-replication
{
  "cluster": [
    "read_ccr"
  ],
  "indices": [
    {
      "names": [
        "leader-index-name"
      ],
      "privileges": [
        "monitor",
        "read"
      ]
    }
  ]
}

本地集群

edit

在包含从属索引的本地集群上，remote-replication角色需要manage_ccr集群权限，以及在从属索引上的monitor、read、write和manage_follow_index权限。

以下请求在本地集群上创建一个远程复制角色：

POST /_security/role/remote-replication
{
  "cluster": [
    "manage_ccr"
  ],
  "indices": [
    {
      "names": [
        "follower-index-name"
      ],
      "privileges": [
        "monitor",
        "read",
        "write",
        "manage_follow_index"
      ]
    }
  ]
}

在每个集群上创建remote-replication角色后，使用创建或更新用户API在本地集群上创建一个用户并分配remote-replication角色。例如，以下请求将remote-replication角色分配给名为cross-cluster-user的用户：

POST /_security/user/cross-cluster-user
{
  "password" : "l0ng-r4nd0m-p@ssw0rd",
  "roles" : [ "remote-replication" ]
}

您只需要在本地集群上创建此用户。

创建一个跟随者索引以复制特定索引

edit

当您创建一个跟随者索引时，您需要在本地集群中引用远程集群和远程集群中的领导者索引。

要在 Kibana 的 Stack Management 中创建一个 follower 索引：

1. 在侧边导航中选择跨集群复制，然后选择跟随索引标签。
2. 选择包含您要复制的领导者索引的集群（ClusterA）。
3. 输入领导者索引的名称，如果您正在按照教程操作，则为kibana_sample_data_ecommerce。
4. 为您的新跟随索引输入一个名称，例如follower-kibana-sample-data。

Elasticsearch 使用 远程恢复 过程初始化跟随者，该过程将现有的 Lucene 段文件从领导者索引导入到跟随者索引。索引状态变为 已暂停。当远程恢复过程完成后，索引跟随开始，状态变为 活动。

当您将文档索引到主索引时，Elasticsearch 会在从属索引中复制这些文档。

API示例

您还可以使用创建跟随者 API来创建跟随者索引。当您创建一个跟随者索引时，您必须引用远程集群和您在远程集群中创建的领导者索引。

在发起跟随者请求时，响应会在远程恢复过程完成之前返回。要等待该过程完成，请在请求中添加wait_for_active_shards参数。

PUT /server-metrics-follower/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster" : "leader",
  "leader_index" : "server-metrics"
}

使用 获取跟随者状态 API 来检查 复制的状态。

创建自动跟随模式以复制时间序列索引

edit

您可以使用自动跟随模式来自动为滚动时间序列索引创建新的跟随者。每当远程集群上新索引的名称与自动跟随模式匹配时，本地集群中就会添加一个相应的跟随者索引。请注意，只有在创建自动跟随模式后在远程集群上创建的索引才会被自动跟随：即使现有索引与模式匹配，远程集群上的现有索引也会被忽略。

自动跟随模式指定了您想要从中复制的远程集群，以及一个或多个指定您想要复制的滚动时间序列索引的索引模式。

要在 Kibana 的堆栈管理中创建自动跟随模式：

1. 在侧边导航中选择跨集群复制，然后选择自动跟随模式标签。
2. 为自动跟随模式输入一个名称，例如beats。
3. 选择包含您要复制的索引的远程集群，在示例场景中是集群A。
4. 输入一个或多个索引模式，这些模式标识您要从远程集群复制的索引。例如，输入metricbeat-* packetbeat-*以自动为Metricbeat和Packetbeat索引创建跟随者。
5. 输入follower-作为跟随者索引名称的前缀，以便您可以更容易地识别复制的索引。

当远程创建了与这些模式匹配的新索引时，Elasticsearch 会自动将它们复制到本地的跟随者索引中。

API示例

使用创建自动跟随模式 API来配置自动跟随模式。

PUT /_ccr/auto_follow/beats
{
  "remote_cluster" : "leader",
  "leader_index_patterns" :
  [
    "metricbeat-*", 
    "packetbeat-*" 
  ],
  "follow_index_pattern" : "{{leader_index}}-copy" 
}

	自动跟随新的 Metricbeat 索引。
	自动跟随新的Packetbeat索引。
	追随者索引的名称是通过在领导者索引的名称后添加后缀 -copy 来派生的。

POST /follower_index/_ccr/pause_follow

POST /follower_index/_close

PUT /follower_index/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster" : "remote_cluster",
  "leader_index" : "leader_index"
}

Cluster A
        ^--Cluster B
                   ^--Cluster C

教程：基于单向跨集群复制的灾难恢复

edit

学习如何在基于单向跨集群复制（uni-directional cross-cluster replication）的两个集群之间进行故障转移和故障恢复。您还可以访问双向灾难恢复，以设置自动故障转移和故障恢复的数据流，无需人工干预。

• 设置从clusterA到clusterB的单向跨集群复制。
• 故障转移 - 如果clusterA离线，clusterB需要将追随者索引“提升”为常规索引以允许写操作。所有摄取都需要重定向到clusterB，这由客户端（Logstash、Beats、Elastic Agents等）控制。
• 故障恢复 - 当clusterA重新上线时，它将承担追随者的角色，并从clusterB复制领导者索引。

跨集群复制仅提供复制用户生成索引的功能。 跨集群复制并非设计用于复制系统生成的索引或快照设置，并且无法在集群之间复制ILM或SLM策略。 了解更多关于跨集群复制的限制。

先决条件

edit

在完成本教程之前， 设置跨集群复制以连接两个 集群并配置一个跟随索引。

在本教程中，kibana_sample_data_ecommerce 从 clusterA 复制到 clusterB。

### On clusterB ###
PUT _cluster/settings
{
  "persistent": {
    "cluster": {
      "remote": {
        "clusterA": {
          "mode": "proxy",
          "skip_unavailable": "true",
          "server_name": "clustera.es.region-a.gcp.elastic-cloud.com",
          "proxy_socket_connections": "18",
          "proxy_address": "clustera.es.region-a.gcp.elastic-cloud.com:9400"
        }
      }
    }
  }
}

### On clusterB ###
PUT /kibana_sample_data_ecommerce2/_ccr/follow?wait_for_active_shards=1
{
  "remote_cluster": "clusterA",
  "leader_index": "kibana_sample_data_ecommerce"
}

写入操作（如摄取或更新）应仅在主索引上进行。从属索引是只读的，并将拒绝任何写入操作。

当 clusterA 宕机时的故障转移

edit

1. 将 clusterB 中的追随者索引提升为常规索引，以便它们接受写入。这可以通过以下方式实现：

   • 首先，暂停追随者索引的索引跟随。
   • 接下来，关闭追随者索引。
   • 取消跟随领导者索引。
   • 最后，打开追随者索引（此时它是一个常规索引）。
   ### 在 clusterB 上 ###
   POST /kibana_sample_data_ecommerce2/_ccr/pause_follow
   POST /kibana_sample_data_ecommerce2/_close
   POST /kibana_sample_data_ecommerce2/_ccr/unfollow
   POST /kibana_sample_data_ecommerce2/_open

2. 在客户端（Logstash、Beats、Elastic Agent），手动重新启用kibana_sample_data_ecommerce2的摄取，并将流量重定向到clusterB。在此期间，您还应将所有搜索流量重定向到clusterB集群。您可以通过将文档摄取到此索引来模拟此操作。您应该注意到此索引现在是可写的。

   ### 在 clusterB 上 ###
   POST kibana_sample_data_ecommerce2/_doc/
   {
     "user": "kimchy"
   }

当clusterA恢复时进行故障恢复

edit

当clusterA恢复时，clusterB成为新的领导者，clusterA成为追随者。

1. 在 clusterA 上设置远程集群 clusterB。

   ### 在 clusterA 上 ###
   PUT _cluster/settings
   {
     "persistent": {
       "cluster": {
         "remote": {
           "clusterB": {
             "mode": "proxy",
             "skip_unavailable": "true",
             "server_name": "clusterb.es.region-b.gcp.elastic-cloud.com",
             "proxy_socket_connections": "18",
             "proxy_address": "clusterb.es.region-b.gcp.elastic-cloud.com:9400"
           }
         }
       }
     }
   }

2. 在将任何索引转换为从节点之前，需要丢弃现有数据。在删除clusterA上的任何索引之前，确保clusterB上具有最新的数据。

   ### 在 clusterA 上 ###
   DELETE kibana_sample_data_ecommerce

3. 在 clusterA 上创建一个 follower 索引，现在跟随 clusterB 中的 leader 索引。

   ### 在 clusterA 上 ###
   PUT /kibana_sample_data_ecommerce/_ccr/follow?wait_for_active_shards=1
   {
     "remote_cluster": "clusterB",
     "leader_index": "kibana_sample_data_ecommerce2"
   }

4. 从集群上的索引现在包含了更新的文档。

   ### 在 clusterA 上 ###
   GET kibana_sample_data_ecommerce/_search?q=kimchy

   如果在软删除被合并之前无法复制到从节点，由于主节点上的历史记录不完整，以下过程将会失败，详情请参见index.soft_deletes.retention_lease.period。

教程：基于双向跨集群复制的灾难恢复

edit

了解如何基于双向跨集群复制在两个集群之间设置灾难恢复。以下教程适用于支持通过查询更新和通过查询删除的数据流。您只能在主索引上执行这些操作。

本教程使用 Logstash 作为数据摄取的来源。它利用了 Logstash 的一个特性，即 Logstash 输出到 Elasticsearch 可以在指定的主机数组之间进行负载均衡。目前，Beats 和 Elastic Agents 不支持多个输出。在本教程中，也可以设置一个代理（负载均衡器）来重定向流量，而不使用 Logstash。

• Setting up a remote cluster on clusterA and clusterB.
• Setting up bi-directional cross-cluster replication with exclusion patterns.
• Setting up Logstash with multiple hosts to allow automatic load balancing and switching during disasters.

初始设置

edit

1. 在两个集群上设置远程集群。

   ### On cluster A ###
   PUT _cluster/settings
   {
     "persistent": {
       "cluster": {
         "remote": {
           "clusterB": {
             "mode": "proxy",
             "skip_unavailable": true,
             "server_name": "clusterb.es.region-b.gcp.elastic-cloud.com",
             "proxy_socket_connections": 18,
             "proxy_address": "clusterb.es.region-b.gcp.elastic-cloud.com:9400"
           }
         }
       }
     }
   }
   ### On cluster B ###
   PUT _cluster/settings
   {
     "persistent": {
       "cluster": {
         "remote": {
           "clusterA": {
             "mode": "proxy",
             "skip_unavailable": true,
             "server_name": "clustera.es.region-a.gcp.elastic-cloud.com",
             "proxy_socket_connections": 18,
             "proxy_address": "clustera.es.region-a.gcp.elastic-cloud.com:9400"
           }
         }
       }
     }
   }

2. 设置双向跨集群复制。

   ### On cluster A ###
   PUT /_ccr/auto_follow/logs-generic-default
   {
     "remote_cluster": "clusterB",
     "leader_index_patterns": [
       ".ds-logs-generic-default-20*"
     ],
     "leader_index_exclusion_patterns":"*-replicated_from_clustera",
     "follow_index_pattern": "{{leader_index}}-replicated_from_clusterb"
   }
   
   ### On cluster B ###
   PUT /_ccr/auto_follow/logs-generic-default
   {
     "remote_cluster": "clusterA",
     "leader_index_patterns": [
       ".ds-logs-generic-default-20*"
     ],
     "leader_index_exclusion_patterns":"*-replicated_from_clusterb",
     "follow_index_pattern": "{{leader_index}}-replicated_from_clustera"
   }

   集群上现有的数据不会被_ccr/auto_follow复制，即使模式可能匹配。此功能只会复制新创建的备份索引（作为数据流的一部分）。

   使用 leader_index_exclusion_patterns 来避免递归。

   follow_index_pattern 仅允许小写字符。

   由于Kibana UI中缺少排除模式，此步骤无法通过Kibana UI执行。请在此步骤中使用API。

3. 设置 Logstash 配置文件。

   此示例使用输入生成器来演示集群中的文档数量。重新配置此部分以适应您自己的用例。

   ### On Logstash server ###
   ### This is a logstash config file ###
   input {
     generator{
       message => 'Hello World'
       count => 100
     }
   }
   output {
     elasticsearch {
       hosts => ["https://clustera.es.region-a.gcp.elastic-cloud.com:9243","https://clusterb.es.region-b.gcp.elastic-cloud.com:9243"]
       user => "logstash-user"
       password => "same_password_for_both_clusters"
     }
   }

   关键点是当集群A宕机时，所有流量将自动重定向到集群B。一旦集群A恢复，流量将自动重定向回集群A。这是通过选项hosts实现的，其中在数组[clusterA, clusterB]中指定了多个ES集群端点。

   在两个集群上为同一用户设置相同的密码以使用此负载均衡功能。

4. 使用之前的配置文件启动 Logstash。

   ### On Logstash server ###
   bin/logstash -f multiple_hosts.conf

5. 观察数据流中的文档数量。

   该设置在每个集群上创建一个名为 logs-generic-default 的数据流。当两个集群都启动时，Logstash 会将 50% 的文档写入 cluster A，并将 50% 的文档写入 cluster B。

   双向跨集群复制将在每个集群上创建一个带有-replication_from_cluster{a|b}后缀的额外数据流。在此步骤结束时：

   • 集群A上的数据流包含：

     • 50 documents in logs-generic-default-replicated_from_clusterb
     • 50 documents in logs-generic-default

   • 集群B上的数据流包含：

     • 50 documents in logs-generic-default-replicated_from_clustera
     • 50 documents in logs-generic-default

6. 查询应设置为在两个数据流中进行搜索。 在任一集群上对logs*进行的查询总共返回100条命中记录。

   GET logs*/_search?size=0

当clusterA 宕机时的故障转移

edit

1. 你可以通过关闭其中一个集群来模拟这种情况。在本教程中，我们关闭cluster A。

2. 使用相同的配置文件启动Logstash。（在实际使用场景中，Logstash会持续进行数据摄入，因此这一步不是必需的。）

   ### 在Logstash服务器上 ###
   bin/logstash -f multiple_hosts.conf

3. 观察所有 Logstash 流量将自动重定向到 cluster B。

   在此期间，您还应将所有搜索流量重定向到clusterB集群。

4. 集群 B 上的两个数据流现在包含不同数量的文档。

   • 集群A上的数据流（已关闭）

     • 50 documents in logs-generic-default-replicated_from_clusterb
     • 50 documents in logs-generic-default

   • 数据流在集群 B 上（已启动）

     • 50 documents in logs-generic-default-replicated_from_clustera
     • 150 documents in logs-generic-default

当clusterA恢复时进行故障恢复

edit

1. 你可以通过重新开启集群 A来模拟这种情况。

2. 在集群 A停机期间摄取到集群 B的数据将自动复制。

   • 集群A上的数据流

     • 150 documents in logs-generic-default-replicated_from_clusterb
     • 50 documents in logs-generic-default

   • 集群B上的数据流

     • 50 documents in logs-generic-default-replicated_from_clustera
     • 150 documents in logs-generic-default
3. 如果你此时运行了Logstash，你还会观察到流量被发送到两个集群。

通过查询执行更新或删除

edit

可以更新或删除文档，但只能在主索引上执行这些操作。

1. 首先确定哪个后备索引包含您要更新的文档。

   ### On either of the cluster ###
   GET logs-generic-default*/_search?filter_path=hits.hits._index
   {
   "query": {
       "match": {
         "event.sequence": "97"
       }
     }
   }

   • 如果返回的结果是 "_index": ".ds-logs-generic-default-replicated_from_clustera--*"，那么您需要在 cluster A 上继续下一步。
   • 如果返回的结果是 "_index": ".ds-logs-generic-default-replicated_from_clusterb--*"，那么您需要在 cluster B 上继续下一步。
   • 如果返回的结果是 "_index": ".ds-logs-generic-default--*"，那么您需要在执行搜索查询的同一集群上继续下一步。

2. 执行按查询更新（或删除）：

   ### On the cluster identified from the previous step ###
   POST logs-generic-default/_update_by_query
   {
     "query": {
       "match": {
         "event.sequence": "97"
       }
     },
     "script": {
       "source": "ctx._source.event.original = params.new_event",
       "lang": "painless",
       "params": {
         "new_event": "FOOBAR"
       }
     }
   }

   如果在软删除被合并之前无法复制到从节点，由于主节点上的历史记录不完整，以下过程将会失败，详情请参见index.soft_deletes.retention_lease.period。