Note
For V4.2.0, this parameter is available starting with V4.2.0.
Description
The ls_gc_delay_time parameter specifies the duration for which the log streams of a tenant are delayed before being deleted.
OceanBase Database V4.2.0 introduced a load balancing module based on log splitting and merging. This allows the database to scale out and scale in. When you scale in OceanBase Database, logs that meet the garbage collection (GC) conditions are removed, and the corresponding log storage is cleared.
In addition, OceanBase Database has implemented physical standby databases based on the network starting with V4.2.0. When the source primary or standby tenant has not enabled log archiving and the database undergoes a scaling down operation, the log stream will be quickly cleared. This can lead to overall log synchronization being held up due to the recycling of logs. Therefore, you need to configure the delay time for log stream deletion for the source primary or standby tenant using this parameter.
Privilege requirements
Query the parameter
The
systenant and all user tenants can query this parameter by executing theSHOW PARAMETERSstatement or querying theGV$OB_PARAMETERSview.Modify the parameter
You can use the
systenant or a user tenant to modify the parameters.
Attributes
| Attribute | Description |
|---|---|
| Type | Time |
| Default value | 0s, indicating that the log stream delay delete mechanism is no longer applicable.
NoteStarting from V4.2.1 BP1, the default value has been adjusted from 3600s to 0s. |
| Value range | [0s, +∞) |
| Modifiable | Yes. You can use the ALTER SYSTEM SET statement to modify the parameter. |
| Effective upon OBServer node restart | No. The setting takes effect immediately. |
Considerations
In physical standby scenarios:
If logs are not archived for the primary or standby tenants on the source, and the default value of the
ls_gc_delay_timeparameter is 3600s (1 hour), the log delayed deletion mechanism is activated, with a delay period of 1 hour for the log streams.If log archiving is enabled for the primary or standby tenant of the source database, the log stream data integrity is guaranteed by log archiving. Therefore, the garbage collection (GC) of the log streams is not affected by this parameter. In this scenario, the log delay deletion mechanism does not take effect, regardless of the value of the
ls_gc_delay_timeparameter.
For a scenario where a tenant is deleted, the log stream delayed deletion mechanism will not take effect regardless of the value of the
ls_gc_delay_timeparameter.Note
The only data that remains after deletion is the log stream entities. Whether the log files of the log stream can be retained depends on the available disk space for the current tenant. If the available disk space is insufficient, log recovery will still be triggered.
Examples
Specify the delay period before a tenant log stream is automatically deleted in the sys tenant.
obclient> ALTER SYSTEM SET ls_gc_delay_time='7200s' TENANT = 'mysql_tenant';You can set the delayed deletion time of the log stream for the current user tenant.
obclient> ALTER SYSTEM SET ls_gc_delay_time='7200s';