Migrate V6.0 servers from multi-broker replication domains to data replication domains
Use this task to migrate multi-broker replication domains to data replication domains. Multi-broker domains were created with a previous version of WebSphere Application Server.
Before you begin
For HTTP session affinity to continue working correctly when migrating V5.x application servers to V6.0 application servers, upgrade all of the Web server plug-ins for WAS to the latest version before upgrading the application servers that perform replication.
After you upgrade your deployment manager to the latest version of WebSphere Application Server, one can create data replication domains only. Any multi-broker domains that you created with a previous release of WAS are still functional, however, one cannot create new multi-broker domains or replicators with the administrative console.
The different versions of application servers cannot communicate with each other. When migrating your servers to the current version of WebSphere Application Server, keep at least two application servers running on the previous version so that replication remains functional.
Overview
Perform this task on any multi-broker domains in your configuration after all of your servers that are using this multi-broker domain have been migrated to the current version of WebSphere Application Server. For more information about the differences between multi-broker domains and the data replication domains, see Comparison of multi-broker versus data replication domains.
Example
The following examples illustrate the migration process for common configurations:
Migrating an application server configuration that uses an instance of data replication service in peer-to-peer mode
Use this migration path to migrate a replication domain that uses the default peer-to-peer configuration. Dynamic cache replication domains use the peer-to-peer topology. See Memory-to-memory topology: Peer-to-peer function for more information.
Before you begin, migrate all the Web server plug-ins for your application server cluster to the current version.
- Migrate one or more of your existing servers to the current version of WebSphere Application Server.
- In the administrative console, create an empty data replication domain. Click Environment > Replication domains > New in the administrative console. See Replicating data across application servers in a cluster for more information about creating a data replication domain.
- Add your migrated application servers to the new data replication domain. For example, if you are migrating 4 servers, migrate 2 servers first and add them to the new replication domain. Configure the servers to use the new domain by configuring the consumers of the replication domain.
- When the new data replication domains are successfully sharing data, migrate the rest of the servers that are using the multi-broker replication domain to data replication domains.
- Delete the empty multi-broker replication domain.
Migrating an application server configuration that uses an instance of the data replication service in client/server mode
Use this set of steps to migrate a replication domain that uses client/server mode.
Before you begin migrating a client/server mode replication domain, consider if migrating your replication domains might cause a single point of failure. Because you migrate the servers to the new type of replication domain one at a time, you risk a single point of failure if there are 3 or fewer application servers. Before migrating, configure at least 4 servers that use multi-broker replication domains. Perform the following steps to migrate the multi-broker domains to data replication domains:
- Migrate one or more of your existing servers to the current version of WebSphere Application Server.
- In the administrative console, create an empty data replication domain. Click Environment > Replication domains > New in the administrative console. See Replicating data across application servers in a cluster for more information about creating a data replication domain.
- Add your migrated servers to the new data replication domain. For example, if you are migrating 4 servers, migrate two of these servers and then add them to the new replication domain. Configure the servers to use the new domain by configuring the consumers of the replication domain.
- Add a part of the clients to the new data replication domain.
- When the new data replication domains are successfully sharing data, migrate the rest of the clients and servers that are using the multi-broker replication domain to data replication domains.
- Delete the empty multi-broker replication domain.
Migrating a replication domain that uses HTTP session memory-to-memory replication that is overloaded at the application or web module level
- Upgrade your deployment manager to the current version of WebSphere Application Server. All the application servers remain configured with the old multi-broker domains on the previous version of WebSphere Application Server.
- In the administrative console, create an empty data replication domain. Click Environment > Replication domains > New in the administrative console. See Replicating data across application servers in a cluster for more information about creating a data replication domain.
- Migrate each application server to the current version of WebSphere Application Server, one at a time. The remaining servers on the previous version of WAS can still communicate with each other, but not with the migrated servers. The migrated servers can also communicate with each other.
- Continue migrating all of the servers to the current version of WebSphere Application Server. All of the application servers are still using multi-broker replication domains, so the features of data replication domains cannot be used.
- Configure all of the application servers to use the new data replication domain, adding the application servers to the empty replication domain that you created.
- Restart all of the application servers in the cluster.
- Delete the empty multi-broker replication domain.
What to do next
During this process, you might lose existing sessions. However, the application remains active through the entire process, so users do not experience down time during the migration. Create a new replication domain for each type of consumer. For example, create one replication domain for session manager and another replication domain for dynamic cache. See Replicating data across application servers in a cluster for more information.
See also
Comparison of multi-broker versus data replication domains
See Also
Replication
Related Tasks
Replicating data across application servers in a cluster