Upgrading cnDBTier

4.1 Supported Upgrade Paths

The following table provides the upgrade paths that are supported by cnDBTier Release 25.1.201.

Table 4-1 Supported Upgrade Paths

Source Release	Target Release
25.1.2xx	25.1.201
25.1.1xx	25.1.201
24.3.x	25.1.201
24.2.x	25.1.201

4.2 Upgrading cnDBTier from Non-TLS to TLS Enabled Version (Replication)

This section describes the procedure to upgrade cnDBTier clusters from a version where TLS is not enabled for replication to a version where TLS is enabled for replication.

Note:

Upgrading non-TLS to TLS enabled version is a disruptive procedure that may temporarily impact Geo-replication in the CNE environment. The LoadBalancer service must be recreated for TLS and non-TLS ports to be published. This requires deleting and recreating the db-replication-svc service.
The namespace occne-cndbtier is given in this procedure is given only as an example. You must configure the name according to your environment.
In this procedure, the cnDBTier sites are upgraded twice (in step 4 and step 7). Ensure that you follow this procedure as-is to upgrade from a non-TLS version to a TLS enabled version.

Create the necessary secrets in all the cnDBTier sites by following step 7 of the Creating Secrets procedure.
Ensure that TLS is enabled in the custom_values.yaml file for all cnDBTier sites:
```
global:
  tls:    
    enable: true
```

Provide all the necessary certificates such as CA certificate, client certificate, and server certificate for the respective ndbmysqld pods in custom_values.yaml file for all cnDBTier sites:

Note:

Set the TLS mode to NONE for all the cnDBTier sites as seen in the following custom_values.yaml file.

tls:
  enable: true
  caCertificate: "<ca certificate file name>"
  tlsversion: "TLSv1.3"
  tlsMode: "NONE"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    - name: ndbmysqld-1
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    ...

For example:

tls:
  enable: true
  caCertificate: "combine-ca.pem"
  tlsversion: "TLSv1.3"
  tlsMode: "NONE"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    - name: ndbmysqld-1
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    ...

Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.

After upgrading each site, run the following command on the site to ensure that the replication is UP:

$ kubectl -n <namespace> exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.<namespace>:8080/db-tier/status/replication/realtime

where, <namespace> is the namespace name of the of cnDBTier cluster.

The value of replicationStatus in the output indicates if the local site is able to replicate data from that remote site:

"UP": Indicates that the local site is able to replicate data from that remote site.
"DOWN": Indicates that the local site is not able to replicate data from the respective remote site.

For example, run the following command to check the georeplication status of cnDBTier cluster2 configured with other remote sites:

$ kubectl -n cluster2 exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.cluster2:8080/db-tier/status/replication/realtime

Sample output:

[
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster1",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  },
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster3",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  },
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster4",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  }
]

In the sample output, the replicationStatus is "UP" for the localSiteName cluster2 for remotesiteName cluster1, cluster3, and cluster4. This indicates that the localSiteName cluster2 is able to replicate data from remotesiteName cluster1, cluster3, and cluster4.

In the custom_values.yaml file, set tlsMode to VERIFY_CA or VERIFY_IDENTITY, depending on your requirement, for all the cnDBTier sites. This configuration ensures that the clients use an encrypted connection and performs verification against the server CA certificate:

VERIFY_CA instructs the client to check if the server’s certificate is valid.
VERIFY_IDENTITY instructs the client to check if the server’s certificate is valid and to check if the host name used by the client, matches the identity in the server’s certificate.

tls:
  enable: true
  caCertificate: "<ca certificate file name>"
  tlsversion: "TLSv1.3"
  tlsMode: "VERIFY_CA/VERIFY_IDENTITY"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    - name: ndbmysqld-1
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    ...

For example:

tls:
  enable: true
  caCertificate: "combine-ca.pem"
  tlsversion: "TLSv1.3"
  tlsMode: "VERIFY_CA"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    - name: ndbmysqld-1
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    ...

Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous step.
After upgrading each site, run the following command on the site to ensure that the replication is UP:
```
$ kubectl -n <namespace> exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.<namespace>:8080/db-tier/status/replication/realtime
```
Where, <namespace> is the namespace name of the of cnDBTier cluster.
The value of replicationStatus in the output indicates if the local site is able to replicate data from that remote site:
- "UP": Indicates that the local site is able to replicate data from that remote site.
- "DOWN": Indicates that the local site is not able to replicate data from the respective remote site.
For example, see Step 7.

Run the hooks.sh script with the --add-ssltype flag on all cnDBTier sites to set the type of "occnerepluser" as TLS:

Note:

Update the values of the environment variables in the following code block as per your cluster.

export OCCNE_NAMESPACE="occne-cndbtier"
export MYSQL_CONNECTIVITY_SERVICE="mysql-connectivity-service"
export MYSQL_USERNAME="occneuser"
export MYSQL_PASSWORD="<password for the user occneuser>"
export OCCNE_REPL_USER_NAME="occnerepluser"
export MYSQL_CMD="kubectl -n <namespace> exec <ndbmysqld-0 pod name> -- mysql --binary-as-hex=0 --show-warnings"
  
occndbtier/files/hooks.sh --add-ssltype

4.3 Upgrading cnDBTier from TLS Enabled to Non-TLS Version (Replication)

This section describes the procedure to upgrade cnDBTier clusters from a version where TLS is enabled for replication to a version where TLS is not enabled for replication.

Note:

Upgrading TLS to non-TLS enabled version is a disruptive procedure that may temporarily impact Geo-replication in the CNE environment. The LoadBalancer service must be recreated for TLS and non-TLS ports to be published. This requires deleting and recreating the db-replication-svc service.
The namespace occne-cndbtier is given in this procedure is given only as an example. You must configure the name according to your environment.
In this procedure, the cnDBTier sites are upgraded twice (in step 3 and step 6). Ensure that you follow this procedure as-is to upgrade from a TLS enabled version to a non-TLS version.

Run the hooks.sh script with the -- remove-ssltype flag on all cnDBTier sites to set the type of "occnerepluser" as Non-TLS:

Note:
Update the values of the environment variables in the following code block as per your cluster.
```
export OCCNE_NAMESPACE="occne-cndbtier"
export MYSQL_CONNECTIVITY_SERVICE="mysql-connectivity-service"
export MYSQL_USERNAME="occneuser"
export MYSQL_PASSWORD="<password for the user occneuser>"
export OCCNE_REPL_USER_NAME="occnerepluser"
export MYSQL_CMD="kubectl -n <namespace> exec <ndbmysqld-0 pod name> -- mysql --binary-as-hex=0 --show-warnings"
  
occndbtier/files/hooks.sh --remove-ssltype
```

