Rolling Back UDR

5.1 Supported Rollback Paths

The following table lists the supported rollback paths for UDR:

Table 5-1 Supported Rollback Paths

Source Release	Target Release
24.3.0	24.2.x
24.3.0	24.1.x

To rollback to the previous UDR version, run the following command to check if the pods have successfully started (shows running state).

kubectl get pods -n <namespace_name>

Where, <namespace_name> is the UDR namespace name. For example, ocudr.

If the pod logs or describe pods command results are not sufficient to handle the issue, then rollback using Helm and proceed with Rollback DB Schema instructions.

5.2 Rollback Tasks

Run the following command to check if the pods are successfully started:

kubectl get pods -n <namespace_name>

Note:

You have to rollback if there are issues that cannot be recovered by checking the logs. You must perform a helm rollback first and then proceed with rollback database schema instructions.

Use the backup of the 24.2.x version's <ocudr-values.yaml> file to roll back from UDR 24.3.0 to a previous version:

Run the following command to obtain the revision number:
```
helm history <helm release name>
```
Example: helm history ocudr
Run the following rollback command.

Note:
For multisite deployments, run the rollback command for all sites.
```
helm rollback <helm release name> <revision_no>
```
Where, <helm release_name> is the release name used by the Helm command.

<revision_no> is the release number to which UDR needs to be rolled back.

Example: helm rollback ocudr 1

Run the following command when you upgrade from 24.1.x or 24.2.x to 24.3.0 and then rollback to 24.1.x or 24.2.x:

Login to mysql, "kubectl exec <dataNodes> -n <namespace> -it bash"
Login to mysql password: mysql -h 127.0.0.1 -uroot -pNextGenCne
use <udrdb-name>;
Example: use udrdb;
    delete from ReleaseConfig where SiteId=<siteId> and CfgKey=ocudr;

Rollback of Multiple Site Deployments

You must follow a specific order during rollback of multiple site deployment. You must rollback all cnDBTier sites and then rollback UDR across all sites. For example, in a three site setup you must follow the below order for NF and cnDBTier rollback:

Rollback site 1 cnDBTier
Rollback site 2 cnDBTier
Rollback site 3 cnDBTier
Rollback Site 1 UDR, Provisioning Gateway, CNC Console, and reinstall the rollback version of the tools (subscriber bulk import and subscriber export tool) deployments if present.
Rollback Site 2 UDR, Provisioning Gateway, CNC Console, and reinstall the rollback version of the tools (subscriber bulk import and subscriber export tool) deployments if present.
Rollback Site 3 UDR, Provisioning Gateway, CNC Console, and reinstall the rollback version of the tools (subscriber bulk import and subscriber export tool) deployments if present.

The above rollback order is required because of the SQL rollback limitation applicable for cnDBTier:

If there are schema changes on any of the tables when running on the higher n+1 release version of cnDBTier, then when you rollback the NF to "n" version of cnDBtier, the schema changes which happened on the higher n+1 version will not be handled and the tables with these changes are dropped and are not re-created on the lower version. For more information, see the Prerequisites section in the Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
Rollback of cnDBTier must be performed carefully as per the above specified order because UDR, Provisioning Gateway, and Tools (subscriber bulk import and subscriber export tool) upgrade and rollback procedure includes database schema change.
There must not be database schema change in the current cnDBTier version to rollback. If there is any database schema change after cnDBtier is upgraded, then these schema changes must be reverted. You must contact My Oracle Support for assistance.

Note:

You must disable the conflict resolution feature during rollback. For more information, see "Conflict Resolution" section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide. You must perform the schema changes before upgrading UDR components and cnDBTier. Schema changes performed during upgrade can be retained since the changes do not impact when you rollback the UDR version.
During the upgrade procedure if there is an issue on UDR, Provisioning Gateway, or Tools in any sites, then UDR, Provisioning Gateway, or Tools must be rolled back immediately. Do not rollback cnDBTier. cnDBTier must be rolled back only if there is a cnDBTier upgrade issues.
Verify the cnDBTier after the upgrade is complete. If there are issues, rollback the cnDBTier immediately. Do not rollback UDR, Provisioning Gateway, or Tools, they can remain on the higher version and are compatible with n-1 cnDBTier release.
To avoid failures during cnDBTier rollback due to schema changes (for example, helm upgrade, rollback performed on UDR, Provisioning Gateway, and subscriber bulk import and subscriber export tool deployments), you can drop the modified schema tables manually before rollback and re-create the modified schema tables after the rollback is complete. For more information, see the Prerequisites section in the Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide and contact My Oracle Support for assistance.

If the rollback fails, see the Debugging Upgrade or Rollback Failure section in the Oracle Communications Cloud Native Core, Unified Data Repository Troubleshooting Guide.

5.3 Postrollback Tasks

After performing rollback, restore preupgrade data obtained earlier through manual backup.

GET API for different resources can be used to see current values in UDR, then accordingly if any update required, individual service APIs defined for different resources can be used to reconfigure the data backup taken before upgrade. See Oracle Communications Cloud Native Core, Unified Data Repository REST Specification Guide for API details.

5 Rolling Back UDR

5.1 Supported Rollback Paths

5.2 Rollback Tasks

5.3 Postrollback Tasks