+

Search Tips   |   Advanced Search

Replicating data with a multi-broker replication domain

Use this task to manage replication domains that you migrated from a Version 6.x or earlier product environment.

transition: Multi-broker replication domains are not created in Version 7.0 product environments. However they can be migrated from existing Version 6.x product environments. If we migrate Version 6.x multi-broker replication domains, we can use the Multi-broker domain panel in the Version 7.0 console to manage these domains.

Although we can manage migrated multi-broker domains with the current version of the product, after you upgrade the deployment manager, we can create only data replication domains in the console. Consider migrating any existing multi-broker domains to the new data replication domains.

If we are performing this task, it is assumed configuredd replication with a previous version of the product, and defined replication domains that list connected replicator entries, residing in managed servers in the cell that can exchange data. We can manage these existing replication domains and replicator entries, but we cannot create new multi-broker replication domains or new replicator entries in the console.

A replicator does not need to run in the same process as the application server that uses it. However, it might be easier to manage replicators and replication domains if a one-to-one relationship exists between replicators and application servers. During configuration, we can select the local replicator as the default replicator.

  1. Manage multi-broker replication domain configuration settings. In the console, click Environment > Replication domains.

  2. Click Multi-broker domain >multi-broker domain_name, and update the values for that particular multi-broker replication domain. The default values are generally sufficient, especially for the pooling and timeout properties.

    1. Name the replication domain.

    2. Specify the timeout interval.

    3. Specify the encryption type. The DES and TRIPLE_DES options encrypt data sent between application server processes and better secure the network joining the processes.

    4. Partition the replication domain to filter the number of processes to which data is sent. Partitioning the replication domain is most often done if you are replicating data to support retrieval of an HTTP session if the process maintaining the HTTP session fails. Partitioning is not supported for sharing of cached data that is maintained by web container dynamic caching.

    5. Specify whether we want a single replication of data to be made. Enable the option if you are replicating data to support retrieval of an HTTP session if the process maintaining the HTTP session fails.

    6. Specify whether processes should receive data in objects or bytes. Processes receiving data in objects receive the data and class definitions. Processes receiving data in bytes receive the data only.

    7. Configure a pool of replication resources. Pooling replication resources can enhance the performance of the replication service.

  3. Maintain the replicators that we have already defined. We cannot create any replicators. The default convention is to define a replicator in each application server that uses replication. However, we can define a pool of replicators, separate from the servers hosting applications.

    1. In the console, click Environment > Replication domains replication_domain_name > Replicator entries > replicator_entry_name.

    2. Specify a replicator name and select a server available within the cell to which we can assign a replicator. Also specify a host name and ports. Note that a replicator has two ports (replicator and client ports) that use the same host name but have different ports.

  4. Click OK to save the changes.


Subtopics


Related tasks

  • Migrate servers from multi-broker replication domains to data replication domains
  • Replicating data across application servers in a cluster
  • Configure cache replication