In the custom_values.yaml file, set tlsMode to NONE for all the cnDBTier sites:

tls:
  enable: true
  caCertificate: "<ca certificate file name>"
  tlsversion: "TLSv1.3"
  tlsMode: "NONE"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    - name: ndbmysqld-1
      serverCertificate: "<server certificate name>"
      serverCertificateKey: "<server key name>"     
      clientCertificate: "<client certificate name>"
      clientCertificateKey: "<client key name>"
    ...

For example:

tls:
  enable: true
  caCertificate: "combine-ca.pem"
  tlsversion: "TLSv1.3"
  tlsMode: "NONE"
  ciphers:
    - TLS_AES_128_GCM_SHA256
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_CCM_SHA256
  certificates:
    - name: ndbmysqld-0
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    - name: ndbmysqld-1
      serverCertificate: "server1-cert.pem"
      serverCertificateKey: "server1-key.pem"     
      clientCertificate: "client1-cert.pem"
      clientCertificateKey: "client1-key.pem"
    ...

Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.

After upgrading each site, run the following command on the site to ensure that the replication is UP:

$ kubectl -n <namespace> exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.<namespace>:8080/db-tier/status/replication/realtime

where, <namespace> is the namespace name of the of cnDBTier cluster.

The value of replicationStatus in the output indicates if the local site is able to replicate data from that remote site:

"UP": Indicates that the local site is able to replicate data from that remote site.
"DOWN": Indicates that the local site is not able to replicate data from the respective remote site.

For example, run the following command to check the georeplication status of cnDBTier cluster2 configured with other remote sites:

$ kubectl -n cluster2 exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.cluster2:8080/db-tier/status/replication/realtime

Sample output:

[
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster1",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  },
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster3",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  },
  {
    "localSiteName": "cluster2",
    "remoteSiteName": "cluster4",
    "replicationStatus": "UP",
    "secondsBehindRemote": 0,
    "replicationGroupDelay": [
      {
        "replchannel_group_id": "1",
        "secondsBehindRemote": 0
      }
    ]
  }
]

In the sample output, the replicationStatus is "UP" for the localSiteName cluster2 for remotesiteName cluster1, cluster3, and cluster4. This indicates that the localSiteName cluster2 is able to replicate data from remotesiteName cluster1, cluster3, and cluster4.

Ensure that TLS is disabled in the custom_values.yaml file for all cnDBTier sites:
```
global:
  tls:    
    enable: false
```
Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous step.
After upgrading each site, run the following command on the site to ensure that the replication is UP:
```
$ kubectl -n <namespace> exec -it ndbmysqld-0 -- curl http://mysql-cluster-db-monitor-svc.<namespace>:8080/db-tier/status/replication/realtime
```
where, <namespace> is the namespace name of the of cnDBTier cluster.
The value of replicationStatus in the output indicates if the local site is able to replicate data from that remote site:
- "UP": Indicates that the local site is able to replicate data from that remote site.
- "DOWN": Indicates that the local site is not able to replicate data from the respective remote site.
For example, see Step 4.

4.4 Upgrading cnDBTier from Non-TLS to TLS Enabled Version (NF Communication)

This section describes the procedure to upgrade cnDBTier clusters from a version where TLS is not enabled in application SQL pods for NF communication to a version where TLS is enabled in application SQL pods for NF communication.

Note:

The namespace name "occne-cndbtier" given in this procedure is only an example. Ensure that you configure the namespace name according to your environment.

Create the necessary secrets in all the cnDBTier sites by following step 8 of the Creating Secrets procedure.
Ensure that /global/ndbappTLS/enable is set to true in the custom_values.yaml file for all cnDBTier sites. This indicates that TLS is enabled in application SQL pods for NF communication:
```
global:
  ndbappTLS:    
    enable: true
```

Provide the necessary certificates by configuring the caCertificate, serverCertificate, and serverCertificateKey parameters in custom_values.yaml file for the respective application SQL pods of all cnDBTier sites:

ndbappTLS:
  enable: true
  caSecret: cndbtier-ndbapp-trust-store-secret
  serverSecret: cndbtier-ndbapp-server-secret
  tlsversion: "TLSv1.3"
  caCertificate: "<caCertificate file name>"
  serverCertificate: "<serverCertificate file name>"
  serverCertificateKey: "<serverCertificateKey file name>"

where,

<caCertificate name>, is the name of the file containing the CA certificate.
<serverCertificate name>, is the name of the file containing the server certificate.
<serverCertificateKey name>, is the name of the file containing the server certificate key.

For example:

ndbappTLS:
  enable: true
  caSecret: cndbtier-ndbapp-trust-store-secret
  serverSecret: cndbtier-ndbapp-server-secret
  tlsversion: "TLSv1.3"
  caCertificate: "combine-ca.pem"
  serverCertificate: "server1-cert.pem"
  serverCertificateKey: "server1-key.pem"

Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.
At this stage, cnDBTier is upgraded and the application SQL pod is configured with TLS certificates. However, the application SQL pod still allows non-TLS communication. To restrict the communication, you must set the mode of the user to X509 such that any NF using the user follows TLS strictly. When the NF user is created, perform the following steps to set the mode of the NF user to X509.

Note:
Before performing this step ensure that the NF is ready to communicate with cnDBTier using TLS.
1. Log in to the ndbappmysqld pod. Enter the password when prompted.
```
$ kubectl -n  <namespace of cnDBTier Cluster> exec -it ndbappmysqld-0 -- mysql -h 127.0.0.1 -uroot -p
```
  Example:
```
$ kubectl -n cluster1 exec -it ndbappmysqld-0 -- mysql -h 127.0.0.1 -uroot -p
```
  Sample output:
```
Enter Password:
```
2. Run the following command to check for NF-specific user account. If there are no NF-specific user accounts, create new user accounts:
```
$ mysql> select user, host  from mysql.user;
```
  Example:
```
+------------------+-----------+
| user             | host      |
+------------------+-----------+
| occnerepluser    | %         |
| occneuser        | %         |
| healthchecker    | localhost |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
| nfuser           | %         |
+------------------+-----------+
7 rows in set (0.00 sec)
```
3. Before altering the user and granting privilege, run the following command to turn off binlogging on one of the ndbappmysqld pods:
```
$ mysql>SET sql_log_bin = OFF;
```
4. Run the following the commands to alter the user and grant the privileges:
```
$ mysql> ALTER USER '<USERNAME>'@'%' REQUIRE X509;   
$ mysql> FLUSH PRIVILEGES;
```
5. Turn on the binlogging on the same ndbappmysqld pod before you exit from the session:
```
mysql>SET sql_log_bin = ON;
```
6. Exit the session:
```
$ mysql> exit;
```

