To migrate the Presence Server application
from version 6.2 to version 7.0,
begin by creating a new cluster for the version 7.0 application
instance. The new cluster runs in parallel with the existing cluster
until a suitable amount of system activity has made the transition
to the new cluster.
None of the Presence Server resources
(data sources, topics, thread pools, sessions, and so forth) are shared
between the version 6.2 and version 7.0 application
instances. As a result, each installation functions independently
while the migration is in progress.
The following assumptions
and prerequisites apply for the migration process:
- This process assumes an “in-place” migration, with no new hardware
resources being added.
- Failover is not supported during the migration period.
- The migration is complete when all operations are running on the
new version 7.0 cluster.
You have the option of either keeping the version 6.2 cluster running
until all sessions have ended, or stopping the cluster when you believe
that a suitable threshold of activity has been reached.
- Sessions can be several hours in length and can be refreshed by
the client before expiring. Because of this, new dialogs (which can
be routed to the new version 7.0 cluster)
are created only when clients are switched on.
Database considerations
Presence Server version 7.0 uses
a different database schema than it used in version 6.2. As a result,
you will create new databases for your version 7.0 installation
rather than retaining the version 6.2 databases.
Here are some
general considerations for migrating the data in your version 6.2
Presence Server database:
- The installation package contains scripts (db2Get and oracleGet)
with which you can extract your existing configuration settings from
the database and store them in a temporary file. Then, after you install Presence Server version 7.0,
you can copy the configuration settings to the new SystemConfiguration.xml file.
From there, they are loaded into the new database.
- User information is not retained during the migration from a version
6.2 system to a version 7.0 system.
(User information includes information published by users, information
about watchers, information about managing servers, and information about
documents for which content indirection is supported.) As the migration
proceeds, new operations–for example, publish and subscribe requests–are
initiated on the version 7.0 cluster,
and the data associated with those operations is recorded in the new
version 7.0 database.
Note that watcher history information (information about watchers
that are in waiting state, with no active subscriptions) is stored
only in the version 6.2 database and is not retained.
- Usage records are not retained during the migration. If you need
to preserve usage records after the migration, you should plan to
extract them from the version 6.2 database after all activity has
ended on the version 6.2 cluster.
- Because some persistence data is located in the version 6.2 database
and some is located in the version 7.0 database,
failover is not supported during the migration period.
Coexistence with other components
Presence Server version
6.2 can coexist with IBM® WebSphere® XML
Document Management Server Component (IBM XDMS)
version 7.0 for
group list and presence-rules operations. Presence Server version
6.2 uses the ua-profile event package to subscribe
to IBM XDMS in
order to receive group structure. As long as XDMS groups are created
with no local lists, Presence Server version
6.2 will be able to manage and handle the XDMS group structure.
Presence Server version 7.0 can
coexist with IBM XDMS version
6.2. A configuration setting, enableXcapEvent, controls
whether Presence Server uses
the ua-profile event package, which is compatible
with IBM XDMS version
6.2. Note that when the enableXcapEvent setting is
disabled, Presence Server version 7.0 does
not support resource-list services documents and local lists in particular.