Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

Data Grid Cross-Site Replication

Red Hat Data Grid 8.5

在 Data Grid 集群间备份数据

Red Hat Customer Content Services

摘要

Data Grid 可以形成全局集群，以便在地理位置复制数据。本指南介绍了如何为缓存配置备份位置并执行跨站点操作。

Red Hat Data Grid
复制链接

Data Grid 是一个高性能分布式内存数据存储。

无架构数据结构
将不同对象存储为键值对的灵活性。
基于网格的数据存储
旨在在集群中分发和复制数据。
弹性扩展
动态调整节点数量，以便在不中断服务的情况下满足需求。
数据互操作性
从不同端点在网格中存储、检索和查询数据。

Data Grid 文档
复制链接

红帽客户门户网站中提供了 Data Grid 的文档。

Data Grid 下载
复制链接

访问红帽客户门户上的 Data Grid 软件下载。

注意

您必须有一个红帽帐户才能访问和下载数据中心软件。

使开源包含更多
复制链接

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始：master、slave、黑名单和白名单。由于此项工作十分艰巨，这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息。

第 1 章 跨站点复制
复制链接

本节介绍数据网格跨站点复制功能，包括用于远程缓存的中继节点、状态传输和客户端连接的详细信息。

1.1. 跨站点复制
复制链接

Data Grid 可以在地理上分散的数据中心和跨不同云提供商运行的集群间备份数据。跨站点复制通过全局集群视图和：

  • 保证服务在停机或灾难时的连续性。
  • 为客户端应用程序提供在全局分布式缓存中对数据的单点访问。

图 1.1. 跨站点复制

使用数据网格部署进行跨站点复制。

1.2. 转发节点
复制链接

中继节点是 Data Grid 集群中的节点，负责从备份位置发送和接收请求。

如果节点不是中继节点，则必须将备份请求转发到本地中继节点。只有中继节点才能向备份位置发送请求。

为获得最佳性能，您应该将所有节点配置为中继节点。这会提高备份请求的速度，因为集群中的每个节点可以直接备份到远程站点，而无需将备份请求转发到本地中继节点。

注意

本文档的图表演示了 Data Grid 集群和一个中继节点，因为这是 JGroups RELAY2 协议的默认设置。同样，一个中继节点更容易地说明，因为集群中的每个中继节点都与远程集群中的每个转发节点通信。

注意

JGroups 配置将节点指定为 "site master" 节点。Data Grid 使用中继节点，因为它更为描述性，并为我们的用户提供了更直观的选择。

1.3. Data Grid 缓存备份
复制链接

Data Grid 缓存包括一个 备份 配置，可让您将远程站点命名为备份位置。

例如，下图显示了三个缓存，"customers"、"eu-orders"和"us-orders"：

  • 在 LON 中，"customers"名称 NYC 作为备份位置。
  • 在 NYC 中，"customers"名称 LON 作为备份位置。
  • "eu-orders"和"us-orders"没有备份，并且对对应的集群是本地的。

1.4. 备份策略
复制链接

Data Grid 在集群间复制数据，同时进行写入缓存。例如，如果客户端将 "k1" 写入 LON，则数据网格同时将"k1"备份到 NYC。

要将数据备份到不同的集群，数据网格可以使用同步或异步策略。

同步策略

当 Data Grid 将数据复制到备份位置时，它会写入本地集群中的缓存以及远程集群中的缓存。借助同步策略，Data Grid 会在返回前等待两个写入操作完成。

如果备份操作失败，您可以控制 Data Grid 如何处理对本地集群中的缓存的写入。Data Grid 可以执行以下操作：

  • 忽略失败的备份，静默继续写入本地集群。
  • 记录警告消息或抛出异常并继续写入本地集群。
  • 使用自定义逻辑处理失败的备份操作。

同步备份还支持两阶段提交，带有参与最佳事务的缓存。备份的第一个阶段会获得锁定。第二个阶段将提交修改。

重要

具有跨站点复制的两个阶段提交对性能有显著影响，因为它需要跨网络有两个往返。

异步策略

当 Data Grid 将数据复制到备份位置时，在写入本地缓存前，它不会等待操作完成。

异步备份操作和写入本地缓存相互独立。如果备份操作失败，对本地缓存的写入操作将继续，且不会发生异常。当发生这种情况时，Data Grid 也重试写操作，直到远程集群与跨站点视图断开连接为止。

同步和异步备份

同步备份提供了跨站点的数据一致性的最强保证。如果 strategy=sync，当 cache.put （） 调用返回时，您知道值是本地缓存和备份位置的最新状态。

这种一致性的权衡是性能。与异步备份相比，同步备份具有更大的延迟。

另一方面，异步备份不会给客户端请求添加延迟，使其不会影响性能。但是，如果 strategy=async，当 cache.put （） 调用返回时，您不能确保备份位置中的值与本地缓存中的值相同。

1.5. 备份位置的自动离线参数
复制链接