4.5 Upgrading cnDBTier from TLS Enabled to Non-TLS Version (NF Communication)

This section describes the procedure to upgrade cnDBTier clusters from a version where TLS is enabled in application SQL pods for NF communication to a version where TLS is not enabled in application SQL pods for NF communication.

Note:

The namespace name "occne-cndbtier" given in this procedure is only an example. Ensure that you configure the namespace name according to your environment.

Perform the following steps to set the NF user to NONE such that the application SQL pods of cnDBTier accepts both TLS and non-TLS communication from the NF that uses the NF user:

Log in to the ndbappmysqld pod. Enter the password when prompted.

$ kubectl -n  <namespace of cnDBTier Cluster> exec -it ndbappmysqld-0 -- mysql -h 127.0.0.1 -uroot -p

Example:

$ kubectl -n cluster1 exec -it ndbappmysqld-0 -- mysql -h 127.0.0.1 -uroot -p

Sample output:

Enter Password:

Run the following command to check for NF-specific user account:

$ mysql> select user, host  from mysql.user;

Example:

+------------------+-----------+
| user             | host      |
+------------------+-----------+
| occnerepluser    | %         |
| occneuser        | %         |
| healthchecker    | localhost |
| mysql.infoschema | localhost |
| mysql.session    | localhost |
| mysql.sys        | localhost |
| root             | localhost |
| nfuser           | %         |
+------------------+-----------+
7 rows in set (0.00 sec)

Before altering the user privilege, run the following command to turn off binlogging on one of the ndbappmysqld pods:
```
$ mysql>SET sql_log_bin = OFF;
```

Run the following the commands to alter the user privilege to NONE:

$ mysql> ALTER USER '<USERNAME>'@'%' REQUIRE NONE;   
$ mysql> FLUSH PRIVILEGES;

Turn on the binlogging on the same ndbappmysqld pod before you exit from the session:
```
mysql>SET sql_log_bin = ON;
```
Exit the session:
```
$ mysql> exit;
```

Make the NF flexible enough to communicate with cnDBTier using TLS. However, when cnDBTier is upgraded to a non-TLS version, the NF must use non-TLS communication.
Ensure that /global/ndbappTLS/enable is set to false in the custom_values.yaml file for all cnDBTier sites. This indicates that TLS is disabled in application SQL pods for NF communication:
```
global:
  ndbappTLS:    
    enable: false
```
Perform the Upgrading cnDBTier Clusters procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous step.

4.6 Upgrading cnDBTier HTTPS Disabled to HTTPS Enabled Version

This section describes the procedure to upgrade cnDBTier HTTPS disabled version to HTTPS enabled version.

Note:

While enabling dual protocol, do not assign the same port for both service.httpport and service.httpsport.
For more information about local site and remote site port configuration parameters, see Global Parameters section.
When upgrading from previous version to current version, ensure the value of the service.httpPort parameter is same as the value of the service.port parameter from the earlier version.

Perform the following steps to enable HTTPS:

Create all the necessary secrets in the cnDBTier site by following the step 7 of the Creating Secrets procedure.
Enable the dual protocol by setting the supportDualProtocol parameter to true in the custom_values.yaml file for all the cnDBTier sites:
Sample:
```
global:
  https:
    enable: false
    supportDualProtocol: true
```
Perform the Upgrading cnDBTier procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.
Result: cnDBTier has been upgraded with the dual-protocol support. This allows both HTTP and HTTPS on the specified service.httpport to be used.

Note:
After this step, only HTTPS protocol is used for the REST APIs across the cnDBTier sites.
Enable https as shown below in custom_values.yaml file for all the cnDBTier sites.
Note:
If HTTPS is enabled, then update the following ports in the cnDBTier site where HTTPS is configured. For more information, see the Customizing cnDBTier section.
- local site port to service.httpsport
- remote site port to service.httpsport
To enable HTTPS, configure the https parameter to true in the custom_values.yaml file as shown below:
```
https:
  enable: true
  supportDualProtocol: true
```
Upgrade the cnDBTier sites one by one with the updated custom_values.yaml file. Follow the upgrade procedure as per the Upgrading cnDBTier section.
Result: cnDBTier is upgraded with dual-protocol support and HTTPS enabled, allowing it to use both HTTP and HTTPS. Currently, HTTPS protocol is used for REST calls across the cnDBTier sites.
Disable the dual-protocol support in the next upgrade.

Note:
This step removes the HTTP port so that only HTTPS connection is allowed in cnDBTier. This step can be performed at any phase of the upgrade.
```
  https:
    enable: true
    supportDualProtocol: false 
```

4.7 Upgrading cnDBTier HTTPS Enabled to HTTPS Disabled Version

This section describes the procedure to upgrade cnDBTier HTTPS enabled to HTTPS disabled version.

Note:

While enabling dual protocol, do not assign the same port for both service.httpPort and service.httpsPort.
For more information about local site and remote site port configuration parameters, see the Global Parameters section.
When upgrading from previous version to current version, ensure the value of the service.httpsPort parameter is same as the value of the service.port parameter from the earlier version. For more information on these parameters, see the Global Parameters section.

Perform the following steps to configure HTTPS:

Enable the dual protocols by setting the supportDualProtocol parameter to true in the custom_values.yaml file for all the cnDBTier sites.
Sample:
```
global:
  https:
    enable: true
    supportDualProtocol: true
```
Perform the Upgrading cnDBTier procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.
Result: cnDBTier has been upgraded with the dual-protocol support. This allows both HTTP on the specified service.httpport and HTTPS on the specified service.httpsport to be used.

Note:
After this step, only HTTPS protocol is used for the REST APIs across the cnDBTier sites.
Disable HTTPS in the custom_values.yaml file for all the cnDBTier sites.
```
global: 
  https:
    enable: false
    supportDualProtocol: true
```
Note:
Update the local site port to service.httpport and remote site port to the server.httpport of the other cnDBTier site where HTTP is configured.
For more information about local site and remote site port configuration, see Global Parameters section.
Perform the Upgrading cnDBTier procedure to upgrade all the cnDBTier sites one after the other using the custom_values.yaml file that you updated in the previous steps.
Result: cnDBTier has been upgraded with the dual-protocol support. This allows both HTTP on the specified service.httpport and HTTPS on the specified service.httpsport to be used.

Note:
After this step, only HTTP protocol is used for the REST APIs across the cnDBTier sites.
Disable the dual-protocol support in the next upgrade.

Note:
This step removes the HTTPS port so that only HTTP connection is allowed in cnDBTier. This step can be performed at any phase of the upgrade.
```
global: 
  https:
    enable: false
    supportDualProtocol: false
```

