Migrating Redwood Platform
Before you start the migration of the central Redwood Server system, you have to complete the following steps:
Prerequisites
- Privileges on the new central Redwood server to unzip the redwood-platform.zip and mount or copy the
DataRootDirectory
from the old central Redwood server.- If you are using the same OS family (Windows, UNIX) it is recommended to keep the same path on the source and target servers.
- If you are migrating from Windows to UNIX (or vice-versa) or cannot keep the same path on the target server, you will have to update table
jcs_jobfile1
to point to the new path - this has to be done in the native database tooling, for example,sqlplus
for Oracle.
- New central Redwood server must be a supported platform with a supported JVM installed.
- The
redwood-platform.zip
version 9.2.8 must be readily available on the new central Redwood server. If you are migrating from an older version, it is not recommended to update the schema in the old database directly as you might need to abort or postpone the migration, for example, if problems are detected that cannot be addressed immediately.- If you are migrating from version 9.1.5 or higher, the admin server version 9.2.8 will be able to update the schema.
- If you are migrating from version 9.0.22 up until 9.1.4, you will need a
redwood-platform.zip
for version 9.1.5 as well as the one for version 9.2.8. Note that 9.1.5 requires Java 8, so that also needs to be available in the new server. - If you are migrating from a version lower than 9.0.22, for example 9.0.21, you will need
redwood-platform.zip
for versions 9.0.22, 9.1.5, and 9.2.8. Note that 9.0.22 requires Java 8, so that also needs to be available in the new server.
- Network connectivity from the new central Redwood server to the new database server (database port) and all platform agents (platform agent port) must work; if platform agents and/or the database server use TLS, the certificate(s) must be trusted by the JVM.
- If you wish to migrate the database using the admin server, the new server must be able to connect to the source database to migrate.
Workflow
Please read the workflow in full and ensure that you know exactly what is expected of you. Ensure you have the required technical parties (System Administration, DBA, Redwood Support) at your disposal prior to starting the procedure to keep downtime at a minimum.
- Prepare the installation files on the new server. See Preparing the Installation Files. Ensure you have a supported JVM installed on the target central Redwood server. Specify any required environment variables/system properties, copy the
<install_dir>/j2ee/cluster/server1/bin/setvars.{sh,bat}
and<install_dir>/j2ee/cluster/adminserver1/bin/setvars.{sh,bat}
files from the old system to the new system and adapt them to the target system, if required. If you are migrating from one OS family to another (Windows to UNIX or vice-versa), you have have to create a platform-specificsetvars
file (setvars.sh
orsetvars.bat
) with all required settings. When you migrate from an older version, this must be done for all<install_dir>/j2ee/cluster/adminserver1/bin/setvars.{sh,bat}
files from theredwood-platform.zip
files you need for the migration, note that if you migrate from version 9.1.5 or lower, you will need a JAVA 8 JVM; see Prerequisites. - Stop the old central server and perform a backup of the database. If the hostname of the central server is to change, ensure Redwood is made aware of the timing of your migration plans, deactivate the license prior to stopping the server and provide Redwood with the deactivation key. Redwood will provide you with a new license upon request.
- Prepare the database, see Database Prerequisites if you are switching database servers and perform either of the following:
- If your old server is on SAP NetWeaver, see SAP NetWeaver to Redwood Platform Migration.
- If you are going to use the same database on the same database server, simply copy the XML file in
<install_dir>/j2ee/cluster/server1/conf/Catalina/localhost/redwood.xml
from the old server to the new server. - If you are switching database servers, see DB2, SQL Server, Oracle, PostgreSQL.
- You copy or mount the
DataRootDirectory
on the new host if it was a network drive or SAN. - If the
DataRootDirectory
path was changed (mount point, drive letter), which is not recommended, update tablejcs_jobfile1
to point to the new location. See Updating the jcs_jobfile1 table. - If the central server hostname has changed:
- If your platform agents were locked to the old server, update the
address_acl
configuration file on each of them with the new URL or rename it.
- If your platform agents were locked to the old server, update the
- Start the central Redwood server, install the license if you changed the central Redwood server's hostname.
- If you changed the path of the
DataRootDirectory
, submit System_SetSystemDataRootDirectory as soon as possible to update theDataRootDirectory
for System process server.
SAP NetWeaver to Redwood Platform Migration
SAP Hana or Sybase
If you have SAP HANA or Sybase ASE as underlying database, follow this procedure:
- If you are upgrading from a version lower than 9.2.8, you copy the database to a temporary database accessible by the admin server and follow Upgrading the Database Schema.
- Retrieve the JDBC database driver for your database and connect to the database. See SAP Hana for instructions for SAP HANA, the same applies for Sybase, you have to get the Sybase JDBC dirver instead of the SAP HANA driver, note that in the case of a migration, you will not install the database as it is already there. If you are asked to upgrade the database schema, ensure you have a backup of the database and do so.
- Proceed to the Migrating the Database with the Admin Server section below.
DB2, SQL Server, Oracle, PostgreSQL
- You have the choice between migrating the database using db-specific tooling, faster but requires that both source and target databases are of the same flavor (for example both are DB2), and using the admin server which is slower and requires a connection from the new server to the old database; the admin server is database flavor independent.
- If you are using database-specific tooling, ask your DBA to copy the schema containing the
jcs_
tables to the new database server and proceed to Migrating the Central Redwood Server. - If you are not using database-specific tooling, start the admin server and connect to the source database to migrate, if you need to upgrade the database schema, ensure you have a backup of the database and do so.
- Proceed to the Migrating the Database with the Admin Server section below.
Migrating the Database with the Admin Server
- Start the admin server version 9.2.8 if it is not already running, connect to the source database.
- Go to DB Tools > Export and fill
jcs.*
into the Pattern field and an existing output directory on the central Redwood server in the Output Directory field, for example../temp
. Note that, depending on the size of the database, this can take a considerable amount of time and use significant disk space. - Use your browser to navigate to
https://<server>:10185/scheduler-admin/login/logout.jsp
to log out of the source database. - Log in to the target database, install the database if instructed to do so.
- Navigate to DB Tools > Clear and fill
.*
into the Pattern field to truncate the database tables before the import. - Navigate to DB Tools > Import and fill the path to the directory where the export was performed, for example,
../temp
. Depending on the size of the exported database, this can take a significant amount of time. - Use your browser to navigate to
https://<server>:10185/scheduler-admin/login/logout.jsp
to log out of the target database. - If you have not mounted/copied the
DataRootDirectory
to the same path, see Updating the jcs_jobfile1 table. - You may now stop the admin server and start the central Redwood server (
server1
).
Migrating the Central Redwood Server
If you used database-specific tooling to migrate the database, you still have to ensure the database is up-to-date.
- Start the admin server and connect to the database, upgrade the database schema if required.
- Ensure you have either mounted/copied the
DataRootDirectory
to the same path or update thejcs_jobfile1
, see Updating the jcs_jobfile1 table. - Stop the admin server and start the central Redwood server (
server1
).
Upgrading the Database Schema
Since the database schema is not up-to-date and as a good practice you do not alter a source system when you migrate, you copy the database to a temporary database and update that, if the source and target database flavors (for example Oracle) are the same, the temporary database can be the target database for the migration.
- Use native database tooling to make a copy of the source database into the temporary database.
- If you are migrating from version 9.0.21 or lower, start the admin server version 9.0.22, connect it to the temporary database, choose Connect and Install/Update.
- Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
- Stop the admin server.
- You now have 9.0.22, proceed to instructions for 9.1.4 or lower.
- If you are migrating from version 9.1.4, start the admin server version 9.1.5, connect it to the temporary database, choose Connect and Install/Update.
- Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
- Stop the admin server.
- Start the admin server version 9.2.8, connect it to the temporary database, choose Connect and Install/Update.
- Wait for the schema evaluation to complete, choose Upgrade, wait for the upgrade to complete.
- Stop the admin server.
- Database schema upgrade is complete.
Updating the jcs_jobfile1 table
Although it is recommended to always have the same path to DataRootDirectory
, it can happen that this is not an option, for example, when you switch OS family from UNIX to Windows, for example. When you need to change the path to DataRootDirectory
, ensure the database is upgraded. You can either use a native database client to run the SQL query or create an SQL file and use the admin server.
If a native database client is not available, you can use the admin server to update the jcs_jobfile1
table.
- Create a file with the below SQL, depending on your database flavor and copy it to the server hosting the admin server.
- Use the admin server to connect to the target database if you are not already connected.
- Navigate to DB Tools > Execute SQL, specify the full path to the SQL file in the SQL File field and choose Execute.
- Use your browser to navigate to
https://<server>:10185/scheduler-admin/login/logout.jsp
to log out of the target database.
SQL Server
use <database_name>
update table [dbo].[JCS_JOBFILE1]
set a_name = replace(a_name, '<old_path>', '<new_path>');
go
DB2, Oracle, PostgreSQL
update table jcs_jobfile1
set a_name = replace(a_name, '<old_path>', '<new_path>');
commit;
Examples
SQL Server
use redwood
update table [dbo].[JCS_JOBFILE1]
set a_name = replace(a_name, 'c:\redwood', 'd:\redwood');
go
Other Supported Databases
update table jcs_jobfile1
set a_name = replace(a_name, 'c:\redwood', 'd:\redwood');
commit;
See Also
Database Tools in the Admin Server
onsiteTopic