This topic provides an overview of the new features introduced in OceanBase Database V3.1.5, along with the enhancements and modifications made to the previous versions of OceanBase Database.
V3.1.5_CE_HF1
Version information
- Release date: June 19, 2023
- Version: V3.1.5_CE_HF1
- RPM version: oceanbase-ce-3.1.5-100010012023060910
Overview
This version addressed several customer and internal testing issues to enhance product stability.
Bug fixes
- Fixed the issue where the
PARAM INFOfield of the__all_virtual_plan_stattable was not deeply copied, which resulted in the generation of a core dump file in the case of access to an invalid memory address. - Fixed the issue where an excessive number of rows were returned by the TABLE LOOKUP operator in the table access by index primary key operation, which resulted in the generation of a core dump file in the case of access to an invalid memory address.
- Fixed the issue where partition pruning was not supported when a time type column was used as a partitioning key and the query condition was not an equation.
V3.1.5_CE
Version information
- Release date: April 19, 2023
- Version: V3.1.5_CE
- RPM version: oceanbase-ce-3.1.5-100000252023041721
Overview
OceanBase Database Community Edition V3.1.5 is officially released 10 months later after the release of its previous version. The new version focuses on improving the stability of the kernel. In terms of features, OBKV supports hotkey-based throttling, while OBCDC has a lower resource requirement for machines owing to the architecture optimization. To meet user requirements for wide tables, the limit on the number of columns in a single table is increased from 512 columns to 4,096 columns. Issues reported by users and found in internal tests are also fixed in this version.
Feature updates
Hotkey-based throttling
OBKV supports hotkey-based throttling. You can set a throttling threshold. The database then implements throttling when the queries per second (QPS) values of the top K rowkeys exceed this threshold. The new version uses a smooth gradient partial throttling scheme, which prevents simple traffic cut-off. TableAPI and HBase operations are supported.
Key capabilities include:
The tenant-level
kv_hotkey_throttle_thresholdparameter is added, which allows you to set the OBKV throttling threshold. The default value is0and the value range is [0, 1000000000000000000L]. When the threshold is set to0, the throttling feature is disabled. When the threshold is set to a value greater than 0, a rowkey whose QPS value is greater than the threshold within an epoch (2s) will be throttled in the next epoch.The
__all_virtual_kv_hotkey_statvirtual table is added, which records the top K hotkeys that are throttled.The
GV$OB_KV_HOTKEY_STATview is added, which records the top K hotkeys. You can view information about all tenants from the sys tenant. However, you can view only the information about the current tenant from a user tenant. You can query theGV$OB_KV_HOTKEY_STATview for information about all OBServer nodes, and query theV$OB_KV_HOTKEY_STATview for information about the current OBServer node.
Architecture optimization for OBCDC
The earlier versions of the synchronization link system OBCDC have high requirements on machine performance, including the memory size and disk performance. In OceanBase Database Community Edition V3.1.5, the OBCDC architecture has been optimized, to reduce memory usage and dependency on resources and improve database performance and stability.
More columns supported for a single table
The maximum number of columns supported for a single table is increased to 4,096. The wide table design reduces table associations and improves database query performance and data processing capabilities.
Note
A table with a primary key supports 4,096 columns. A table without a primary key supports 4,095 columns, because the system will generate a hidden primary key for the table.
Support for setting the maximum space for clog storage to an absolute value
In earlier versions of OceanBase Database, the maximum space for clog storage can only be set to a percentage of disk space, which cannot accurately represent the disk usage in some shared storage scenarios. OceanBase Database Community Edition V3.1.5 allows you to set the maximum space for clog storage to an absolute value, which is more flexible and easier to use.
The cluster-level startup parameter
log_disk_sizeis added, which specifies the maximum space available for storing clog files on a single OBServer node. The value range is [0G, + ∞). The default value is0G, which indicates that the entire disk is available for storing clog files.- If
log_disk_sizeis set to a negative value or a value greater than the total disk size, the OBServer node fails to be initialized. In this case, modify this parameter and restart the OBServer node for the modification to take effect. - When
log_disk_sizeis set to a value greater than 0, the maximum space available for storing clog files is calculated by using the following formula: Value oflog_disk_sizex Available space of the disk in percentage. In previous versions, the maximum space available for storing clog files is calculated by using the following formula: Total disk space x Available space of the disk in percentage.
- If
To adapt to the Python Django framework, the system variable
default_storage_engineis added. The default value isOceanBase.
Other changes
The default value of the tenant-level parameter undo_retention is changed from 0 to 1800, indicating that multi-version data is retained for 1,800 seconds during a minor compaction by default.
Bug fixes
- Fixed the issue where hints were missing when SQL statements were rewritten.
- Fixed the issue where a read-only replica failed to be converted into a full-featured replica.
- Fixed the issue where clog playback was stuck during tenant restore.
- Fixed the issue where archiving failed to be enabled for a tenant being restored.
- Fixed the issue where the memory was used up when indexes were created for JSON-generated columns.
- Fixed the issue where a core dump occurred on the OBServer node in some special scenarios.
- Fixed the issue where SQL statements were stuck during partition adding operations.
- Fixed the issue where the content read from read-only views could not be written to other tables.
- Fixed the issue where the index status was not as expected after restore.
- Fixed the issue where the JSON type data failed to be converted into the INT type data.
- Fixed the issue where the standby database failed to be restarted due to slog replay errors.
- Fixed the issue where the execution of
INSERT INTO IGNOREwas stuck. - Fixed the issue where a major compaction was stuck and the
buffer not enougherror was reported. - Fixed the issue where data backup failed because zone backup took too long.
- Fixed the issue where the same SQL statement had different execution plans and returned different results.
- Fixed the issue where a backup failed to be forcibly canceled and the backup status stayed at "Stopping".
- Fixed the issue where a
datafile_sizescale-out did not take effect on some OBServer nodes. - Fixed the issue where physical restore sometimes failed after schema history recycling was enabled.
- Fixed the issue where the query result data was garbled when multiple data entries were inserted into a table with mixed character sets by using the
REPLACE INTOstatement. - Fixed the issue where KVCache could not be cleared due to insufficient memory during the execution of a stored procedure with over 0.6 billion entries of data.
- Fixed the issue where the
replica is not readableerror was occasionally returned for the full-featured replica, resulting in time-consuming queries. - Fixed the issue where when an automatic cleanup task was normally scheduled, back pieces that were expected to be cleaned up were not deleted.
- Fixed the issue where the
from_base64()parameter was incompatible with MySQL when it was set to a line feed or tab character. - Fixed the issue where Error 4016 was returned for the
select NULLIF(NULL, '') from dualstatement when PreparedStatement was enabled. - Fixed the issue where Error 5024 was returned for the
insert ... on duplicate key updatestatement, indicating duplicate primary keys. - Fixed the issue where the
observer.logfile had a large number ofFail to erase key from cacheerrors. - Fixed the issue where duplicate empty constraint names caused the
schema hangerror. - Fixed the issue where the
ORA-00904: invalid identifiererror was returned when a cursor used a ROWID alias in PL. - Fixed the issue where when a primary/standby switchover was initiated while a backup cleanup task was in the Doing state, Error 4016 might be reported for the cleanup task that resumed after the switchover.
- Fixed the issue where after the
SELECTstatement called a formal parameter user-defined function (UDF), the system could not identify the parameter passing field in theSELECTstatement that was nested in theGROUP BY…HAVINGaggregate function.