4.8 Handling `mysql_native_password` Plugin Before the Upgrade

The cnDBTier version 25.1.2xx does not support the mysql_native_password plugin.

This section explains the steps to migrate from mysql_native_password plugin used by earlier MySQL users to caching_sha2_password plugin before performing the upgrade.

Procedure to migrate

Identifying users not using caching_sha2_password:
Run the following SQL queries using any ndbmysqld or ndbappmysqld pod to check existing user authentication plugins:
```
SELECT user, host, plugin FROM mysql.user;
SELECT user, host, plugin FROM mysql.user WHERE plugin <> 'caching_sha2_password';
```
If all users are already using the caching_sha2_password plugin, skip the rest of the steps. Otherwise, proceed with the conversion steps below.
Generating ALTER USER command:
Use the following bash command to generate the required ALTER USER statements for users not using the caching_sha2_password plugin:
1. Set the environment variables:
  1. Username stored in secret 'occne-secret-db-monitor-secret must be set to user="<occneuser>" .
  2. Password stored in secret 'occne-secret-db-monitor-secret' must be set to password="<password>".
  3. Use '127.0.0.1' for IPv4 or '::1' for IPv6 must be set to host="<mysql_localhost>".
2. Set the namespace and container/pod details:
  1. Namespace of the cnDBTier deployment must be set to namespace="<namespace>".
  2. Add a prefix to the MySQL ndb Container name, if applicable, container="<mysql_ndb_cluster_container_name>"
  3. Add a prefix to the pod name for ndbappmysqld-0, if applicable, pod="<ndbappmysqld_pod_name>".
3. Start the execution:
  Run the following command:
```
echo; echo "SET sql_log_bin = OFF;"; kubectl -n "$namespace" exec -it -c "$container" "$pod" -- bash -c "mysql -N -s -h$host -u$user -p$password -e \"SELECT CONCAT(\\\"ALTER USER '\\\", user, \\\"'@'\\\", host, \\\"' IDENTIFIED WITH caching_sha2_password BY '\<your_password_here\>';\\\") FROM mysql.user WHERE plugin <> 'caching_sha2_password';\" 2>/dev/null" | sed '/healthchecker/d'; echo "FLUSH PRIVILEGES;"; echo "SET sql_log_bin = ON;"; echo
```
If required, update the root user:
1. If the root user is not already using the caching_sha2_password plugin, run the following SQL commands in MySQL:
```
SET sql_log_bin=OFF;
 
-- Grant temporarily required by cndbtier for password propagation
GRANT NDB_STORED_USER ON *.* TO 'root'@'localhost';
FLUSH PRIVILEGES;
 
SET sql_log_bin=ON;
```
2. Update the root password plugin.
  Run the following commands to set the root password:
```
SET sql_log_bin = OFF;
 
ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY '<root_password>';
FLUSH PRIVILEGES;
 
SET sql_log_bin = ON;
```
  Replace <root_password> with the appropriate password.

Remove the temporary root grant:

Revoke the temporary NDB_STORED_USER grant from the root user:

SET sql_log_bin=OFF;
 
REVOKE NDB_STORED_USER ON *.* FROM 'root'@'localhost';
FLUSH PRIVILEGES;
 
SET sql_log_bin=ON;

Handle the healthchecker user, if it exists

If the healthchecker user exists and is not using caching_sha2_password, then run the following SQL statements:

SET sql_log_bin=OFF;
 
GRANT NDB_STORED_USER ON *.* TO 'healthchecker'@'localhost';
FLUSH PRIVILEGES;
 
DROP USER IF EXISTS 'healthchecker'@'localhost';
FLUSH PRIVILEGES;
 
SET sql_log_bin=ON;

Run the ALTER USER command for all other affected users

Run the ALTER USER commands for the remaining users that are not using the caching_sha2_password plugin (for example, occneuser, occnerepluser, NF users):

SET sql_log_bin = OFF;
 
SELECT user, host, plugin FROM mysql.user;
 
ALTER USER 'occneuser'@'%' IDENTIFIED WITH caching_sha2_password BY '<occneuser_password>';
ALTER USER 'occnerepluser'@'%' IDENTIFIED WITH caching_sha2_password BY '<occnerepluser_password>';
 
-- Add ALTER USER commands for NF users or any other relevant users
-- Example:
-- ALTER USER 'nfuser'@'%' IDENTIFIED WITH caching_sha2_password BY '<nfuser_password>';
 
FLUSH PRIVILEGES;
SELECT user, host, plugin FROM mysql.user;
 
SET sql_log_bin = ON;

Verify Across All the Pods if Users are Using caching_sha2_password Plugin:

Run the following script to verify that all the users are now using the caching_sha2_password plugin across all the ndbmysqld and ndbappmysqld pods:

user="occneuser"
password="<password>"
host="::1"
 
for pod in $(
    kubectl -n "$DBTIER_NAMESPACE" get pods -l dbtierapp=ndbmysqld --no-headers -o=custom-columns='NAME:.metadata.name'
    kubectl -n "$DBTIER_NAMESPACE" get pods -l dbtierapp=ndbappmysqld --no-headers -o=custom-columns='NAME:.metadata.name'
); do
    echo "Pod: $pod"
    kubectl -n $DBTIER_NAMESPACE exec -it -c mysqlndbcluster "$pod" -- bash -c "
        mysql -h$host -u$user -p$password -e 'SELECT user, host, plugin FROM mysql.user;' 2>/dev/null
    "
    echo
done

Replace the <password> field with the actual password for the occneuser.

4.9 Upgrading cnDBTier Clusters

Note:

If cnDBTier is configured with single replication channel then upgrade has to be done using single replication channel group. If cnDBTier is configured with multi replication channel group then upgrade has to be done using multi replication channel group.
As of 23.4.x, the Upgrade Service Account requires persistentvolumeclaims in its rules.resources. This new rule is necessary for the post-rollback hook to delete mysqld PVCs when rolling back to an earlier mysql release.
The db-backup-manager-svc automatically restarts when errors are encountered. Hence, in the case where the backup-manager-svc encounters a temporary error during the upgrade process of cnDBTier, it may undergo several restarts. Once the cnDBTier reaches a stable state, it is expected that the db-backup-manager-svc pod will operate fine without any further restarts.

It is recommended to bring cnDBTier HeartbeatIntervalDbDb value to 1250. If the value of HeartbeatIntervalDbDb is 5000, then follow the below steps to reduce HeartbeatIntervalDbDb to 1250:

Modify the HeartbeatIntervalDbDb to 2500 in custom values file (/global/additionalndbconfigurations/ndb/) and perform cnDBTier upgrade.
Once upgrade is completed successfully Modify the HeartbeatIntervalDbDb to 1250 in custom values file (/global/additionalndbconfigurations/ndb/) and perform cnDBTier upgrade.