使用过量 RAM 和 CPU 在集群间复制数据的操作是资源密集型。为了避免资源 Data Grid 在特定时间段内停止接受请求时，使其离线进行备份位置。

Data Grid 根据失败的后续请求数量和第一次故障起的时间间隔，使远程站点离线。当目标集群没有跨站点视图(JGroups 网桥)中的任何节点，或者目标集群确认请求前超时过期时，请求会失败。

备份超时

备份配置包括在集群之间复制数据的操作的超时值。如果操作在超时过期前没有完成，则数据网格会将其记录为失败。

在以下示例中，将数据复制到 NYC 的操作会在 10 秒后没有完成时记录失败：

XML

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000" />
  </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"
Copy to Clipboard Toggle word wrap

失败数

您可以指定备份位置离线前可能出现的 连续 失败数量。

在以下示例中，如果集群尝试将数据复制到 NYC，连续五个操作失败，NYC 会自动离线：

XML

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000">
      <take-offline after-failures="5"/>
    </backup>
  </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000",
          "take-offline" : {
            "after-failures" : "5"
          }
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"
        takeOffline:
          afterFailures: "5"
Copy to Clipboard Toggle word wrap

等待时间

您还可以指定在备份操作失败时进行站点离线前等待的时间。如果在等待时间超时前备份请求成功，则数据网格不会使站点离线。

一个或两分钟是让备份位置离线前等待的时间。如果等待时间太短，则备份位置会过早离线。然后，您需要使集群重新上线并执行状态传输操作，以确保数据在集群之间进行同步。

失败数的负或零值相当于 1 的值。Data Grid 仅使用最短时间在故障后等待备份位置离线，例如： 

<take-offline after-failures="-1"
              min-wait="10000"/>
Copy to Clipboard Toggle word wrap

在以下示例中，如果集群尝试将数据复制到 NYC，且连续五个失败，在第一个失败操作后有 15 秒，NYC 会自动进行离线：

XML

