Understanding Transactional Consistent Replication (TRC)

Why Transactional Consistency is Important

Transactional consistency refers to the state of coherent data in the system. While data itself can be technically stored in the database without errors, its semantic meaning like dependencies and relations to other data might be broken. In that case, the data is not consistent. To ensure, that data is consistent all the time, Software Update Manager uses the concept of Transactional Consistent Replication (TCR).

Uptime data conversion happens parallel to end user activity.
Uptime data conversion requires to work on consistent data.
Transactional Consistent Replication (TCR) ensures data consistency.
TCR requires sufficient kernel level.

This image shows the main activity blocks during downtime-optimized conversion. It highlights the point in time in which consistent data are required and shows that this is achieved using TCR during data transfer.

The uptime data conversion has to work on consistent data. This is different to uptime migration where data are simply migrated, and their context is not relevant. If simply all currently existing table entries were transferred, the target state (prior to uptime data conversion) would be inconsistent. The reason is that the tables are not transferred all at the same point in time, so during the overall time of transfer, some tables may already have received new content due to end user activities.

TCR as solution

The solution is based on Transactional Consistent Replication (TCR). TCR is based on a kernel hook feature that is available with a specific kernel patch level. The hook allows you to execute statements for the event of database commit (or rollback). With this, it is possible to define a specific consistent state of database tables, and return to this state prior to the data conversion.

The approach is based on database triggers that are created by Software Update Manager on database level. At a specific point in time T0, the triggers are set, and all subsequent changes are recorded in trigger log tables. In addition and based on the TCR kernel hook, all subsequent database commits are noted with the commit ID and a transaction ID in a snap table.

Shortly before the initial transfer starts, the latest transaction commit level is used as a reference, as a snapshot. After the Initial Replication and before the uptime data conversion starts, the Revert2Snapshot step reverts the transferred data to this snapshot level. The table changes created later than the snapshot (which are discarded with the revert) are not lost, as they are considered later during the delta replication.

TCR requires specific kernel version levels.

More information on the concept of triggers and snapshots are part of a later lesson.

In addition, a short-term lock of Asset Accounting is triggered by Software Update Manager after the triggers were activated. During this lock, manual activities are required on Asset Accounting. The required activities are described in the guide for downtime-optimized conversion, and on respective Software Update Manager dialogs as well.

Note

TCR triggers are comparably "expensive" as they introduce remarkable load on the database server. Therefore, TCR might lead to performance issues (on production system). An alternative approach is based on cloning the whole database using online backup and restore to a different host as a online backup is always transactional consistent. This clone can then be used as source for the initial data migration. At the finalization date of this course, the clone-based approach was not yet generally available. Please refer to the latest version of the downtime-optimized conversion guide for availability of the approach.

Check TCR Requirements

In the following exercise, you will discover whether the prerequisites for TCR are met.

ExerciseStart Exercise

Move through Lock of Asset Accounting

In the following exercise, you will learn how the dialogs for the short-term lock of Asset Accounting look like.