If the value of HeartbeatIntervalDbDb is 500, then follow the below steps to increase HeartbeatIntervalDbDb to 1250.

Modify the HeartbeatIntervalDbDb to 900 in custom values file (/global/additionalndbconfigurations/ndb/) and perform a cnDBTier upgrade.
Once the upgrade is completed, modify the HeartbeatIntervalDbDb to 1250 in custom values file (/global/additionalndbconfigurations/ndb/) and perform a cnDBTier upgrade.

When upgrading from any cnDBTier release prior to version 23.4.x, it is essential to deactivate the network policy in the custom_values.yaml file before initiating the upgrade process.

global:
  networkpolicy:
    enabled: false

Following the successful upgrade to cnDBTier version 23.4.x, there is an option to re-enable the network policy in the custom_values.yaml file at their discretion by following the upgrade procedure again.

global:
  networkpolicy:
    enabled: true

Note:

If the TLS certificates for replication are being modified while upgrading a cnDBTier cluster from TLS to TLS, refer to the section"Modifying cnDBTier Certificates to Establish TLS Between Georeplication Sites" in Oracle Communications Cloud Network Core, cnDBTier User Guide to add new certificates by retaining existing certificates and then proceed with the upgrade.
If the TLS certificates for APP SQL pods are being modified while upgrading a cnDBTier cluster from TLS to TLS, refer to the section "Modifying cnDBTier Certificates to Establish TLS for Communication with NFs" in Oracle Communications Cloud Network Core, cnDBTier User Guide to add new certificates by retaining existing certificates and then proceed with the upgrade.
If upgrading from 24.3.x or 25.1.2xx then configure service.httpsPort (refer mentioned field for current version) same as the value in the earlier version as service.port refer mentioned field of earlier version.
If upgrading from 24.3.x with https enabled, then set the following configuration (global/https/clientAuthentication) to 'WANT' and upgrade all the sites one by one. After all the sites are upgraded, set the configuration (global/https/clientAuthentication) to 'NEED' and perform upgrade one more time on all the sites one by one.
```
global:
  https:
    clientAuthentication: WANT
```
If you are upgrading cnDBTier from 24.3.x or 25.1.1xx to current version with https enabled, then ensure to create the secrets given in the Creating Secrets section.
During upgrade you must upgrade only one georedundant cnDBTier site at a time. Upon completion of upgrade, you must move to the next geo redundant cnDBTier site for upgrade.
Starting from the 24.3.x release, files can be encrypted in the data nodes by setting EncryptedFileSystem to 1. Therefore, when upgrading from a release prior to 24.3.x or a TDE-disabled setup to a 24.3.x TDE-enabled setup, first create the secret "occne-tde-encrypted-filesystem-secret" by following the section Creating Secrets.
The namespace "occne-cndbtier" is provided only as an indicative purpose. You can configure the name according to your environment.
The PVC value must not be changed during an upgrade. If the PVC size needs to be adjusted according to the dimensioning sheet, please follow the vertical scaling procedure to modify the PVC size.

Assumptions

All NDB pods of cnDBTier cluster are up and running.
Helm limits some parameter (for example, pvc size) to be changed during upgrade, so these type of parameters cannot be changed.

The Start Node ID must be same as existing start Node ID. The Starting Node ID can be obtained from the existing cluster using the following command:

$ kubectl -n ${OCCNE_NAMESPACE} exec ndbmgmd-0 -- ndb_mgm -e show

Sample output:

Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @10.233.94.13  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0, *)
id=2    @10.233.124.12  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0)
 
[ndb_mgmd(MGM)] 2 node(s)
id=49   @10.233.124.11  (mysql-8.4.4 ndb-8.4.4)
id=50   @10.233.93.14  (mysql-8.4.4 ndb-8.4.4)
 
[mysqld(API)]   5 node(s)
id=56   @10.233.123.15  (mysql-8.4.4 ndb-8.4.4)
id=57   @10.233.94.14  (mysql-8.4.4 ndb-8.4.4)
id=70   @10.233.120.20  (mysql-8.4.4 ndb-8.4.4)
id=71   @10.233.95.22  (mysql-8.4.4 ndb-8.4.4)
id=222 (not connected, accepting connect from any host)
id=223 (not connected, accepting connect from any host)
id=224 (not connected, accepting connect from any host)
id=225 (not connected, accepting connect from any host)

As per the above example, the Start Node ID must be 49 for mgm, 56 for georeplication SQL and 70 for non-georeplication SQL pods.

Note:

Node id 222 to node id 225 are shown as "not connected" because these are added as empty slot ids which are used for georeplication recovery.

Upgrading cnDBTier Cluster

Perform the following procedure to upgrade cnDBTier cluster:

