In this section, you move all existing API Manager configurations from the current environment to the new one.
Back up the databases in your API Manager instances and synapse configs in of all the tenants, including the super tenant. You find the synapse configs in
<APIM_1.9.0_HOME>/repository/conf/datasources/master-datasources.xmlfile and provide the datasource configurations for the following databases. You can copy the configurations from the same file in the API Manager 1.8.0 instance.
- User Store
- Registry database
- API Manager Databases
Edit the registry configurations in the
<APIM_1.9.0_HOME>/repository/config/registry.xmland the user database in the
Move all your synapse configurations by copying and replacing
NOTE: Do not replace the
_AuthorizeAPI_.xmlfiles in the
/default/apisub directory unless you use a custom token endpoint. They are application-specific APIs.
the API Manager from 1.8.0 to 1.9.0
- Download the API Manager 1.9.0 from http://wso2.com/products/api-manager.
- Stop all running API Manager server instances. Back
Make sure you backed up all the databases of your API Manager 1.8.0 server instance.Download
and synapse configs as instructed in step 1 of the previous section.
Download WSO2 API Migration Client v1.9.0.
- Extract and find the jar (
- the file you downloaded in the previous step and do the following:
) and copy it into
- Copy the
- Copy the
- file to
- file to
- Copy the
If you are not using the MySQL database with the API Manager, change the query inside
<APIM_1.9.0_HOME>/migration-scripts/18-19-migration/drop-fk.sqlaccording to your database type
. The scripts for each database type are given in the table below:
Database type Script MySQL No changes are required as the default
file already contains sql the scripts for mysql and if you use mysql no need to do the 6th step MySQL.If you are running on H2 change the query in drop-fk.sql to,
SELECT DISTINCT constraint_name FROM information_schema.constraints WHERE table_name = 'AM_APP_KEY_DOMAIN_MAPPING';
ALTER TABLE AM_APP_KEY_DOMAIN_MAPPING DROP CONSTRAINT <temp_key_name>;For Oracle
SELECT DISTINCT constraint_name FROM user_cons_columns WHERE table_name = 'AM_APP_KEY_DOMAIN_MAPPING';
ALTER TABLE AM_APP_KEY_DOMAIN_MAPPING DROP CONSTRAINT <temp_key_name>;For
MS SQL Server Server
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE WHERE TABLE_NAME = 'AM_APP_KEY_DOMAIN_MAPPING' AND COLUMN_NAME='CONSUMER_KEY';
ALTER TABLE AM_APP_KEY_DOMAIN_MAPPING DROP CONSTRAINT <temp_key_name>;For Postgresql
SELECT CONSTRAINT_NAME FROM information_schema.constraint_table_usage WHERE TABLE_NAME = 'AM_APP_KEY_DOMAIN_MAPPING';
ALTER TABLE AM_APP_KEY_DOMAIN_MAPPING DROP CONSTRAINT <temp_key_name>;
Start the API Manager 1.9.0 with the command
-Dmigrate=1.9for database, registry and file system migrations. If you need to perform single resource migrations, you can use the following commands. If you already run
, you do not need to run Please note that if you run
execute the following commands:
- For database migrations run -DmigrateDB=1.9
- For registry migrations run -DmigrateReg=1.9
- For file system migrations run -DmigrateFS=1.9
Tip: Note that running -Dmigrate=1.9, it
migrates all the resources, including the databases, registry and the file system.
To re-index the artifacts in the registry, perform the two steps given below.
a) Rename the lastAccessTimeLocation in the
repository/conf/registry.xmlfile. For example, change the
/_system/local/repository/components/org.wso2.carbon.registry/indexing/lastaccesstimeregistry path to
b) Shut down AM 1.9.0, backup and delete the
repository/conf/solrdirectory and restart the server.
For a cluster
- If you use a cluster/distributed setup, then you need to copy the migration client to particular node and run -DmigrateDB=1.9 to migrate databases, -DmigrateReg=1.9 to migrate registry, -DmigrateFS=1.9 to migrate file system. You only need to copy migration-script folder into the node which hosts your databases