ob_tenant_long_trans_exist

Description

This alert is triggered when the duration of a transaction on the OBServer exceeds the threshold. The default threshold is 1200 seconds.

Principle

The following table describes the key parameters that are involved in the monitoring and alerting logic.

Note

The system parameter ocp.alarm.datasource.trans-min-duration-seconds specifies the transaction duration threshold, in seconds, that triggers an alert. The value of long_trans_max_duration_seconds must be equal to or greater than the value of this system parameter. The default value is 60 seconds.

Alert rule

Alert information

Alert templates

• Alert overview

  • template: ${alarm_target} ${alarm_name}

  • Example: ob_cluster=obcluster-2:tenant_name=orac2:trans_hash={hash:10801753558860391353, inc:59202486, addr:"192.168.0.1:2882", t:1646993121179509}. A long-running transaction exists in the OceanBase Database tenant.

• Alert details

  • Template: Cluster: ${ob_cluster_name}; Tenant: A long-running transaction exists in the ${tenant_name} tenant; Session ID: ${session_id}; Transaction ID: ${trans_hash}; Transaction Type: ${trans_type}; Transaction Created At: ${trans_create_time}; Maximum Transaction Duration: ${value_shown}.

  • Example: Cluster: obcluster; Tenant: A long-running transaction exists in the orac2 tenant; Session ID: 3221635048; Transaction ID: {hash:10801753558860391353, inc:59202486, addr:"192.168.0.1:2882", t:1646993121179509}; Transaction Type: distribute; Transaction Created At: 2022-03-11T18:05:21.184+08:00; Maximum Transaction Duration: 25 days 19 hours 57 minutes and 24.66 seconds.

Impact on the system

Long-running transactions cause serious data jams and lock timeouts, affecting the execution of other transactions.

Possible causes

Long-running transactions are likely to occur when the cluster is leaderless because the candidates fail to receive the majority of votes from other nodes in the cluster during the leader election (the "minority problem"), the disk is full, the memory is used up, or large transactions are under processing.

Solutions

1. Check for the minority problem.

   The minority problem occurs because of OBServer exceptions or network failure. It also triggers the ob_cannot_connected alert at the same time.

   In that case, you need to first solve the problem of the ob_cannot_connected alert by referring to the corresponding topic. Then, check whether the ob_tenant_long_trans_exist alert is cleared 5 minutes later.

2. Check the disk space.

   Insufficient disk space also triggers the following alerts at the same time. We recommend that you first solve the problems that caused the following alerts by referring to the respective topics, and then check whether the ob_tenant_long_trans_exist alert is cleared 5 minutes later.

   • ob_host_data_disk_percent_over_threshold

   • ob_host_log_disk_percent_over_threshold

   • ob_host_install_disk_percent_over_threshold

3. Check the memory.

   Insufficient memory may also trigger the alert of memory usage exceeding the threshold at the same time. For more information, see ob_host_mem_percent_over_threshold.

4. Check for large transactions.

   On the Performance Diagnostics page of the OCP console, click the TopSQL and SlowSQL tabs to check for suspicious SQL statements such as long-running SQL statements.

   If any, analyze the cause of the problem and optimize the SQL statements based on the diagnosis result. You can also consider splitting a large transaction into small transactions as needed.

5. If the problem persists despite the preceding operations, run the following commands and send the result to OceanBase Technical Support for troubleshooting.

   -- View the information of all servers to see if a server is faulty.
   select * from __all_server;
   
   -- View the long-running transaction.
   SELECT *
   FROM __all_virtual_trans_stat
   WHERE is_exiting !=1 AND part_trans_action <= 2 AND ctx_create_time < DATE_SUB(NOW(), INTERVAL 1200 SECOND)
   LIMIT 100;