Download the latest cnDBTier packages to Bastion Host. For more information, refer to the Downloading cnDBTier Package section.
If dB encryption and HTTPS mode is not enabled before, then disable the HTTPS mode and dB encryption before the upgrade.
Configure the https and encryption parameters in the custom_values.yaml file as shown below:
```
https:
    enable: false
     
  encryption:
    enable: false
```
Before performing cnDBTier upgrade, run the Helm test on the current cnDBTier at all sites, only if the Helm test is successful on all sites then proceed with the upgrade.Verify if the current cnDBTier instance is running correctly by running the following Helm test command on Bastion host:
```
$ helm test  mysql-cluster --namespace ${OCCNE_NAMESPACE}
```
Sample output:
```
NAME: mysql-cluster
LAST DEPLOYED: Tue May 20 10:22:58 2025
NAMESPACE: occne-cndbtier
STATUS: deployed
REVISION: 1
TEST SUITE:     mysql-cluster-node-connection-test
Last Started:   Tue May 20 14:15:18 2025
Last Completed: Tue May 20 14:17:58 2025
Phase:          Succeeded
```
If the upgrade has to be done with fixed loadBalancer IP for external services, then find the IP addresses of the current cnDBTier cluster by running the following command:
```
$ kubectl get svc -n ${OCCNE_NAMESPACE}
```
Configure the loadBalancer IP addresses obtained from the above command in custom_values.yaml file by referring to the cnDBTier configurations table in the section Customizing cnDBTier.
If backup encryption is required to be enabled, then create the backup encryption secrets and subsequently configure "/global/backupencryption/enable" configuration in the custom_values.yaml as true for enabling the backup encryption.
If password encryption is required to be enabled, then create the password encryption secrets and subsequently configure "/global/encryption/enable" configuration in the custom_values.yaml as true for enabling the password encryption.
If Kubernetes version is above or equal to 1.25 and Kyverno is supported or installed on Kubernetes, then run the following commands appropriately:
- If Kubernetes version is above or equal to 1.25 and Kyverno is supported or installed on Kubernetes and ASM or istio is installed or running on Kubernetes, then run the following command:
```
# $ kubectl apply -f namespace/occndbtier_kyvernopolicy_asm_${OCCNE_VERSION}.yaml -n ${OCCNE_NAMESPACE}
```
- If Kubernetes version is above or equal to 1.25 and Kyverno is supported or installed on Kubernetes and ASM or istio is not installed or running on Kubernetes, then run the following command:
```
$ kubectl apply -f namespace/occndbtier_kyvernopolicy_nonasm_${OCCNE_VERSION}.yaml -n ${OCCNE_NAMESPACE}
```
If secure transfer of backup(s) to remote server needs to be enabled, then create the remote server user name and private key secrets and subsequently configure the following parameters in the custom_values.yaml file for enabling the secure transfer of backup(s):
- /global/remotetransfer/enable
- /global/remotetransfer/faultrecoverybackuptransfer
- /global/remotetransfer/remoteserverip
- /global/remotetransfer/remoteserverport
- /global/remotetransfer/remoteserverpath
Starting from version 25.1.2xx, using dual protocol support, HTTP and HTTPs can be run concurrently on separate ports. Hence, HTTPs can be enabled or disabled using the procedures, Upgrading cnDBTier HTTPS Enabled to HTTPS Disabled Version and Upgrading cnDBTier HTTPS Disabled to HTTPS Enabled Version respectively.
The following ports must be configured:
- httpport (default port 80): HTTP traffic will be served on port 80.
- httpsport (default port 443): HTTPS traffic will be served on port 443.
This allows for a smooth migration between HTTP and HTTPS (or vice-versa) without service interruption.
If you are upgrading from a version prior to 25.1.2xx, perform the following procedure:
- If you are upgrading from HTTPS to HTTPS:
  The httpsport value must be set to the same value as service.port from your previous release. For example, If the service.port was set to 80, then set httpsport to 80 as shown below:
```
service:
  type: LoadBalancer
  loadBalancerIP: ""
  httpport: 81
  httpsport: 80
```
- If you are upgrading from HTTP to HTTP:
  The httpport value must be set to the same value as service.port from your previous release. For example, if the service.port was set to 80, then set httpport to 80 as shown below:
```
service:
  type: LoadBalancer
  loadBalancerIP: ""
  httpport: 80
  httpsport: 443
```

Automated cnDBTier upgrade needs a Service Account for pod rolling restart and patch, if you choose to go with Automated cnDBTier upgrade with the Service Account, then follow the Upgrading cnDBTier Clusters with an Upgrade Service Account section. If you choose to upgrade cnDBTier manually without having to use any Service Account, then follow the Upgrading cnDBTier Clusters without an Upgrade Service Account.

4.9.1 Upgrading cnDBTier Clusters with an Upgrade Service Account

Perform the following procedure to upgrade cnDBTier clusters with an Upgrade Service Account:

Note:

The namespace "occne-cndbtier" is provided as an indicative purpose. You must configure the namespace name according to your environment.

Create an Upgrade Service Account manually if it does not exist so that cnDBTier does not create automated service account using Helm charts. If you have a Service Account created manually with the right role, which you can check in namespace.yaml or rbac.yaml, to use for upgrade, skip this step. Do not perform this step if you want to create service account using cnDBTier Helm charts.
1. Set the ${OCCNE_RELEASE_NAME} environment variable with the Helm value of RELEASE_NAME which you can find in the NAME column, when you run the command, helm -n ${OCCNE_NAMESPACE}list.
```
export OCCNE_RELEASE_NAME="mysql-cluster"
```
2. Update the Service Account, Role and Rolebinding for the upgrade in namespace/rbac.yaml file. Depending upon the CSAR package type, the namespace directory can be either found at /Artifacts/Scripts/ or at /Scripts/ relative path.
```
sed -i "s/occne-cndbtier/${OCCNE_NAMESPACE}/" namespace/occndbtier_rbac_${OCCNE_VERSION}.yaml
sed -i "s/mysql-cluster/${OCCNE_RELEASE_NAME}/" namespace/occndbtier_rbac_${OCCNE_VERSION}.yaml
sed -i "s/cndbtier-upgrade/${OCCNE_RELEASE_NAME}-upgrade/" namespace/occndbtier_rbac_${OCCNE_VERSION}.yaml
sed -i "s/rolebinding/role/" namespace/occndbtier_rbac_${OCCNE_VERSION}.yaml
```
3. Create an Upgrade Service Account, Upgrade Role, and Upgrade Rolebinding by running the following command:
```
kubectl -n ${OCCNE_NAMESPACE} apply -f namespace/occndbtier_rbac_${OCCNE_VERSION}.yaml
```
Configure the Upgrade Service Account in your custom_values.yaml file. Follow one of these options:
- If step 1 is performed or if the Service Account is created manually and you want cnDBTier to use the same service account for upgrade, then provide the name of that manually created service account in the parameter global.autoCreateResources.serviceAccounts.accounts[1].serviceAccountName and configure global.autoCreateResources.serviceAccounts.accounts[1].create flag as false.
```
autoCreateResources:
    enabled: false
    serviceAccounts:
      create: false
      accounts:
        - serviceAccountName: ""
          type: APP
          create: true
        - serviceAccountName: "<manually_created_service_account_name>"
          type: UPGRADE
          create: false
```
- If a Service Account was created previously using the Helm charts manually, if from this release you want cnDBTier helm charts to create automated service account, then set the global.serviceAccountForUpgrade.create parameter to true and provide the name of the Service Account different from the manual Service Account existing in the older release. Service account name must be different from manually created service account in previous version in order to support rollback, since rollback requires that manual service account which was configured in older version custom_values.yaml file. Service Account name has to be configured in field global.autoCreateResources.serviceAccounts.accounts[1].serviceAccountName. This field can also be left empty, and in that case, cnDBTier Helm chart will create Service Account with the name release-name-upgrade-reader (if the release name is mysql-cluster, then Service Account will be created with the name mysql-cluster-upgrade-reader).
```
autoCreateResources:
    enabled: true/false
    serviceAccounts:
      create: true
      accounts:
        - serviceAccountName: ""
          type: APP
          create: true
        - serviceAccountName: "<service_account_name>"
          type: UPGRADE
          create: true
```
- If a Service Account was created previously by cnDBTier Helm charts with the global.serviceAccountForUpgrade.create parameter set to true in the previous release (25.1.100 or 24.3.x), retain the configurations for the global.autoCreateResources.serviceAccounts.accounts[1].create parameter in the current release which must be same as the global.serviceAccountForUpgrade.create parameter in the older release and similarly configurations for global.autoCreateResources.serviceAccounts.accounts[1].serviceAccountName must be same as global.serviceAccountForUpgrade.name.
- If you do not have a serviceAccount created manually or from a previous cnDBTier version, then configure global.autoCreateResources.serviceAccounts.accounts[1].create parameter as true in custom_values file. If global.autoCreateResources.serviceAccounts.accounts[1].serviceAccountName is configured, then upgrade service account will be created with the provided name or cnDBTier will create a Service Account with the default name in case serviceAccountName is set to empty ("") value.
```
autoCreateResources:
    enabled: true
    serviceAccounts:
      create: true
      accounts:
        - serviceAccountName: ""
          type: APP
          create: true
        - serviceAccountName: "<service_account_name>"
          type: UPGRADE
          create: true
```
Upgrade cnDBTier by running the following commands:
Set the ${OCCNE_RELEASE_NAME} environment variable with the Helm value of RELEASE_NAME, the release name is found in the NAME column when you run this command:
```
helm -n ${OCCNE_NAMESPACE} list
export OCCNE_RELEASE_NAME="mysql-cluster"
 
cd /var/occne/cluster/${OCCNE_CLUSTER}
 
helm -n ${OCCNE_NAMESPACE} upgrade ${OCCNE_RELEASE_NAME} occndbtier -f occndbtier/custom_values.yaml
```
Wait for all the MGM and NDB pods to restart.
Perform a second rollout restart of the NDB pods to apply the change to the new HeartbeatDbDb. This step is required only if upgrading from a release that doesn't have this support.
```
kubectl -n $DBTIER_NAMESPACE rollout restart statefulset ndbmtd
```
Wait for all the NDB pods to restart.

