Read Before Upgrade

Upgrade Impact and Constraints

The upgrade includes the following impacts and constraints, before upgrading, you should do a good job of fully checking and understanding, to ensure that the conditions can be met before upgrading, if you have any questions, please contact our engineers.

• Do not perform the upgrade, scale-out, and scale-in at the same time.
• In-place upgrades do not involve Virtual IP, and CM automatically drift Virtual IP during rolling upgrades.
• During the upgrade, do not change the values of wal_level, max_connections, max_prepared_transactions, and max_locks_per_transaction. If the value is changed, the instance fails to be started after the rollback.
• You are advised to perform upgrade when the database system is idle. You can determine the time (for example, holidays) based on experience.
• Before the upgrade, ensure that the database is normal. If your database was installed via PTK, you can run the ptk cluster -n <CLUSTER_NAME> status command to query the cluster status, Normal means that all instances of the cluster are available. If your database was installed via gs_om, you can run the gs_om -t status command to query the database status. If the value of cluster_state in the query result is Normal, the database is normal.
• Ensure that the database mutual trust is normal before the upgrade. You can run the ssh hostname command on any node to connect to another node for verification. If no password is required for the interconnection between hosts, the mutual trust relationship is normal. (Generally, the mutual trust relationship is normal when the database is running properly.)
• The database deployment mode (configuration files) cannot be changed before and after the upgrade. Before the upgrade, the deployment mode is verified. If the deployment mode is changed, an error is reported.
• The database is running properly and data on the primary node has been fully synchronized to standby nodes.
• Do not enable Kerberos during the upgrade.
• PTK has supported upgrades of database clusters with CM deployed since version 1.5.
• The cluster stream replication parameter enable_stream_replication needs to be set to on.

Notes For Each Version

Current Version 3.0.X

If the current database version is 3.0.X, you need to check for the existence of views that contain rownum and connect by syntax.

You can get the view definition and check if it has a rownum or connect by syntax by using the following command:

select pg_get_viewdef('viewname') def where def like '%ROWNUM%' or def like '%CONNECT BY%' ;

If such a view exists, you need to do the following:

1. Get the view definition.

   Select pg_get_viewdef('v1'); 

   v1 represents the name of the view where the rownum or connect by syntax exists.

2. Delete the related views.

   Drop view v1;

3. Rebuild these views using the original view definitions after the upgrade is complete.

   Create view as viewdef;

   viewdef represents the view definition queried in the first step.

   
   

Target Version 5.0.6

MogDB 5.0.6 supports parallel import/export, which relies on the new built-in plugin tidrangescan. after the upgrade is completed, if you need to use gs_dump, gs_restore parallel import/export feature, you need to manually create the tidrangescan plugin in the database where you want to do the import/export:

create extension tidrangescan;

Target Version 5.0.8

After upgrading the old version of MogDB to version 5.0.8, when using the dolphin extension to do union (set calculation) in the B-compatible database, all text types will be converted to text type (support for multiple union type inference and conversion to ensure that union returns a fixed type of result set). For the old version of the database using the dolphin extension, you need to do the adaptation of the client transformation.