bin/ninja.sh -v export -r -o export.xml
Migration to Native PostgreSQL Repository
Since 4.4
This functionality is available since version 4.4.
|
Overview
Since changes in schema are too large to be handled by SQL update, or you may be switch to PostgreSQL database, you must export and reimport all your data.
In short the migration process should be:
-
Upgrading midPoint to 4.4 using your original SQL configuration
-
Exporting your existing data to file system using Ninja
-
Initializing Native PostgreSQL repository
-
Changing midPoint configuration to use the Native PostgreSQL Repository
-
Importing your existing data to the Native PostgreSQL Repository using Ninja
-
Starting midPoint with the new configuration
-
Audit migration with midPoint already up and running
First point, the upgrade to 4.4 using the same SQL database, is not described here. Please consult Upgrade section of the Relase notes for 4.4.
Exporting your existing data to file
We need to export existing data in raw mode, so they can be later reimported into new native PostgreSQL repository using same tool (Ninja).
In terminal, go to your midPoint installation directory and execute:
See Ninja for more export configuration options and their meaning. |
If you want to migrate the audit tables, you can also export the audit now, but it is possible to migrate audit while the midPoint is already running. Because this makes the critical migration path shorter, we discuss after-the-fact audit migration later in this document.
Initializing & changing configuration for native PostgreSQL repository
See Using Native PostgreSQL Repository for installation and configuration of native PostgreSQL repository.
Be sure to size the new database adequately:
-
Use at least as much filesystem space as previously.
-
Use your DB tools to find out what the database size is, how much is taken by main part of the repository and how much is taken bay audit, especially if you intend to separate them in the new repository.
Please, backup your config.xml , you may need it later, if you will need to
revert changes in order to fix some problems.
|
Do not start midPoint after configuration changes performed in usage documentation. This would create the initial objects and irrelevant audit records that would have to be deleted. |
If you want to migrate your old audit records to the new database and keep event record IDs unique, set the ID sequence in the new database as described in Audit migration from other database. Also, be sure you initialized audit table partitions if you want to use them. |
Importing your existing data to repository
Once export is successful and configuration changes were made, we may proceed with importing data to new native PostgreSQL repository.
In terminal, navigate to your new midPoint installation directory and execute:
bin/ninja.sh -v import -i export.xml
See Ninja for more import configuration options and their meaning |
Starting midPoint
If the import was successful, you are now able to start midPoint using the new repository.
Audit migration
With midPoint up and running you now have time to migrate the old audit records. The process can be done in a single export/import for smaller audit sizes (up to a million of entries), or iteratively for lager audits. It is even possible to drop the imported audit if anything goes wrong and start again - this is especially easy with partitioning.
Check Audit migration from other databases section from Native PostgreSQL Audit Trail document for more details.