Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Note |
---|
June, 2024: With future Runtime releases, you will not be able anymore to use the same persistent state database schema for multiple independent services. |
Currently it is technically possible (though not recommended) to share one persistent state database schema between different independent services. With future Runtime releases, this will not be allowed anymore.
This means that you need to rework services that share the same persistent state database schema. This article describes what you need to do.
What this is about
You have set up a persistent state database schema of which the database tables contain data of multiple (2 or more) independent services.
As this is not allowed anymore, you need to
- create dedicated database schemes for every single service
- move (first copy, then delete) the data from the shared database to the dedicated database
You can keep one of the services in the original database.
To do this, follow the procedure described below.
Step 1: Stop the affected services
Stop all services that are affected by this rework.
Step 2: Create a database backup
Before starting with this migration, we strongly recommend to do a database backup. This way you can rollback your changes if anything goes wrong during the migration.
Step 3: Create a new database schema for every service
For each service you need to create a separate database schema. This is done by database commands that depend on the database system you are using. It may be e.g. something like
CREATE SCHEMA <name of new schema>
(Oracle)
orCREATE DATABASE <name of new database>
(SQL Server)
Info |
---|
Keep in mind, to also assign the needed database users that the services you are going to migrate use to connect to the database. They need read and write access to this new schema! |
Next, you need to create all necessary persistent state tables to the database scheme. To help you with that, the Runtime comes with scripts for every supported database (MySQL/MariaDB, Oracle and SQL Server).
Go to your Runtime directory, to
<path to Runtime directory>/<your OS>/resource/sql/<your DB system>/pstate
.Info If you are using an older Runtime (before Runtime 2023.1), these scripts reside in
<path to Runtime directory>/<your OS>
.Find the script
CreateSchema.sql
for your database.Tip The MySQL script also fits for MariaDB.
Run this script for each newly created schema to create persistent state tables.
Step 4: Copy the data
Copy the data of each service to the corresponding database schema. To help you with that task, we have prepared some scripts, or you can execute the steps manually.
The owner concept
To perform the next steps, you need to be familiar with the owner concept of the PAS persistent state implementation.
- Services are owners of persistent state objects.
- You need to know the owner to distinguish the persistent state data.
- The owner name is the service name as per default.
The owner name can be changed in the service configuration/settings:
Configuration Section Key
Name Value Persistent State Persistent State: Owner: AL_PS_OWNER Service_2 Tip For more information on how to access the service configuration, refer to Adapting the Configuration of Containerized xUML Services for the PAS Administration, and to Adapting Integration Service Configuration for the Integration/Bridge.
This is why owner names are coded into owner IDs in a dedicated table OWNERS
, e.g.
OWNER_ID | OWNER | COMPOSITE | HOST | START_TS | STOP_TS |
---|---|---|---|---|---|
1 | Service_1 | Service_1 | localhost | 1.715.611.721 | 1.715.611.807 |
2 | Service_2 | Service_2 | localhost | 1.715.611.815 | 1.715.611.875 |
Database items like persistent state object data is coded to the owner ID, some other items are coded to the owner name. Keep this in mind when doing the migration manually - the migration scripts (see below) already cover that.
Use the scripts
The following scripts are available:
Note | ||
---|---|---|
| ||
At the top of each script, you'll find three variables with sample values: For how to lookup the owner name, refer to The owner concept above. |
Script | Content |
---|---|
Script to split a MySQL/MariaDB database | |
Script to split an Oracle database | |
Script to split an SQLServer database |
Split the data manually
For each service, copy the related data from the old to the new database schema. To identify the data, refer to the owner name or owner ID.
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Step 5: Delete the copied data
After having copied the data - either by script, or manually - you need to delete the data from the old database schema. To identify the data, refer to the owner name or owner ID.
Table | Script | |||||
---|---|---|---|---|---|---|
Delete data by owner name Set the owner name manually. | ||||||
OBJECT_KEYS |
| |||||
CONVERSATION_EVENTS |
| |||||
Delete data by owner ID As a reference, we are using the owner id from the OWNERS table we have already copied. | ||||||
EXTERNAL_ATTRIBUTES |
| |||||
CONVERSATION_LOCKS |
| |||||
HISTORY_STATES |
| |||||
|
| |||||
EVENTS |
| |||||
TOKENS |
| |||||
OBJECT_DATA |
| |||||
OWNERS |
|
Step 6: Change the service configuration
After the data migration, you need to update the service configuration (settings) of the migrated services. You need to update the configured database to the new one the data has been migrated to.
You can do this in the PAS Administration or on the Integration Component (Bridge), or you can change the definitions in your MagicDraw model and redeploy it.
Tip |
---|
For more information on how to access the service configuration, refer to Adapting the Configuration of Containerized xUML Services for the PAS Administration, and to Adapting Integration Service Configuration for the Integration/Bridge. |
PAS Administration |
|
---|---|
PAS Integration Component |
|
MagicDraw |
|
Step 7: Restart the services
Info | ||
---|---|---|
| ||
Have you already assigned the needed database users that the migrated services use to connect to the database? They need read and write access! |
Now you can restart the migrated services.
Info |
---|
We recommend to test the new setup carefully. |
Panel | ||
---|---|---|
| ||
|
Panel | ||
---|---|---|
| ||