Verify the cluster status from the management pod by running the following command:

$ kubectl -n ${OCCNE_NAMESPACE} exec -it ndbmgmd-0 -- ndb_mgm -e show

Sample output:

Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @10.233.104.176  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0)
id=2    @10.233.121.175  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0, *)
 
[ndb_mgmd(MGM)] 2 node(s)
id=49   @10.233.101.154  (mysql-8.4.4 ndb-8.4.4)
id=50   @10.233.104.174  (mysql-8.4.4 ndb-8.4.4)
 
[mysqld(API)]   8 node(s)
id=56   @10.233.92.169  (mysql-8.4.4 ndb-8.4.4)
id=57   @10.233.101.155  (mysql-8.4.4 ndb-8.4.4)
id=70   @10.233.92.170  (mysql-8.4.4 ndb-8.4.4)
id=71   @10.233.121.176  (mysql-8.4.4 ndb-8.4.4)
id=222 (not connected, accepting connect from any host)
id=223 (not connected, accepting connect from any host)
id=224 (not connected, accepting connect from any host)
id=225 (not connected, accepting connect from any host)

Note:

Nodes with id 222 to id 225 will be shown as "not connected" because these are added as empty slot ids which are used for geo replication recovery.

Run the following Helm test command to verify if the cnDBTier services are upgraded successfully:

$ helm test  mysql-cluster --namespace ${OCCNE_NAMESPACE}

Sample output:

NAME: mysql-cluster
LAST DEPLOYED: Tue May 20 10:22:58 2025
NAMESPACE: occne-cndbtier
STATUS: deployed
REVISION: 1
TEST SUITE:     mysql-cluster-node-connection-test
Last Started:   Tue May 20 14:15:18 2025
Last Completed: Tue May 20 14:17:58 2025
Phase:          Succeeded

After the successful cnDBTier upgrade, follow the Postinstallation Tasks.

4.9.2 Upgrading cnDBTier Clusters without an Upgrade Service Account

Perform the following procedure to upgrade cnDBTier clusters without an Upgrade Service Account:

Note:

The namespace "occne-cndbtier" is provided as an indicative purpose. You must configure the namespace name according to your environment.

Configure your custom_values.yaml file to not use Upgrade Service Account.
```
autoCreateResources:
  enabled: true/false
  serviceAccounts:
    create: true
    accounts:
      - serviceAccountName: ""
        type: APP
        create: true
        - serviceAccountName: ""
        type: UPGRADE
        create: false
```
Note:
If the previous release of cnDBTier used a custom_values file where the parameter global.serviceAccountForUpgrade.create was set to true, then the Helm chart may have created a service account during that deployment.
If you upgrade to a newer version of cnDBTier with the Service Account disabled, that is the parameterglobal.serviceAccountForUpgrade.create is set to false or removed, then the previously created service account will be deleted during the upgrade.

As a result, if a rollback is attempted, then the rollback fails as the required Service Account from the earlier version no longer exists.
Run the preupgrade script if you are upgrading from a previous cnDBTier release or if you need to enable or disable password encryption. It upgrades the schema.
Run the following commands on the Bastion host to apply the schema changes:

Note:
Enabling or disabling encryption may cause a brief disruption to the replication between the sites if a switchover happens between step 2 and step 4. Therefore, perform steps 3 and 4 immediately after completing step 2.

Replace the values for the environment variables below with the correct ones for your cluster:
```
export OCCNE_NAMESPACE="occne-cndbtier"
export MYSQL_CONNECTIVITY_SERVICE="mysql-connectivity-service"
export MYSQL_USERNAME="occneuser"
export MYSQL_PASSWORD="<password for the user occneuser>"
export DBTIER_REPLICATION_SVC_DATABASE="replication_info"
export DBTIER_BACKUP_SVC_DATABASE="backup_info"
export DBTIER_HBREPLICAGROUP_DATABASE="hbreplica_info"
export DBTIER_CLUSTER_INFO_DATABASE="cluster_info"
export REPLCHANNEL_GROUP_COUNT=<configured number of replication channel groups i.e either 1/2/3>
export MYSQL_CMD="kubectl -n <namespace> exec <ndbmysqld-0/ndbappmysqld-0 pod name> -- mysql --binary-as-hex=0 --show-warnings"
```
To enable or disable password encryption, uncomment the following line and set the variable to true or false to enable or disable it.
```
# export ENABLE_ENCRYPTION="<true/false>"
```
```
occndbtier/files/hooks.sh --schema-upgrade
```
Perform the following steps on the Bastion host to run the preupgrade procedure.
1. Replace the values for the following environment variables with the correct ones for your cluster:
```
export OCCNE_NAMESPACE="occne-cndbtier"
```
2. If pod prefix is being used, then a prefix must be added to the following environment variable for both the pod and stateful set names:
  For example:
