Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 2. Configuring Data Grid cross-site replication

Set up cluster transport so Data Grid clusters can discover each other and relay nodes can send messages for cross-site replication. You can then add backup locations to Data Grid caches.

2.1. Configuring cluster transport for cross-site replication
링크 복사

Add JGroups RELAY2 to your transport layer so that Data Grid can replicate caches to backup locations.

Procedure

  1. Open your Data Grid configuration for editing.
  2. Add the RELAY2 protocol to a JGroups stack.
  3. Specify the stack name with the stack attribute for the transport configuration so the Data Grid cluster uses it.
  4. Save and close your Data Grid configuration.

JGroups RELAY2 stacks

The following configuration shows a JGroups RELAY2 stack that:

  • Uses the default JGroups UDP stack for inter-cluster transport, which refers to communication between nodes at the local site.
  • Uses the default JGroups TCP stack for cross-site replication traffic.
  • Names the local site as LON.
  • Specifies a maximum of 1000 nodes in the cluster that can send cross-site replication requests.
  • Specifies the names of all backup locations that participate in cross-site replication. 
<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. Custom JGroups RELAY2 stacks
링크 복사

You can add custom JGroups RELAY2 stacks to Data Grid clusters to use different transport properties for cross-site replication. For example, the following configuration uses TCPPING instead of MPING for discovery and extends the default TCP stack: 

<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. Adding backup locations to caches
링크 복사

Specify the names of remote sites so Data Grid can replicate data to caches on those clusters.

Procedure

  1. Open your Data Grid configuration for editing.
  2. Add the backups element to your cache configuration.
  3. Specify the name of the remote site as the backup location.
    For example, in the LON configuration, specify NYC as the backup.
  4. Repeat the preceding steps on each cluster so that each site is a backup for other sites.
    For example, if you add LON as a backup for NYC you should also add NYC as a backup for LON.
  5. Save and close your Data Grid configuration.

Backup configuration

The following example shows the "customers" cache configuration for the LON cluster:

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

The following example shows the "customers" cache configuration for the NYC cluster:

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. Backing up to caches with different names
링크 복사

Data Grid replicates data between caches that have the same name by default. If you want Data Grid to replicate between caches with different names, you can explicitly declare the backup for each cache.

Procedure

  1. Open your Data Grid configuration for editing.
  2. Use backup-for or backupFor to replicate data from a remote site into a cache with a different name on the local site.
  3. Save and close your Data Grid configuration.

Backup for configuration

The following example configures the "eu-customers" cache to receive updates from the "customers" cache on the LON cluster:

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. Configuring cross-site state transfer
링크 복사

Change cross-site state transfer settings to optimize performance and specify whether operations happen manually or automatically.

Procedure

  1. Open your Data Grid configuration for editing.

  2. Configure state transfer operations as appropriate.

    1. Specify the number of entries to include in each state transfer operation with chunk-size or chunkSize.
    2. Specify the time to wait, in milliseconds, for state transfer operations to complete with timeout.
    3. Set the maximum number of attempts for Data Grid to retry failed state transfers with max-retries or maxRetries.
    4. Specify the time to wait, in milliseconds, between retry attempts with wait-time or waitTime.
    5. Specify if state transfer operations happen automatically or manually with mode.
  3. Open your Data Grid configuration for editing.

State transfer configuration

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. Configuring conflict resolution algorithms
링크 복사

Configure Data Grid to use a different algorithm to resolve conflicting entries between backup locations.

Procedure

  1. Open your Data Grid configuration for editing.
  2. Specify one of the Data Grid algorithms or a custom implementation as the merge policy to resolve conflicting entries.
  3. Save and close your Data Grid configuration for editing.

Data Grid algorithms

Tip

Find all Data Grid algorithms and their descriptions in the org.infinispan.xsite.spi.XSiteMergePolicy enum.

The following example configuration uses the ALWAYS_REMOVE algorithm that deletes conflicting entries from both sites:

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

Custom conflict resolution algorithms

If you create a custom XSiteEntryMergePolicy implementation, you can specify the fully qualified class name as the merge policy.

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. Cleaning tombstones for asynchronous backups
링크 복사

With the asynchronous backup strategy Data Grid stores metadata, known as tombstones, when it removes keys. Data Grid periodically runs a task to remove these tombstones and reduce excessive memory usage when backup locations no longer require the metadata. You can configure the frequency for this task by defining a target size for tombstone maps as well as the maximum delay between task runs.

Procedure

  1. Open your Data Grid configuration for editing.

  2. Specify the number of tombstones to store with the tombstone-map-size attribute.

    If the number of tombstones increases beyond this number then Data Grid runs the cleanup task more frequently. Likewise, if the number of tombstones is less than this number then Data Grid does not run the cleanup task as frequently.

  3. Add the max-cleanup-delay attribute and specify the maximum delay, in milliseconds, between tombstone cleanup tasks.
  4. Save the changes to your configuration.

Tombstone cleanup task configuration

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. Verifying cross-site views
링크 복사

When you set up Data Grid to perform cross-site replication, you should check log files to ensure that Data Grid clusters have successfully formed cross-site views.

Procedure

  1. Open Data Grid log files with any appropriate editor.
  2. Check for ISPN000439: Received new x-site view messages.

For example, if a Data Grid cluster in LON has formed a cross-site view with a Data Grid cluster in NYC, logs include the following messages: 

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. Configuring Hot Rod clients for cross-site replication
링크 복사

Configure Hot Rod clients to use Data Grid clusters at different sites.

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

Tip

Use the following methods to switch Hot Rod clients to the default cluster or to a cluster at a different site:

  • RemoteCacheManager.switchToDefaultCluster()
  • RemoteCacheManager.switchToCluster(${site.name})
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat