Rolling Upgrade

Rolling upgrade does not require all nodes to be down, but can be realized while external services are being upgraded.

PTK 1.4.0 and above support rolling upgrade, but since the rolling upgrade process always upgrades the standby node and does not directly upgrade the primary node, you cannot submit any SQL during the upgrade process, and cannot upgrade database with plugins.

Supported Upgrade Version

Rolling upgrades only support upgrades between versions with no changes in metadata, i.e., the kernel version of the database must be the same before and after the upgrade. The output of Number field by running ptk candidate db is the kernel version number (requires PTK 1.4.0 or later).

# ptk candidate db
  Software  | Version | Number | Lifecycle Policy | Release Date  
------------+---------+--------+------------------+---------------
  MogDB     | 2.0.0   | 92.298 | LTS              | 2021-05-25    
            | 2.0.1   | 92.299 | LTS              | 2021-07-08    
            | 2.0.3   | 92.300 | LTS              | 2022-06-29    
            | 2.0.4   | 92.302 | LTS              | 2022-10-15    
            | 2.1.1   | 92.421 | Preview          | 2022-03-22    
            | 3.0.0   | 92.605 | LTS              | 2022-06-30    
            | 3.0.1   | 92.605 | LTS              | 2022-07-30    
            | 3.0.2   | 92.605 | LTS              | 2022-09-16    
            | 3.0.3   | 92.605 | LTS              | 2022-10-31    
            | 3.0.4   | 92.605 | LTS              | 2023-03-24    
            | 3.0.5   | 92.607 | LTS              | 2023-07-20    
            | 3.0.6   | 92.607 | LTS              | 2023-09-15    
            | 3.0.7   | 92.607 | LTS              | 2023-12-29    
            | 3.1.0   | 92.781 | Preview          | 2022-12-30    
            | 3.1.1   | 92.781 | LTS              | 2023-11-26    
            | 5.0.0   | 92.848 | LTS              | 2023-07-14    
            | 5.0.1   | 92.850 | LTS              | 2023-08-15    
            | 5.0.2   | 92.900 | LTS              | 2023-09-30    
            | 5.0.3   | 92.900 | LTS              | 2023-10-27    
            | 5.0.4   | 92.901 | LTS              | 2023-11-30    
            | 5.0.5   | 92.901 | LTS              | 2023-12-30    
            | 5.0.6   | 92.920 | LTS              | 2024-03-30

Backup Data

In the upgrade process, to avoid the implementation of errors in the upgrade exception, resulting in the original version of the database files or data being accidentally modified, and can not be performed to roll back the operation of the situation, the upgrade must be done before the data backup and integrity protection, to facilitate the use of the upgraded data backed up when the upgrade error occurs restored to the state before the upgrade, to avoid operational errors resulting in the business can not be recovered.

In the process of upgrading with PTK, the tool will automatically complete the backup of the original version of the database software, If you need to back up all the data files, you can use gs_basebackup for the base physical backup, an example is as follows:

Create a backup directory using the database user (e.g. omm)
```
mkdir /home/omm/mogdb_data_bak
```
Backup via gs_basebackup
```
gs_basebackup -D /home/omm/mogdb_data_bak -h 127.0.0.1 -p 26000
```
The host name and port number need to be replaced according to the actual situation.

Upgrade Steps

Take one primary and one standby as an example, assume that the primary IP is IP1 and the standby IP is IP2 in the initial state.

Check if the machine status is Normal.
```
ptk cluster -n <CLUSTER_NAME> status
```
Upgrade standby node in the cluster.

Perform a single-node upgrade of a standby node in the cluster with the -H parameter, and the node should be able to temporarily switchover to the primary node to provide services.
```
ptk cluster -n <CLUSTER_NAME> upgrade -p <PACKAGE_PATH> -H <IP2>
```
Perform primary/standby nodes switchover.

Switch the upgraded standby node to the primary node and demote the original primary node to the standby node.
```
ptk cluster -n <CLUSTER_NAME> switchover -H <IP2>
```

Upgrade the original primary node.

ptk cluster -n <CLUSTER_NAME> upgrade -p <PACKAGE_PATH> -H <IP1>

(Optional) Re-switch the primary node to the original primary machine.
```
ptk cluster -n <CLUSTER_NAME> switchover -H <IP1>
```

Upgrade commit.

ptk cluster -n <CLUSTER_NAME> upgrade-commit

Notes

There will be scenarios where different versions of the primary and standby nodes are running at the same time, so you should make sure that there are no changes in metadata and log file formats between the old and new versions when using a rolling upgrade.

Please make a good data backup in advance, so that you can roll back to the pre-upgrade state if you encounter problems, and then feedback the problems encountered to our engineers.