The dbmigration tool allows you to migrate system objects, data records and deployed objects (except Jobs and workflows) between relational databases.
Make sure that both MDM servers are up and running.
If you need to migrate between two databases on a single machine, you must run the two MDM servers side by side. You can do this by setting a different port binding on the target server.
For further information about running multiple instances of Tomcat on the same machine, see the Talend Installation Guide.
The migration of UpdateReport records to the target MDM server may lead to unexpected results. For example, some eligible triggers are triggered, or processes or Jobs are executed. To avoid this issue, before the migration, you need to disable the Event Manager on the target MDM server by configuring
subscription.engine.autostart=falsein the file <$INSTALLDIR>/conf/mdm.conf, where <$INSTALLDIR> specifies the MDM server installation directory. You need to re-enable it and when the migration is completed. Make sure to restart the MDM server for the configuration to take effect.
In the target MDM server, browse to:
Save a copy of the dbmigration.properties.template file giving it the name dbmigration.properties, for example.
Open the new dbmigration.properties file using a text editor.
In the "from" list, set the connection information to the source server.
In the "to" list, set the connection information to the target server.
If you want to migrate from 5.X, one configuration example is given below:
####from 5.X using EJBs#### from.host=localhost from.user=admin from.password=talend from.jndi.port=1199 to.url=http://192.168.32.191:8280/talendmdm to.home=D:\\Talend\Talend-MDMServer to.user=administrator to.password=administrator to.cluster.batch.size=500
If you want to migrate from 6.X, one configuration example is given below:
####from 6.X using REST#### from.url=http://localhost:8180/talendmdm from.user=administrator from.password=administrator to.url=http://192.168.32.191:8280/talendmdm to.home=D:\\Talend\Talend-MDMServer to.user=administrator to.password=administrator to.cluster.batch.size=500
If the data containers and data models in your source server do not have the same names (for example, if the ProductDemo data container uses the Product data model), you must also use the following syntax in the dbmigration.properties file to specify how they are connected:
For entities that have Foreign Keys to themselves (for example, Person might have a FK relation 'is child of' to Person), the migration process does not ensure the correct insertion order. As a result, the validation of such records may fail even though data integrity is correct. To avoid this, it is recommended that you deploy the data model to the target MDM server first and then temporarily disable FK integrity checks for the FK field in the data model editor.
If needed, modify the number of migration threads specified by the parameter
The default value of this parameter is 8.
Run the appropriate dbmigration file for your system (dbmigration.bat for Windows and dbmigration.sh for Linux).
Give the CommandLine the file name you set as a parameter, as follows:
If needed, you can add parameters to the CommandLine when running the dbmigration script for your system.
Add the parameter...
Do the migration in an interactive mode.
For example, you will be prompted which data model needs to be migrated. Enter Y to select the data model you want to migrate, or enter N to skip the data model you do not want to migrate.
Perform only the validation of user-defined data models.
You will be prompted if a data model has any entity that refers to itself, or has circular dependencies between entities such as EntityA references EntityB, EntityB references EntityC, and EntityC references EntityA.
Restart the target server in order to complete the migration process.
If the source and target servers are running on the same machine and using different port bindings, stop the source server and then launch the target server on the desired port.
This will migrate the MDM instances stored in databases from the source server to the target server in line with the connection information defined in the file.
The activity of the dbmigration tool can be logged using the log4j feature.
If needed, you can change the log4j configuration information in the file <$INSTALLDIR>/tools/dbmigration/log4j.properties. For more information on the log4j logging levels, see the Apache documentation at http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html.
An example of the file log4j.properties is shown below:
log4j.rootCategory=INFO,CONSOLE,FILE log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%p [%c] - %m%n log4j.appender.FILE=org.apache.log4j.RollingFileAppender log4j.appender.FILE.File=dbmigration.log log4j.appender.FILE.layout=org.apache.log4j.PatternLayout log4j.appender.FILE.layout.ConversionPattern=%d %p [%c] - %m%n
By default, the log information is stored in the file <$INSTALLDIR>/tools/dbmigration/dbmigration.log.
When you migrate MDM instances using the dbmigration tool, you can check the log information in the file dbmigration.log to troubleshoot migration issues.
The following is an example of an error message in the file dbmigration.log:
2015-12-16 18:25:36,486 ERROR [org.talend.mdm.db.migration.rest.RESTXmlServer] - Unable to commit on 'Product' (total 2 records, some of them rollbacked)
Additionally, you can check the file <$INSTALLDIR>/logs/mdm.log on the source MDM server and target MDM server respectively to learn more information about the execution results of the dbmigration tool.