All Products
Search
Document Center

System configuration management

Last Updated: Jan 10, 2020

zone_merge_concurrency

If the value of the system configuration enable_merge_by_turn is set to true, the zone_merge_concurrency parameter is used to schedule merge operations.

The RootService node schedules merging operations based on the following rules:

  • Replicas of two zones are not merged if the replicas are exactly the same and the zones are in the same region and of the same type. Zones that require a longer merge time are merged with higher priority.
  • The RootService node uses different strategies based on the value of the zone_merge_concurrency parameter.
  1. zone_merge_concurrency = 0:

The RootService node sorts zones based on the merge time of the previous round. The RootService node starts merging zones that require a long merge time and does not control concurrency. Replicas of two zones are merged if the replicas are different or the zones are in different regions. In the optimal scenarios, each zone is in a different region, and replicas in all zones can be merged.

  1. zone_merge_concurrency > 0:

The RootService node sorts zones based on the merge time of the previous round. The RootService node checks zones that require a long merge time. Then, the RootService node selects zones that are in different regions from the zones being merged, zones that are in the same region but have different zone types, or zones that are in the same region but have different replicas. If the maximum concurrency is not reached, replicas in the zones are merged. If the maximum concurrency is reached, the RootService node stops checking.

major_freeze_duty_time

This parameter specifies the time to perform a daily freeze operation and upgrade the major version. The value range is [00:00-24:00]. The daily freeze and merge operations of an ApsaraDB for OceanBase cluster consume a specific amount of system resources such as CPU and I/O. We recommend that you specify an appropriate time during off-peak hours based on the characteristics of your business and the volume of daily memory increments.

For example, for a transaction-type business, you can set the value of this parameter to 02:00. For a business that runs at zero at night, you can set the value of this parameter to 05:00.

major_freeze_trigger_percentage

This parameter specifies the threshold that triggers a major freeze in an ApsaraDB for OceanBase cluster.

Calculation method: major_freeze_trigger_percentage = triggering threshold for major_freeze/capacity of MemStore

The capacity of MemStore is specified by the memstore_lmt_percent parameter.

Calculation formula: memstore_lmt_percent = memstore_limit/min_memory

ApsaraDB for OceanBase is similar to an in-memory database. If the memory is full and cannot be released in a timely manner, the database cannot properly provide services. If the memory is released too frequently due to major freezes, the performance of the entire system is compromised. We recommend that you configure this parameter based on the memory size of the server and the write speed required by your business.

minor_freeze_times

This parameter specifies the number of dumps. The number of dumps equals the number of minor freezes before a major freeze is triggered. If a major freeze fails to be triggered, a minor freeze is triggered to release an amount of memory.

  1. minor_freeze_times=0

If the value of this parameter is set to 0, the dump feature is disabled.

If too many dumps occur during the interval of two major freezes, the performance of the database is compromised. We recommend that you configure this parameter based on your business requirements.

memory_limit_percentage

This parameter specifies the percentage of server memory in proportion to the total memory. The server memory is used by an OBServer node to store the data that is added, deleted, or modified. ApsaraDB for OceanBase is similar to an in-memory database. If the memory is full and cannot be released in a timely manner, the database cannot properly provide services. We recommend that you configure this parameter based on the memory size of the server and your business requirements.

trace_log_slow_query_watermark

This parameter specifies the threshold to record a slow query in the trace log. The value range is [1 ms, +∞). If the speed of running SQL queries for the business is fast, only a few queries are slow. In this case, you can set a value between 100 ms and 1s for this parameter. In other cases, you can set a larger value for this parameter.

If you do not want ApsaraDB for OceanBase to record slow queries in the trace log, you can set a larger value for this parameter, for example, 50s.

max_syslog_file_count

This parameter specifies the maximum number of log files for an OBServer node. Outdated log files are automatically deleted. Each log file is 256 MB in size.

You must configure this parameter based on the capacity of the home disk of the system where ApsaraDB for OceanBase is installed. Note that if the value of this parameter is set to 0, the log files are not automatically deleted.

large_query_threshold

This parameter specifies the large query threshold of an ApsaraDB for OceanBase cluster. If the estimated execution time of an SQL query is greater than this threshold, the query is scheduled as a large query. We recommend that you configure this parameter based on your business requirements.

If the threshold is set to a small value, most queries are scheduled as large queries, which affects the response time of the system.

large_query_worker_percentage

The large_query_worker_percentage parameter specifies the percentage of worker threads used for large query processing. The large_query_worker_percentage parameter is used in combination with the large_query_threshold parameter. We recommend that you configure the large_query_worker_percentage parameter based on your business requirements.

For example, if the value of the large_query_worker_percentage parameter is set to 30, the ApsaraDB for OceanBase cluster uses 30% of the worker threads for processing large queries. In online transaction processing (OLTP) scenarios, you can set an appropriate value for this parameter to ensure that responses can be returned as expected.