<distributed-cache>
  <backups>
    <backup site="NYC"
            strategy="ASYNC"
            timeout="10000">
      <take-offline after-failures="5" min-wait="15000"/>
    </backup>
  </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "NYC" : {
        "backup" : {
          "strategy" : "ASYNC",
          "timeout" : "10000",
          "take-offline" : {
            "after-failures" : "5",
            "min-wait" : "15000"
          }
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
        timeout: "10000"
        takeOffline:
          afterFailures: "5"
          minWait: "15000"
Copy to Clipboard Toggle word wrap

1.6. state transfer
复制链接

State transfer 是一个管理操作，可在站点之间同步数据。

例如，LON 脱机，NYC 开始处理客户端请求。当您重新上线时， LON 中的 Data Grid 集群与 NYC 中的集群没有相同的数据。

为确保数据在 LON 和 NYC 之间保持一致，您可以将状态从 NYC 推送到 LON。

  • state transfer 是双向的。例如，您可以将状态从 NYC 推送到 LON 或从 LON 推送到 NYC。
  • 将状态推送到离线站点会使它们重新上线。

  • 状态传输只覆盖两个站点、原始站点和接收站点中存在的数据。Data Grid 不会删除数据。

    例如，当 LON 和 NYC 离线时，"k2"存在于 LON 和 NYC 上。当您使 LON 重新上线时，该位置上仍然存在"k2"。如果您将状态从 NYC 推送到 LON，则传输不会影响 LON 上的"k2"。

提示

为确保缓存的内容在状态传输后相同，请在推送状态前从接收站点的缓存中删除所有数据。

使用 clear （） 方法或 CLI 中的 clearcache 命令。

  • 状态传输不会覆盖启动推送后发生的数据的更新。

    例如，LON 和 NYC 中存在 "k1,v1"。LON 脱机，因此您将状态从 NYC 推送到 LON，这会使 LON 重新上线。在状态传输完成前，客户端将"k1,v2"放在 LON 上。

    在这种情况下，来自 NYC 的状态传输不会覆盖 "k1,v2"，因为启动推送后该修改发生。

自动状态传输

默认情况下，您必须使用 CLI 或 JMX 或 REST 手动执行跨站点状态传输操作。

但是，在使用异步备份策略时，Data Grid 可以自动执行跨站点状态传输操作。

当备份位置重新上线且网络连接稳定时，Data Grid 会在备份位置之间启动双向状态传输。例如，Data Grid 同时将状态从 LON 传输到 NYC 和 NYC 到 LON。

注意

为了避免临时网络断开触发状态传输操作，备份位置必须满足两个条件才能离线。备份位置的状态必须脱机，并且不能包含在 JGroups RELAY2 的跨站点视图中。

缓存启动时也会触发自动状态传输。

在 LON 启动的场景中，在缓存启动后，它会向 NYC 发送通知。之后，NYC 启动一个单向状态转移到 LON。

1.7. 站点间的客户端连接
复制链接

客户端可以在 Active/Passive 或 Active/Active 配置中写入 Data Grid 集群。

Active/Passive

下图演示了主动/被动，其中 Data Grid 只处理一个站点的客户端请求：

在前面的镜像中：

  1. 客户端连接到 LON 上的 Data Grid 集群。
  2. 客户端将 "k1" 写入缓存。
  3. LON 的中继节点 "n1" 发送请求，以将"k1"复制到位于 NYC 的中继节点"nA"。

通过主动/被动，NYC 提供数据冗余。如果 LON 的 Data Grid 集群因任何原因而离线，客户端就可以开始向 NYC 发送请求。当您使 LON 恢复在线时，您可以将数据与 NYC 同步，然后将客户端切回到 LON。

Active/Active

下图显示了在两个站点处理客户端请求的 Active/Active ：

在前面的镜像中：

  1. 客户端 A 连接到 LON 上的 Data Grid 集群。
  2. 客户端 A 将 "k1" 写入缓存。
  3. 客户端 B 连接到位于 NYC 的 Data Grid 集群。
  4. 客户端 B 将"k2"写入缓存。
  5. LON 和 NYC 发送请求的转发节点，以便"k1"复制到 NYC，"k2"复制到 LON。

通过 Active/Active NYC 和 LON 在处理客户端请求时将数据复制到远程缓存。如果 NYC 或 LON 离线，客户端可以开始向在线站点发送请求。然后，您可以使离线站点重新上线，将状态推送到同步数据，并根据需要切换客户端。

备份策略和客户端连接
重要

建议使用 Active/Active 配置的异步备份策略(strategy=async)。

如果多个客户端尝试同时写入同一条目，并且备份策略是同步的(strategy=sync)，则会出现死锁。但是，如果两个站点都访问不同的数据集，您可以使用同步备份策略，在这种情况下，不会出现并发写入的死锁风险。

1.7.1. 并发写入和冲突条目
复制链接

如果客户端同时写入同一条目，但在不同的站点上，可能会发生冲突的条目，并带有 Active/Active 站点配置。

例如，当客户端 B 写入 NYC 中的 "k1" 时，客户端 A 写入 LON 中的 "k1"。在这种情况下，"k1" 在 LON 中与 NYC 中的值不同。在进行复制后，不能保证哪个站点存在"k1"的值。

为确保数据一致性，Data Grid 使用向量时钟算法在备份操作过程中检测冲突的条目，如下例所示： 

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--
Copy to Clipboard Toggle word wrap

向量时钟是与每个写入条目递增的时间戳元数据。在前面的示例中，0 代表 "k1" 上向量时钟的初始值。

客户端将 "k1=2" 置于 LON 中，向量时钟为 1,0，数据网格复制到 NYC。然后，客户端将 "k1=3" 置于 NYC 中，并将向量时钟更新为 1,1，后者的数据网格复制到 LON。

但是，如果客户端同时将"k1=5"置于 LON 中，则客户端会将 "k1=8" 置于 NYC 中，则数据网格检测到冲突条目，因为 "k1" 的向量值在 LON 和 NYC 之间不严格更大或更少。

当找到冲突的条目时，Data Grid 使用 Java compareTo (String anotherString) 方法来比较站点名称。要确定哪个键具有优先级，Data Grid 选择不适合其他的站点名称。名为 AAA 的站点的键优先于名为 AAB 的站点的密钥，以此类推。

在同一示例后，为了解决"k1"的冲突，Data Grid 使用源自 LON 的 "k1" 的值。这会在 Data Grid 解析冲突并复制值后，在 LON 和 NYC 中都生成 "k1=5"。

提示

在站点名称前加上数字作为代表解析冲突条目的优先级顺序的简单方法；例如，1LON 和 2NYC。

备份策略

Data Grid 仅对异步备份策略(strategy=async)执行冲突解析。

您永远不会将同步备份策略与 Active/Active 配置一起使用。在这个配置并发写入会导致死锁和丢失数据。但是，如果两个站点都访问不同的数据集，您可以将同步备份策略与 Active/Active 配置一起使用，在这种情况下，不会出现并发写入的风险。

跨站点合并策略

除了配置 Data Grid 的跨站点合并策略外，数据源还提供 XSiteEntryMergePolicy SPI：

  • 始终删除冲突的条目。
  • 发生写/删除冲突时应用写入操作。
  • 当发生写/删除冲突时删除条目。

1.8. 跨站点复制过期
复制链接

过期会根据时间删除缓存条目。Data Grid 提供两种方法为条目配置过期：

Lifespan

lifespan 属性设置条目可以存在的最大时间。当您使用跨站点复制设置 生命周期 时，Data Grid 集群将条目独立于远程站点过期。

最大闲置

max-idle 属性根据给定时间段内的读取或写入操作指定条目可以存在的时长。当您使用跨站点复制设置 max-idle 时，Data Grid 集群发送 touch 命令，以使用远程站点协调空闲的超时值。

注意

在跨站点部署中使用最大闲置过期可能会影响性能，因为额外的处理可以保持 max-idle 值同步，意味着一些操作需要更长的时间才能完成。

第 2 章 配置 Data Grid 跨站点复制
复制链接

设置集群传输，以便数据网格集群可以相互发现，中继节点可以发送消息以进行跨站点复制。然后，您可以在 Data Grid 缓存中添加备份位置。

2.1. 为跨站点复制配置集群传输
复制链接

将 JGroups RELAY2 添加到您的传输层，以便数据网格可以将缓存复制到备份位置。

流程

  1. 打开 Data Grid 配置以进行编辑。
  2. 将 RELAY2 协议添加到 JGroups 堆栈。
  3. 使用传输配置的 stack 属性指定堆栈名称，以便 Data Grid 集群使用它。
  4. 保存并关闭您的 Data Grid 配置。
JGroups RELAY2 堆栈

以下配置显示了一个 JGroups RELAY2 堆栈：

  • 使用默认的 JGroups UDP 堆栈进行集群内部传输，这指的是本地站点的节点之间的通信。
  • 使用默认的 JGroups TCP 堆栈进行跨站点复制流量。
  • 将本地站点命名为 LON。
  • 指定集群中最多可发送跨站点复制请求的 1000 个节点。
  • 指定参与跨站点复制的所有备份位置的名称。 
<infinispan>
  <jgroups>
    <stack name="xsite" extends="udp">
      <relay.RELAY2 xmlns="urn:org:jgroups"
                    site="LON"
                    max_site_masters="1000"/>
      <remote-sites default-stack="tcp">
        <remote-site name="LON"/>
        <remote-site name="NYC"/>
      </remote-sites>
    </stack>
  </jgroups>
  <cache-container>
    <transport cluster="${cluster.name}" stack="xsite"/>
  </cache-container>
</infinispan>
Copy to Clipboard Toggle word wrap

2.1.1. 自定义 JGroups RELAY2 堆栈
复制链接

您可以将自定义 JGroups RELAY2 堆栈添加到 Data Grid 集群，以使用不同的传输属性进行跨站点复制。例如，以下配置使用 TCPPING 而不是 MPING 进行发现并扩展默认的 TCP 堆栈： 

<infinispan>
  <jgroups>
    <stack name="relay-global" extends="tcp">
      <TCPPING initial_hosts="192.0.2.0[7800]"
               stack.combine="REPLACE"
               stack.position="MPING"/>
    </stack>
    <stack name="xsite" extends="udp">
      <relay.RELAY2 site="LON" xmlns="urn:org:jgroups"
                    max_site_masters="10"
                    can_become_site_master="true"/>
      <remote-sites default-stack="relay-global">
        <remote-site name="LON"/>
        <remote-site name="NYC"/>
      </remote-sites>
    </stack>
  </jgroups>
</infinispan>
Copy to Clipboard Toggle word wrap

2.2. 在缓存中添加备份位置
复制链接

指定远程站点的名称，以便 Data Grid 可以将数据复制到这些集群上的缓存。

流程

  1. 打开 Data Grid 配置以进行编辑。
  2. 将 backup 元素添加到缓存配置中。
  3. 将远程站点的名称指定为备份位置。
    例如，在 LON 配置中，指定 NYC 作为备份。
  4. 在每个集群中重复前面的步骤，以便每个站点都是其他站点的备份。
    例如，如果您将 LON 添加为 NYC 的备份，您还应将 NYC 添加为 LON 的备份。
  5. 保存并关闭您的 Data Grid 配置。
备份配置

以下示例显示了 LON 集群的"customers"缓存配置：

XML

<replicated-cache name="customers">
  <backups>
    <backup site="NYC"
            strategy="ASYNC" />
  </backups>
</replicated-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "replicated-cache": {
    "name": "customers",
    "backups": {
      "NYC": {
        "backup" : {
          "strategy" : "ASYNC"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

replicatedCache:
  name: "customers"
  backups:
    NYC:
      backup:
        strategy: "ASYNC"
Copy to Clipboard Toggle word wrap

以下示例显示了 NYC 集群的"customers"缓存配置：

XML

<distributed-cache name="customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC" />
  </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "name": "customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  name: "customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"
Copy to Clipboard Toggle word wrap

2.3. 使用不同名称备份缓存
复制链接

默认情况下，Data Grid 在具有相同名称的缓存之间复制数据。如果您希望 Data Grid 在具有不同名称的缓存之间复制，您可以明确声明每个缓存的备份。

流程

  1. 打开 Data Grid 配置以进行编辑。
  2. 使用 backup-for 或 backupFor 将远程站点中的数据复制到本地站点上不同名称的缓存中。
  3. 保存并关闭您的 Data Grid 配置。
备份配置

以下示例配置 "eu-customers" 缓存来接收来自 LON 集群上的"customers"缓存的更新：

XML

<distributed-cache name="eu-customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC" />
  </backups>
  <backup-for remote-cache="customers"
              remote-site="LON" />
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "name": "eu-customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    },
    "backup-for" : {
      "remote-cache" : "customers",
      "remote-site" : "LON"
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  name: "eu-customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"
  backupFor:
    remoteCache: "customers"
    remoteSite: "LON"
Copy to Clipboard Toggle word wrap

2.4. 配置跨站点状态传输
复制链接

更改跨站点状态传输设置以优化性能，并指定是否手动或自动进行操作。

流程

  1. 打开 Data Grid 配置以进行编辑。

  2. 根据需要配置状态传输操作。

    1. 使用 chunk-size 或 chunkSize 指定要包含在每个状态传输操作中的条目数。
    2. 以毫秒为单位指定状态传输操作以 超时 完成的时间。
    3. 使用 max-retries 或 maxRetries 设置 Data Grid 的最大尝试次数，以重试失败的状态传输。
    4. 指定重试尝试与 wait-time 或 waitTime 之间的等待时间（以毫秒为单位）。
    5. 指定状态传输操作是否自动或通过 模式 手动进行。
  3. 打开 Data Grid 配置以进行编辑。
状态传输配置

XML

<distributed-cache name="eu-customers">
  <backups>
    <backup site="LON"
            strategy="ASYNC">
      <state-transfer chunk-size="600"
                      timeout="2400000"
                      max-retries="30"
                      wait-time="2000"
                      mode="AUTO"/>
    </backup>
  </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "name": "eu-customers",
    "backups": {
      "LON": {
        "backup": {
          "strategy": "ASYNC",
          "state-transfer": {
            "chunk-size": "600",
            "timeout": "2400000",
            "max-retries": "30",
            "wait-time": "2000",
            "mode": "AUTO"
          }
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  name: "eu-customers"
  backups:
    LON:
      backup:
        strategy: "ASYNC"
        stateTransfer:
          chunkSize: "600"
          timeout: "2400000"
          maxRetries: "30"
          waitTime: "2000"
          mode: "AUTO"
Copy to Clipboard Toggle word wrap

2.5. 配置冲突解析算法
复制链接

将 Data Grid 配置为使用不同的算法来解析备份位置之间的冲突条目。

流程

  1. 打开 Data Grid 配置以进行编辑。
  2. 指定其中一个 Data Grid 算法或自定义实现，作为合并策略来解析冲突条目。
  3. 保存并关闭您的 Data Grid 配置进行编辑。
Data Grid 算法
提示

在 org.infinispan.xsite.spi.XSiteMergePolicy enum 中查找所有 Data Grid 算法及其描述。

以下示例配置使用 ALWAYS_REMOVE 算法，该算法从两个站点中删除冲突条目：

XML

<distributed-cache>
   <backups merge-policy="ALWAYS_REMOVE">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "merge-policy": "ALWAYS_REMOVE",
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    mergePolicy: "ALWAYS_REMOVE"
    LON:
      backup:
        strategy: "ASYNC"
Copy to Clipboard Toggle word wrap

自定义冲突解析算法

如果创建自定义 XSiteEntryMergePolicy 实现，您可以将完全限定类名称指定为 merge 策略。

XML

<distributed-cache>
   <backups merge-policy="org.mycompany.MyCustomXSiteEntryMergePolicy">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "merge-policy": "org.mycompany.MyCustomXSiteEntryMergePolicy",
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    mergePolicy: "org.mycompany.MyCustomXSiteEntryMergePolicy"
    LON:
      backup:
        strategy: "ASYNC"
Copy to Clipboard Toggle word wrap

2.6. 清理 tombstones 以异步备份
复制链接

使用异步备份策略 Data Grid 会在删除密钥时存储元数据，称为 tombstones。Data Grid 定期运行一个任务来删除这些 tombstones，并在备份位置不再需要元数据时减少过量内存用量。您可以通过为 tombstone 映射定义目标大小以及任务运行之间的最大延迟来配置此任务的频率。

流程

  1. 打开 Data Grid 配置以进行编辑。

  2. 使用 tombstone-map-size 属性指定要存储的 tombstones 数量。

    如果 tombstones 的数量超过这个数字，则 Data Grid 会更频繁地运行清理任务。同样，如果 tombstones 的数量小于这个数字，则 Data Grid 不会像频繁运行清理任务一样运行清理任务。

  3. 添加 max-cleanup-delay 属性，并在 tombstone 清理任务之间指定最大延迟（以毫秒为单位）。
  4. 保存对配置的更改。
tombstone cleanup 任务配置

XML

<distributed-cache>
   <backups tombstone-map-size="512000" max-cleanup-delay="30000">
      <backup site="LON" strategy="ASYNC"/>
   </backups>
</distributed-cache>
Copy to Clipboard Toggle word wrap

JSON

{
  "distributed-cache": {
    "backups": {
      "tombstone-map-size": 512000,
      "max-cleanup-delay": 30000,
      "LON": {
        "backup": {
          "strategy": "ASYNC"
        }
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

distributedCache:
  backups:
    tombstoneMapSize: 512000
    maxCleanupDelay: 30000
    LON:
      backup:
        strategy: "ASYNC"
Copy to Clipboard Toggle word wrap

2.7. 验证跨站点视图
复制链接

当您将 Data Grid 设置为执行跨站点复制时，您应该检查日志文件，以确保 Data Grid 集群已成功用于跨站点视图。

流程

  1. 使用任何合适的编辑器打开 Data Grid 日志文件。
  2. 检查 ISPN000439: Received new x-site view 信息。

例如，如果 LON 中的 Data Grid 集群在 NYC 中带有 Data Grid 集群的跨站点视图，日志包括以下消息： 

INFO  [org.infinispan.XSITE] (jgroups-5,<server-hostname>) ISPN000439: Received new x-site view: [NYC]
INFO  [org.infinispan.XSITE] (jgroups-7,<server-hostname>) ISPN000439: Received new x-site view: [LON, NYC]
Copy to Clipboard Toggle word wrap

2.8. 为跨站点复制配置 Hot Rod 客户端
复制链接

将 Hot Rod 客户端配置为使用不同站点的 Data Grid 集群。

hotrod-client.properties

# Servers at the active site
infinispan.client.hotrod.server_list = LON_host1:11222,LON_host2:11222,LON_host3:11222

# Servers at the backup site
infinispan.client.hotrod.cluster.NYC = NYC_hostA:11222,NYC_hostB:11222,NYC_hostC:11222,NYC_hostD:11222
Copy to Clipboard Toggle word wrap

ConfigurationBuilder

ConfigurationBuilder builder = new ConfigurationBuilder();
builder.addServers("LON_host1:11222;LON_host2:11222;LON_host3:11222")
       .addCluster("NYC")
       .addClusterNodes("NYC_hostA:11222;NYC_hostB:11222;NYC_hostC:11222;NYC_hostD:11222")
Copy to Clipboard Toggle word wrap

提示

使用以下方法将 Hot Rod 客户端切换到默认集群或不同站点的集群：

  • RemoteCacheManager.switchToDefaultCluster()
  • RemoteCacheManager.switchToCluster (${site.name})

第 3 章 使用 CLI 执行跨站点操作
复制链接

使用 Data Grid 命令行界面(CLI)连接到 Data Grid Server 集群，管理站点，以及将状态传输推送到备份位置。

3.1. 使备份位置离线和在线
复制链接

手动使备份位置离线，并使它们重新上线。

先决条件

  • 创建与 Data Grid 的 CLI 连接。

流程

  1. 使用 site status 命令检查备份位置是否在线或离线： 

    site status --cache=cacheName --site=NYC
    Copy to Clipboard Toggle word wrap
    注意

    --site 是一个可选参数。如果没有设置，CLI 会返回所有备份位置。

    提示

    使用 --all-caches 选项获取所有缓存的备份位置状态。

  2. 管理备份位置，如下所示：

    • 使用 bring-online 命令在线显示备份位置： 

      site bring-online --cache=customers --site=NYC
      Copy to Clipboard Toggle word wrap

    • 使用 take-offline 命令使备份位置离线： 

      site take-offline --cache=customers --site=NYC
      Copy to Clipboard Toggle word wrap
提示

使用 --all-caches 选项使备份位置在线，或者对所有缓存使备份位置离线。

如需更多信息和示例，请运行 help site 命令。

3.2. 配置跨站点状态传输模式
复制链接

当 Data Grid 检测到备份位置上线时，您可以将跨站点状态传输操作配置为自动进行。或者，您可以使用默认模式手动执行状态传输。

先决条件

  • 创建与 Data Grid 的 CLI 连接。

流程

  1. 使用 site 命令配置状态传输模式，如下例所示：

    • 检索当前状态传输模式。 

      site state-transfer-mode get --cache=cacheName --site=NYC
      Copy to Clipboard Toggle word wrap

    • 为缓存和备份位置配置自动状态传输操作。 

      site state-transfer-mode set --cache=cacheName --site=NYC --mode=AUTO
      Copy to Clipboard Toggle word wrap
提示

运行 help site 命令以获取更多信息和示例。

3.3. 将状态推送到备份位置
复制链接

将缓存状态传输到备份位置。

先决条件

  • 创建与 Data Grid 的 CLI 连接。

流程

  • 使用 site push-site-state 命令来推送状态传输，如下例所示： 

    site push-site-state --cache=cacheName --site=NYC
    Copy to Clipboard Toggle word wrap
提示

使用 --all-caches 选项为所有缓存推送状态传输。

如需更多信息和示例，请运行 help site 命令。

第 4 章 使用 REST API 执行跨站点操作
复制链接

Data Grid Server 提供了一个 REST 端点，用于公开执行跨站点操作的方法。

4.1. 获取所有备份位置的状态
复制链接

使用 GET 请求检索所有备份位置的状态。 

GET /rest/v2/caches/{cacheName}/x-site/backups/
Copy to Clipboard Toggle word wrap

Data Grid 以 JSON 格式为每个备份位置的状态响应，如下例所示： 

{
  "NYC": {
    "status": "online"
  },
  "LON": {
    "status": "mixed",
    "online": [
      "NodeA"
    ],
    "offline": [
      "NodeB"
    ]
  }
}
Copy to Clipboard Toggle word wrap
Expand
表 4.1. 返回的状态
value描述

online

本地集群中的所有节点都有一个带有备份位置的跨站点视图。

离线

本地集群中没有带有备份位置的跨站点视图。

mixed

本地集群中的某些节点具有带有备份位置的跨站点视图，本地集群中的其他节点没有跨站点视图。响应表示每个节点的状态。

4.2. 获取特定备份位置的状态
复制链接

使用 GET 请求检索备份位置的状态。 

GET /rest/v2/caches/{cacheName}/x-site/backups/{siteName}
Copy to Clipboard Toggle word wrap

Data Grid 以 JSON 格式通过站点中的每个节点状态进行响应，如下例所示： 

{
  "NodeA":"offline",
  "NodeB":"online"
}
Copy to Clipboard Toggle word wrap
Expand
表 4.2. 返回的状态
value描述

online

节点在线。

离线

节点离线。

失败

无法检索状态。远程缓存可以在请求期间关闭或发生网络错误。

4.3. 使备份位置离线
复制链接

通过 POST 请求和 ?action=take-offline 参数使备份位置离线。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=take-offline
Copy to Clipboard Toggle word wrap

4.4. 在线提供备份位置
复制链接

使用 ?action=bring-online 参数在线启动备份位置。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=bring-online
Copy to Clipboard Toggle word wrap

4.5. 将状态推送到备份位置
复制链接

使用 ?action=start-push-state 参数将缓存状态推送到备份位置。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=start-push-state
Copy to Clipboard Toggle word wrap

4.6. 取消状态传输
复制链接

使用 ?action=cancel-push-state 参数取消状态传输操作。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-push-state
Copy to Clipboard Toggle word wrap

4.7. 获取状态传输状态
复制链接

使用 ?action=push-state-status 参数检索状态传输操作的状态。 

GET /rest/v2/caches/{cacheName}/x-site/backups?action=push-state-status
Copy to Clipboard Toggle word wrap

Data Grid 以 JSON 格式为每个备份位置的状态进行响应，如下例所示： 

{
   "NYC":"CANCELED",
   "LON":"OK"
}
Copy to Clipboard Toggle word wrap
Expand
表 4.3. 返回的状态
value描述

发送

状态传输到备份位置正在进行。

确定

状态传输成功完成。

ERROR

出现错误，状态为 transfer。检查日志文件。

取消

状态转移取消正在进行。

4.8. 清除状态传输状态
复制链接

使用 ?action=clear-push-state-status 参数发送站点的清除状态传输状态。 

POST /rest/v2/caches/{cacheName}/x-site/local?action=clear-push-state-status
Copy to Clipboard Toggle word wrap

4.9. 修改 会使离线条件
复制链接

如果满足某些条件，站点将处于离线状态。修改离线参数，以控制备份位置自动离线的时间。

流程

  1. 检查配置了 GET 请求和 take-offline-config 参数的离线参数。 

    GET /rest/v2/caches/{cacheName}/x-site/backups/{siteName}/take-offline-config
    Copy to Clipboard Toggle word wrap

    Data Grid 响应包括 after_failures 和 min_wait 字段，如下所示： 

    {
  "after_failures": 2,
  "min_wait": 1000
}
    Copy to Clipboard Toggle word wrap

  2. 修改 取 PUT 请求正文中的离线参数。 

    PUT /rest/v2/caches/{cacheName}/x-site/backups/{siteName}/take-offline-config
    Copy to Clipboard Toggle word wrap

    如果操作成功完成，服务会返回 204 （不内容）

4.10. 从接收站点取消状态传输
复制链接

如果两个备份位置之间的连接中断，您可以在接收推送的站点上取消状态传输。

从远程站点取消状态传输，并使用 ?action=cancel-receive-state 参数保留本地缓存的当前状态。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-receive-state
Copy to Clipboard Toggle word wrap

4.11. 获取备份位置的状态
复制链接

使用 GET 请求检索所有备份位置的状态。 

GET /rest/v2/container/x-site/backups/
Copy to Clipboard Toggle word wrap

Data Grid 以 JSON 格式的状态响应，如下例所示： 

{
   "SFO-3":{
      "status":"online"
   },
   "NYC-2":{
      "status":"mixed",
      "online":[
         "CACHE_1"
      ],
      "offline":[
         "CACHE_2"
      ],
      "mixed": [
         "CACHE_3"
      ]
   }
}
Copy to Clipboard Toggle word wrap
Expand
表 4.4. 返回的状态
value描述

online

本地集群中的所有节点都有一个带有备份位置的跨站点视图。

离线

本地集群中没有带有备份位置的跨站点视图。

mixed

本地集群中的某些节点具有带有备份位置的跨站点视图，本地集群中的其他节点没有跨站点视图。响应表示每个节点的状态。 

GET /rest/v2/container/x-site/backups/{site}
Copy to Clipboard Toggle word wrap

返回单个备份位置的状态。

4.12. 使备份位置离线
复制链接

使用 ?action=take-offline 参数使备份位置离线。 

POST /rest/v2/container/x-site/backups/{siteName}?action=take-offline
Copy to Clipboard Toggle word wrap

4.13. 在线提供备份位置
复制链接

使用 ?action=bring-online 参数在线启动备份位置。 

POST /rest/v2/container/x-site/backups/{siteName}?action=bring-online
Copy to Clipboard Toggle word wrap

4.14. 检索状态传输模式
复制链接

使用 GET 请求检查状态传输模式。 

GET /rest/v2/caches/{cacheName}/x-site/backups/{site}/state-transfer-mode
Copy to Clipboard Toggle word wrap

4.15. 设置状态传输模式
复制链接

使用 ?action=set 参数配置状态传输模式。 

POST /rest/v2/caches/{cacheName}/x-site/backups/{site}/state-transfer-mode?action=set&mode={mode}
Copy to Clipboard Toggle word wrap

4.16. 启动状态传输
复制链接

使用 ?action=start-push-state 参数将所有缓存的状态推送到远程站点。 

POST /rest/v2/container/x-site/backups/{siteName}?action=start-push-state
Copy to Clipboard Toggle word wrap

4.17. 取消状态传输
复制链接

使用 ?action=cancel-push-state 参数取消持续状态传输操作。 

POST /rest/v2/container/x-site/backups/{siteName}?action=cancel-push-state
Copy to Clipboard Toggle word wrap

第 5 章 通过 JMX 执行跨站点操作
复制链接

执行跨站点操作，如推送状态转移并通过 JMX 进行站点上线。

5.1. 注册 JMX MBeans
复制链接

Data Grid 可以注册可以用来收集统计信息并执行管理操作的 JMX MBeans。您还必须启用统计信息，否则 Data Grid 为 JMX MBeans 中的所有统计属性提供 0 值。

重要

只有在 Data Grid 嵌入于应用程序中而不是远程 Data Grid 服务器时，使用 JMX Mbeans 来收集统计信息。

当您使用 JMX Mbeans 从远程 Data Grid 服务器收集统计信息时，从 JMX Mbeans 接收的数据可能与 REST 等其他 API 接收的数据不同。在这种情况下，从其他 API 接收的数据更为准确。

流程

  1. 打开 Data Grid 配置以进行编辑。
  2. 将 jmx 元素或对象添加到缓存容器，并将 true 指定为 enabled 属性或字段的值。
  3. 添加 domain 属性或字段，并指定公开 JMX MBeans 的域（如果需要）。
  4. 保存并关闭您的客户端配置。
JMX 配置

XML

<infinispan>
  <cache-container statistics="true">
    <jmx enabled="true"
         domain="example.com"/>
  </cache-container>
</infinispan>
Copy to Clipboard Toggle word wrap

JSON

{
  "infinispan" : {
    "cache-container" : {
      "statistics" : "true",
      "jmx" : {
        "enabled" : "true",
        "domain" : "example.com"
      }
    }
  }
}
Copy to Clipboard Toggle word wrap

YAML

infinispan:
  cacheContainer:
    statistics: "true"
    jmx:
      enabled: "true"
      domain: "example.com"
Copy to Clipboard Toggle word wrap

5.2. 使用 JMX 客户端执行跨站点操作
复制链接

使用 JMX 客户端执行跨站点操作。

先决条件

  • 配置数据网格以注册 JMX MBeans

流程

  1. 使用任何 JMX 客户端连接到 Data Grid。

  2. 从以下 MBeans 调用操作：

    • XSiteAdmin 为缓存提供跨站点操作。

    • GlobalXSiteAdminOperations 为缓存管理器提供跨站点操作。

      例如，若要使站点重新上线，可调用 bringSiteOnline (siteName)。

5.3. JMX MBeans 用于跨站点复制
复制链接

Data Grid 为跨站点复制提供 JMX MBeans，允许您收集统计信息并执行远程操作。

org.infinispan:type=Cache 组件提供以下 JMX MBeans：

  • XSiteAdmin 会公开适用于特定缓存实例的跨站点操作。
  • RpcManager 提供关于用于跨站点复制的网络请求的统计信息。
  • AsyncXSiteStatistics 为异步跨站点复制提供统计信息，包括队列大小和冲突数量。

org.infinispan:type=CacheManager 组件包括以下 JMX MBean：

  • GlobalXSiteAdminOperations 会公开适用于缓存容器中的所有缓存的跨站点操作。

有关 JMX MBeans 以及可用操作和统计的描述的详情，请查看 Data Grid JMX 组件 文档。

法律通告
复制链接

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部