- Created by Kirstin Seidel-Gebert, last modified on Jun 12, 2024
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 4 Next »
With future Runtime releases, you will not be able anymore to use the same persistent state database schema for multiple independent services.
Before you update to such a Runtime version, you need to resolve this! We recommend to perform the migration as soon as possible.
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)
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
.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.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 FirstService 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 | FirstService | FirstService | localhost | 1.715.611.721 | 1.715.611.807 |
2 | SecondService | SecondService | 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:
Rework the scripts to fit your setup
At the top of each script, you'll find three variables with sample values: @old_schema
, @new_schema
, @owner_name
. You need to replace the sample values with the actual names according to your setup.
For how to lookup the owner name, refer to The owner concept above.
Script | Content |
---|---|
split_mysql.sql | Script to split a MySQL/MariaDB database |
split_oracle.sql | Script to split an Oracle database |
split_sqlserver.sql | 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.
Task | Table | Script |
---|---|---|
Update persistent state version Set the current persistent state version to the newly created VERSION table. | VERSION | UPDATE <new schema>.VERSION SET MAX_OWNER_ID = (SELECT MAX_OWNER_ID FROM <old schema>.VERSION) |
Copy owner data Copy the owner data of the service in question. | OWNERS | INSERT INTO <new schema>.OWNERS SELECT * FROM <old schema>.OWNERS WHERE OWNER = <your owner name> |
Copy data by owner ID As a reference, we are using the owner id from the OWNERS table we have already copied. | ||
Copy persistent state object data | OBJECT_DATA | INSERT INTO <new schema>.OBJECT_DATA SELECT * FROM <old schema>.OBJECT_DATA WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy externally stored persistent state attributes | EXTERNAL_ATTRIBUTES | INSERT INTO <new schema>.EXTERNAL_ATTRIBUTES SELECT * FROM <old schema>.EXTERNAL_ATTRIBUTES WHERE OBJECT_ID IN (SELECT OBJECT_ID FROM <new schema>.OBJECT_DATA) |
Copy tokens | TOKENS | INSERT INTO <new schema>.TOKENS SELECT * FROM <old schema>.TOKENS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy pending events | EVENTS | INSERT INTO <new schema>.EVENTS SELECT * FROM <old schema>.EVENTS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy object identifiers | OBJECT_IDENTIFIERS | INSERT INTO <new schema>.OBJECT_IDENTIFIERS SELECT * FROM <old schema>.OBJECT_IDENTIFIERS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy history states | HISTORY_STATES | INSERT INTO <new schema>.HISTORY_STATES SELECT * FROM <old schema>.HISTORY_STATES WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy conversation locks | CONVERSATION_LOCKS | INSERT INTO <new schema>.CONVERSATION_LOCKS SELECT * FROM <old schema>.CONVERSATION_LOCKS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
Copy data by owner name Set the owner name manually. | ||
Copy object keys | OBJECT_KEYS | INSERT INTO <new schema>.OBJECT_KEYS SELECT * FROM <old schema>.OBJECT_KEYS WHERE OWNER = <your owner name> |
Copy conversation events | CONVERSATION_EVENTS | INSERT INTO <new schema>.CONVERSATION_EVENTS SELECT * FROM <old schema>.CONVERSATION_EVENTS WHERE OWNER = <your owner name> |
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 | DELETE FROM <old schema>.OBJECT_KEYS WHERE OWNER = <your owner name> |
CONVERSATION_EVENTS | DELETE FROM <old schema>.CONVERSATION_EVENTS WHERE OWNER = <your owner name> |
Delete data by owner ID As a reference, we are using the owner id from the OWNERS table we have already copied. | |
EXTERNAL_ATTRIBUTES | DELETE FROM <old schema>.EXTERNAL_ATTRIBUTES WHERE OBJECT_ID IN (SELECT OBJECT_ID FROM <new schema>.OBJECT_DATA) |
CONVERSATION_LOCKS | DELETE FROM <old schema>.CONVERSATION_LOCKS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
HISTORY_STATES | DELETE FROM <old schema>.HISTORY_STATES WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
| DELETE FROM %OLD_schema%.OBJECT_IDENTIFIERS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
EVENTS | DELETE FROM <old schema>.EVENTS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
TOKENS | DELETE FROM <old schema>.TOKENS WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
OBJECT_DATA | DELETE FROM <old schema>.OBJECT_DATA WHERE OWNER IN (SELECT OWNER_ID FROM <new schema>.OWNERS) |
OWNERS | DELETE FROM <old schema>.OWNERS WHERE OWNER_ID IN (SELECT OWNER_ID FROM <new schema>.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.
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
Reminder
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.
We recommend to test the new setup carefully.
- No labels