```
export NDB_MGMD_PODS="<global.k8sResource.pod.prefix>-ndbmgmd-0 <global.k8sResource.pod.prefix>-ndbmgmd-1"
```
```
export APP_STS_NAME="<global.k8sResource.pod.prefix>-ndbappmysqld"
export NDB_MGMD_PODS="ndbmgmd-0 ndbmgmd-1"
export APP_STS_NAME="ndbappmysqld"
 
occndbtier/files/hooks.sh --pre-upgrade
```
Upgrade cnDBTier by running the following commands:
Set the ${OCCNE_RELEASE_NAME} environment variable with the Helm value of RELEASE_NAME which you can find in the NAME column when you run this command helm -n ${OCCNE_NAMESPACE} list:
```
export OCCNE_RELEASE_NAME="mysql-cluster"
cd /var/occne/cluster/${OCCNE_CLUSTER}
helm -n ${OCCNE_NAMESPACE} upgrade ${OCCNE_RELEASE_NAME} occndbtier -f occndbtier/custom_values.yaml --no-hooks
```

Run the post-upgrade script. It deletes all the MGM pods, waits for them to comeup, and patches upgradeStrategy.

# replace the values for the environment variables below with the correct ones for your cluster
export OCCNE_NAMESPACE="occne-cndbtier"
#export API_EMP_TRY_SLOTS_NODE_IDS="id=222"
export API_EMP_TRY_SLOTS_NODE_IDS="id=222\|id=223\|id=224\|id=225"
export MGM_NODE_IDS="id=49\|id=50"
# export all the ndbmtd node ids in the below env variable
export NDB_NODE_IDS="id=1\|id=2"
# Export all the ndbmysqld node ids in the below env variable
# ndbmysqld node_ids starts at global.api.startNodeId and ends at (global.api.startNodeId + global.apiReplicaCount - 1)
export API_NODE_IDS="id=56\|id=57"
# if pod prefix is being used, then the prefix must be added to the below env variable for both the the pod and stateful set names
# example: export NDB_MGMD_PODS="<global.k8sResource.pod.prefix>-ndbmgmd-0 <global.k8sResource.pod.prefix>-ndbmgmd-1"
# export NDB_STS_NAME="<global.k8sResource.pod.prefix>-ndbmtd"
export NDB_MGMD_PODS="ndbmgmd-0 ndbmgmd-1"
export NDB_MTD_PODS="ndbmtd-0 ndbmtd-1"
export NDB_STS_NAME="ndbmtd"
export API_STS_NAME="ndbmysqld"
export APP_STS_NAME="ndbappmysqld"
 
#If auto scaling for ndbapp sts is enabled then declare the below env variables(NDBAPP_START_NODE_ID and NDBAPP_REPLICA_MAX_COUNT)
#export NDBAPP_START_NODE_ID="<as configured in values.yaml: global.ndbapp.startNodeId>"
#export NDBAPP_REPLICA_MAX_COUNT="<as configured in values.yaml: global.ndbappReplicaMaxCount>"    
 
#If values.global.ndbapp.ndb_cluster_connection_pool is greater than 1 then declare the below env variable(APP_CON_POOL_INGORE_NODE_IDS)
export APP_CON_POOL_INGORE_NODE_IDS="id=100\|id=101\|id=102 ... \|id=(n-1)\|id=n"
# Here n can be calculated as n = 100 + (((values.global.ndbapp.ndb_cluster_connection_pool - 1) * values.global.ndbappReplicaMaxCount) - 1)
 
 
occndbtier/files/hooks.sh --post-upgrade

Wait for all the MGM and NDB pods to restart.
Perform a second rollout restart of the NDB pods to apply the change to the new HeartbeatDbDb. This step is required only if upgrading from a release that does not have this support.
```
kubectl -n $DBTIER_NAMESPACE rollout restart statefulset ndbmtd
```
Wait for all the NDB pods to restart.

Verify the cluster status from the management pod by running the following command:

$ kubectl -n ${OCCNE_NAMESPACE} exec -it ndbmgmd-0 -- ndb_mgm -e show

Sample output:

Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @10.233.104.176  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0)
id=2    @10.233.121.175  (mysql-8.4.4 ndb-8.4.4, Nodegroup: 0, *)
 
[ndb_mgmd(MGM)] 2 node(s)
id=49   @10.233.101.154  (mysql-8.4.4 ndb-8.4.4)
id=50   @10.233.104.174  (mysql-8.4.4 ndb-8.4.4)
 
[mysqld(API)]   8 node(s)
id=56   @10.233.92.169  (mysql-8.4.4 ndb-8.4.4)
id=57   @10.233.101.155  (mysql-8.4.4 ndb-8.4.4)
id=70   @10.233.92.170  (mysql-8.4.4 ndb-8.4.4)
id=71   @10.233.121.176  (mysql-8.4.4 ndb-8.4.4)
id=222 (not connected, accepting connect from any host)
id=223 (not connected, accepting connect from any host)
id=224 (not connected, accepting connect from any host)
id=225 (not connected, accepting connect from any host)

Note:

Node id 222 to id 225 will be shown as "not connected" because these are added as empty slot Ids which are used for geo replication recovery.

Run the following Helm test command to verify if the cnDBTier services are upgraded successfully.

$ helm test  mysql-cluster --namespace ${OCCNE_NAMESPACE}
NAME: mysql-cluster
LAST DEPLOYED: Tue May 20 10:22:58 2025
NAMESPACE: occne-cndbtier
STATUS: deployed
REVISION: 1
TEST SUITE:     mysql-cluster-node-connection-test
Last Started:   Tue May 20 14:15:18 2025
Last Completed: Tue May 20 14:17:58 2025
Phase:          Succeeded

After the successful cnDBTier upgrade, follow the Postinstallation Tasks.

4 Upgrading cnDBTier

4.1 Supported Upgrade Paths

4.2 Upgrading cnDBTier from Non-TLS to TLS Enabled Version (Replication)

4.3 Upgrading cnDBTier from TLS Enabled to Non-TLS Version (Replication)

4.4 Upgrading cnDBTier from Non-TLS to TLS Enabled Version (NF Communication)

4.5 Upgrading cnDBTier from TLS Enabled to Non-TLS Version (NF Communication)

4.6 Upgrading cnDBTier HTTPS Disabled to HTTPS Enabled Version

4.7 Upgrading cnDBTier HTTPS Enabled to HTTPS Disabled Version

4.8 Handling mysql_native_password Plugin Before the Upgrade

4.9 Upgrading cnDBTier Clusters

4.9.1 Upgrading cnDBTier Clusters with an Upgrade Service Account

4.9.2 Upgrading cnDBTier Clusters without an Upgrade Service Account

4.8 Handling `mysql_native_password` Plugin Before the Upgrade