2.0.1 Feature Introduction

MogDB 2.0.1 is a patch version of MogDB 2.0.0, which is released on July 8, 2021. It resolves the following issues upon MogDB 2.0.0:

Modified defects

• I3RCGU When synchronous_commit is set to off, transactions are continuously inserted to the host and are blocked for 1 to 2 seconds at intervals.
• I3R7IZ A core error may occur during log switchover because walsnd->mutex is repeatedly obtained.
• I3R7VH When a large number of transactions are continuously executed, archiving on the standby node fails.
• I3ROC6 000000010000000100000078.00000028.backup is generated in the pg_xlog directory on the primary node.
• I3RRIC In a cluster deployed with one primary and three standby nodes, the synchronization list is set to ANY 2(dn_6002, dn_6003, dn_6004), a large number of transactions are continuously executed, and the archiving function of standby node 1 is enabled. After the archiving is disabled and enabled again, the archiving function of standby node 1 is abnormal.
• I3S40U The pg_xlog of the standby node is not reclaimed.
• I3SPOW In primary/standby mode, gs_probackup fails to back up data when the archiving function is enabled.
• I3SUD0 When a cluster is scaled in to a standalone system, no is selected for restart, and then all nodes are scaled out, the database fails to be restarted. A message is displayed indicating that the standby node 1 is not in the cluster.
• I3SXC0 The online upgrade fails, and an error message is displayed indicating that the upgrade_from parameter fails to be set using gs_guc.
• I3T1TX In a cluster deployed with one primary node and one standby node, the synchronization list is set to * and the synchronization mode is set to off. The archiving function on the standby node fails, though it has been enabled.
• I3T4MG How do I use the pg_xlog archiving function on the standby node? Add the document description.
• I3T6IC OM is installed with one primary node and three standby nodes. The pg_xlog of the primary node starts from 0001, the pg_xlog of standby nodes 1 and 3 start from 0003, and the pg_xlog of standby node 2 starts from 0005. The pg_xlog of the primary and standby nodes are inconsistent.
• I3TDOA When archive_command for enabling the archiving function on the standby node is set to an incorrect address, the generated .ready files are inconsecutive. After archive_command is changed to a correct address, the added archives are still inconsecutive.
• I3R7IZ A core error may occur during log switchover because walsnd->mutex is repeatedly obtained.
• I3P07C Multiple nodes in the cluster are faulty, and gs_dropnode cannot be executed properly.
• I3J6MT The command for deleting a node fails to be executed, and an error is reported.
• I3RK0C When RTO is enabled, the node deletion command fails to be executed and an error is reported.
• I3QN9E Failed to manually run the online scaling command, and an error is reported.
• I3QZUG When the primary node is stopped, the scaling command fails to be executed and a message is displayed indicating that the command is incomplete.
• I3N0XQ A copy fails to be added to GaussDB, and an error is reported.
• I3S40U The pg_xlog of the standby node is not reclaimed.
• I3R7VH When a large number of transactions are continuously executed, archiving on the standby node fails.
• When a database is in the idle or low-load status, the CPU usage is relatively high.

New Functions

• Enhanced the Xlog archiving on the standby node and intelligent index recommendation capabilities.

• Logical replication allows users to set more filtering tables.

• Red Hat Enterprise Linux 7 is supported.