Escalation Impact and Escalation Constraints
Note the following items during the upgrade process.
The upgrade operation cannot be performed at the same time as capacity expansion and contraction.
Virtual IPs are not supported.
During the upgrade process, the values of the four GUC parameters, wal_level, max_connections, max_prepared_transactions, and max_locks_per_transaction, are not allowed to be modified. If modified, it will cause the instance to start abnormally after rollback.
It is recommended to upgrade the database system when it is idle, and try to avoid the busy time period (you can judge according to experience, such as holidays, etc.).
Ensure that the database is normal as much as possible before upgrading. It can be queried through gs_om -t status. The cluster_state of the query result is Normal, which means the database is normal.
Before the upgrade, ensure that the database mutual trust is normal. You can connect to another node through the ssh hostname command on any node for verification. If there is no need to enter a password for the interconnection between the machines, it means that the mutual trust is normal (usually when the database status is normal, the mutual trust is generally normal).
Before and after the upgrade, the deployment method (configuration file) of the database cannot be changed. The deployment method will be verified before the upgrade, and an error will be reported if it is changed.
Before upgrading, ensure that the operating system is in a healthy state. The gs_checkos tool can be used to complete the operating system status check.
The in-place upgrade needs to stop the business, while the grayscale upgrade supports full-service operation.
The database is running normally and the data of the primary DN is fully synchronized to the standby DN.
The kerberos switch is not allowed to be turned on during the upgrade.
Please do not modify the version.cfg file extracted from the installation package.
If an exception occurs during the upgrade process and the upgrade fails, the user needs to manually roll back, and the next upgrade can only be performed after the rollback is successful.
If the upgrade rolls back successfully and the upgrade is successful again, the GUC parameters set in the uncommitted stage will become invalid.
Please do not manually set GUC parameters during the upgrade process.
During the grayscale upgrade, the service interruption will not exceed 10s during the upgrade.
During the upgrade process, the om operation must be performed only when the kernel version is consistent with the om version. The consistency here means that both the kernel code and the om code come from the same software package. If the pre-script of the upgrade package is executed but not upgraded, or the pre-script of the baseline package is not executed after the upgrade is rolled back, it will cause inconsistency between the kernel code and the om code.
If new fields are added to the system table during the upgrade, \dthese new fields cannot be viewed through commands after the upgrade. selectAt this time , these newly added fields can be found through the command.
The upgrade requires the guc parameter enable_stream_replication=on, and the upgrade is not allowed when the parameter is off.
In the gray scale upgrade, the business concurrency should be less than 200 concurrent reads plus 200 concurrent writes.
If the MOT table is used in versions earlier than openGauss2.0.0, the upgrade to openGauss2.0.0 is not supported.
During the upgrade process, please do not install other opengGauss database clusters on the current machine.
During the upgrade, the template0 library will be connected, and an error will be reported when executing create database during the upgrade.
The openGauss shared storage mode does not support version upgrades.
PL/Java Upgrade Constraints
When upgrading from 3.0.0 and earlier versions to 3.1.0 and later versions, if the business uses the PL/Java function and the java environment does not exist on the machine where the database instance is located, the pre-upgrade check will fail. Therefore, it is necessary to confirm in advance whether to use the PL/Java function and the current JAVA version. The check method is:
Execute the "select count(1) from pg_proc where prolang = 15;" command in the database using the initialization user.
If the result is > 0, it means that the database uses PL/Java. Refer to 2 to further check whether there is a Java environment.
If result = 0, the database is not using PL/Java. Then end this verification and execute other verification processes.
Execute the "java -version" command as user root on the operating system.
java -version
If Java exists, and the version is equal to or higher than JDK1.8, then end this verification and perform other verification processes.
If Java does not exist or the version is lower than JDK1.8, you need to refer to 3 to download JDK and configure Java environment variables.
Download the JDK and configure the Java environment variables.
You can download it from the official website or use this link: https://www.hikunpeng.com/zh/developer/devkit/compiler/jdk, and configure environment variables in the following way:
export JAVA_HOME=/xxx/jdk1.xxx
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
illustrate:
The JDK directory and version need to be replaced according to the actual path and version number.
The upgrade check only verifies the Java environment variables of the node that executes the upgrade command. If other nodes also need to use PL/Java, please download the JDK and configure the Java environment variables simultaneously, otherwise PL/Java will not be available.
Top comments (0)