Data migration by virtual instance
How To articles are not official guidelines or officially supported
documentation. They are community-contributed content and may not always
reflect the latest updates to Liferay DXP. We welcome your feedback to
improve How to articles!
While we make every effort to ensure this Knowledge Base is accurate,it
may not always reflect the most recent updates or official guidelines.We
appreciate your understanding and encourage you to reach out with any
feedback or concerns.
Legacy Article
You are viewing an article from our legacy "FastTrack"
publication program, made available for informational purposes. Articles
in this program were published without a requirement for independent
editing or verification and are provided"as is" without
guarantee.
Before using any information from this article, independently verify its
suitability for your situation and project.
Issue
- we'd like to manage a gradual migration from DXP 7.0 to DXP 7.3
- Is it possible to define a database per instance on DXP 7.3?
- Is it possible to migrate data per instance from DXP 7.0 to 7.3 knowing that the data for both environments will evolve in the meantime and that the migrations for each virtual instance will be separated by 2 to 3 months each ?
Resolution
-
These things are not possible.
It is not possible to use a separate database for each virtual instance (in any DXP version, as a matter of fact. Prior to DXP 7.0, it was possible to achieve this through Database Sharding, but this functionality has been deprecated in DXP) So a DXP server can run on only one database, in which there is a logical separation of the virtual instances (by companyId. The table company lists the various virtual instancess), but everything is in the same database, it cannot be separated into multiple databases.
It is also not possible (largely because of the above) to do an upgrade in several "steps, turns", one virtual instance at a time. Because when you start the upgrade script (from the target version's <liferay_home>/tools folder), that script runs on the whole database, it processes all the rows in every table, regardless of the virtual instance (companyId) they belong to. There is no way to separate this.
Did this article resolve your issue ?
