Feature Summary and Revision History

Revision History

Feature Description

In CPS 22.2.0 release, Centos version 8.1 is replaced with Alma Linux 8.5 with latest rpm packages.

With Alma Linux 8.5, the kernel version is modified to:

# rpm -qa | grep kernel-[0-9]
kernel-4.18.0-348.7.1.el8_5.x86_64
## cat /etc/redhat-release
AlmaLinux release 8.5 (Arctic Sphynx)
# uname -a

Along with the OS upgrade and Kernel upgrade many of the dependent third party packages are also upgraded.

Feature Summary and Revision History

Feature Description

This release provides support for MongoDB version 4.2.20.

Upgrade, Migrate, and Backward Compatibility Considerations

You can upgrade CPS 22.1.0 (mongoDB version,4.0.27) to CPS 22.2.0 (mongoDB version,4.2.20).

Any CPS version prior to CPS 22.1 such as CPS 21.2 (mongo DB version,3.6.17) and previous versions of CPS, does not support direct upgrade to CPS 22.2 (mongoDB version, 4.2.20).

To upgrade the mongoDB version to the latest 4.2.20 then, you must upgrade the CPS version, which uses mongoDB 4.0.27 version.

Prerequisites for the ISSM Process

The following are the Prerequisites:

• Take a copy of the mongoConfig.cfg file in both old Cluster Managers.

• Update the following values in mongoConfig.cfg file:

  • WT_CACHESIZEGB=12

  • WT_CACHEARBSIZEGB=1

• Execute import_deploy.sh before performing ISSM procedure.

• Make sure that the system is running mongo 3.6 and Java driver patch is applied on the system.

Note

CPS recommends configuring the above values in mongoConfig.cfg before performing fresh install or ISSM. For more information, visit mongoDB Package Components Upgrade. During deployment if you are using custom scripts for deploying the environment then change the scripts to modify the mongoConfig.cfg as needed.

After the prerequisites conditions are met, perform the ISSM process.

Storage Engine Support

To upgrade to MongoDB 4.2 from MongoDB 4.0 deployment that uses MMAPv1, you must upgrade to WiredTiger.

Note	Starting in version 4.2, mongoDB deprecates the MMAPv1 storage Engine and in version 4.2, MongoDB removes the deprecated MMAPv1 storage engine.

MongoDB with WiredTiger supports either XFS or EXT4 filesystems. To avoid performance issues, it is recommended to use XFS file systems for data bearing nodes with the WiredTiger storage engine.

Upgrading Procedure

• Ensure to change the storage engine from MMapV1 to WiredTiger in MongoDB 4.0. For more information see the

• Perform ISSM from 22.1.0 to 22.2.0.

• To migrate to CPS 22.1 release , ISSM from CPS 21.1/21.2 releases is recommended, post following a pre-requisite of applying Mongo Driver Patch.

The prerequisites for upgrading to 22.1.x release are:

• Set the 4.0 replica set to CompatibilityVersion 4.0. To ensure that all members of the replica set have featureCompatibilityVersion set to 4.0, connect to each replica set member and check the featureCompatibilityVersion:

  db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

  All members return a result that includes "featureCompatibilityVersion" : { "version" : "3.6" }.

• To set or update featureCompatibilityVersion, run the following command on the primary. Most of the data-bearing members must be available:

  db.adminCommand( { setFeatureCompatibilityVersion: "4.0" } )

Note	Ensure that no Replica set member is in Rollback or recovering state.

For more information, see the Configuration Parameters - HA System table in the CPS Installation Guide for OpenStack and Modification of Storage Engine before Upgrade.

Memory and Performance Impact

Wired Tiger Storage engine change in MongoDB Server 4.0 requires additional CPU resources of ~15% and additional memory (RAM) resources of ~40% in the Session Manager VMs. Up to ~40% more memory being consumed more by wiredtiger from total memory(RAM) than MMapV1.

For example, if the session manager VM(150GB) with MMapV1 utilizes 60GB then, wiredtiger requires 120GB(MMapV1 usage 60GB + 40% of total memory 150GB).

For more information, see the Configuration Parameters - HA System table in the CPS Installation Guide for OpenStack and Modification of Storage Engine before Upgrade.

Roll back Procedure

Before performing a rollback, restore the copied mongoConfig.cfg file in older Cluster Managers.

Execute the import_deploy.sh before performing ISSM rollback procedure.

Feature Summary and Revision History

Feature Description

This release provides support for MongoDB version 4.2.20.

Upgrade, Migrate, and Backward Compatibility Considerations

• Supported DRA Releases for upgrading to 4.2: You can upgrade vDRA 22.1.1 (mongoDB version,4.0.27 WT storage engine) to vDRA 22.2.0 (mongoDB version,4.2.20 WT storage engine).

• Un Supported DRA Releases for upgrading to 4.2: Any DRA version prior to CPS 22.1.1 such as DRA 22.1 (mongo 4.0.27 MMAP storage engine), 21.2 (mongo 3.6.9 MMAP storage engine) or DRA 19.4/18.2 (mongo 3.4.5 MMAP storage engine), and previous versions of DRA, does not support direct upgrade to DRA 22.2 (mongoDB version, 4.2.20)

  Note	Upgrading to DRA 22.2 is supported only from DRA 22.1.1 MR.

Prerequisite for upgrading to 22.2 from 22.1.1 MR and rollback from 22.2 to 22.1.1 MR

The following are the common prerequisites for upgrade and roll back:

• Run the following CLI before upgrade:

  #database fcvcheck4

  Note	Make sure to run the above CLI before upgrade and / or downgrade on all sites.

• Specify any one of the CLI options:

  • Set: This option checks and sets FCV only on primary.

    Note

    We recommend to use Set option first and then Check to make sure that FCV is replicated on secondary members. Upgrade/downgrade should not be triggered if any error is found in above CLI or FCV is not replicated on secondary members. Make sure to resolve the CLI error, rerun the CLI, and then only proceed for upgrade or downgrade.

  • Check: This option only checks FCV on all members (primary, secondary, and arbiter).

Upgrade to 22.2.0

1. Run the prerequisite steps.

2. Follow the standard documented procedure for upgrade.

Downgrade from 22.2.0

1. Run the steps mentioned in the prerequisite section.

2. Follow the standard documented procedure for downgrade.

Feature Summary and Revision History

Feature Description

In CPS 22.2.0 and later releases, the python is upgraded to the latest 3.9.6 stable version.

Configuration and Restrictions

To perform ISSM, ensure to follow the steps to perfom Cluster Manager backup:

• Mount the existing ISO of your current CPS and run the backup cluman step specified in the Migrate the Cluster Manager VM section in the CPS Migration and Upgrade Guide. For example, if you are migrating to 22.2.0 from 22.1.0 then, mount the 22.1 ISO for taking Cluster Manager backup operations.

• During the ISSM rollback, at the time of migration from x.iso to y.iso and and at the time of mounting y.iso for rollback procedure, ensure to use Python2 (22.1) ISO.