Question
UniCredit Business Integrated Solutions
RO
Last activity: 7 Jun 2019 5:09 EDT
Migration to a new server using the existing database
Hello,
We're initiating a migration process (as a fresh install on a new server) on one of our PEGA applications (PRPC 7.1.9 + SIPay 7.1.1 + our app) from the existing WAS application server to a Jboss one. We want to keep the existing database, we have a multi schema installation. The install on the migrated machine will be performed via the included sh files within the PEGA installation kit.
I would kindly ask for guidance if ok (or what would be the implications) to add the DB connection parameters into setupDatabase.properties and use it like this with the install.sh for the install on the migration server.
Will the initial system be kept as it is (with WAS) and will we be able to work from the migrated machine as well (Jboss)? While the old installation is actually not in use anymore.
Thanks a lot!
Proximus
BE
Hello,
Are you just moving from WAS to JBOSS without touching your PEGA Apps or you're doing WAS to JBOSS move plus PEGA platform upgrade?
Thank you
Anthony
UniCredit Business Integrated Solutions
RO
Hi Anthony,
We're only moving WAS to JBOSS. We're not going to touch PEGA.
On the new machine (JBOSS) we're performing a fresh install of the same PRPC / app versions as on the old server. We want this new machine with JBOSS to point to the existing DB (multi schema).
Thank you!
Proximus
BE
<env name="Identification/SystemName" value="prpc" /> - Start the new servers as prpc system, so not as your existing system name
<env name="agent/masterdelay" value="5000000" /> - Avoid having any agents started/running on new servers, they are not supposed to process data. This maybe not best way to do, but it's easy and works fine
<env name="cluster/Hazelcast/members" value="your new servers list comma separated" /> --> Define the list of new servers only which will be part of above defined temporary system name
The ear I deploy is not having any listeners.
That way, I'm able to start all new servers against existing DB as prpc application so not conflicting with existing running application.
The day of the switch, it really depends on your global application/setup, but the smallest part is:
Stop your active system
Update prconfig on new server (comment System Name line or put the real System name)
<env name="Identification/SystemName" value="prpc" /> - Start the new servers as prpc system, so not as your existing system name
<env name="agent/masterdelay" value="5000000" /> - Avoid having any agents started/running on new servers, they are not supposed to process data. This maybe not best way to do, but it's easy and works fine
<env name="cluster/Hazelcast/members" value="your new servers list comma separated" /> --> Define the list of new servers only which will be part of above defined temporary system name
The ear I deploy is not having any listeners.
That way, I'm able to start all new servers against existing DB as prpc application so not conflicting with existing running application.
The day of the switch, it really depends on your global application/setup, but the smallest part is:
Stop your active system
Update prconfig on new server (comment System Name line or put the real System name)
-> By restarting the new servers, they'll be up as your new active servers
then deploy your ear with listeners
Then comment agent line from prconfig to have agents running.
You can do all together at once if you like the big bang :)
This is the basic.
Then you need to take into account any external job/script having references to your old servers.
you need to take care of any global load balancer having ref to your previous servers
Any certificates should have previously been installed on future new servers
etc...
Hope this helps
Regards
Anthony