Fix telemetry.json not updating after configuration change

Environment

• Version: OceanBase seekdb (r) (Built 100000222026032420-bde98aeaa8740119c4a2aa420138c838312e6708 Mar 24 2026)
• Is this an RD-provided temporary version?: No
• Reproducibility: Always reproducible
• Test Change: Normal installation via RPM, after successful startup, executed: alter system set memory_limit='4g';
• Other anomalies/changes on the environment?: No
• Environment Information: Please provide connection strings for the problematic tenant and the sys tenant, deployment information. Is the scene preserved?
• Log Information:

Description

The telemetry data file telemetry.json does not update after modifying the system configuration memory_limit.

Steps to Reproduce

1. Install and start OceanBase seekdb normally via RPM.
2. Execute the SQL command: alter system set memory_limit='4g';
3. Observe the telemetry.json file. Its modification timestamp remains unchanged, and the memoryLimit field inside still shows the old value (e.g., "2G").

Details

• The modification time of the telemetry file telemetry.json is Mar 27 17:11. Verified at 2026-04-02 17:37:17, the file's modification time had not updated, and the corresponding memoryLimit field was still "2G".
• The memory_limit configuration was successfully changed to "4g" at 2026-03-27 17:31:37.619459, as confirmed by querying DBA_OB_ROOTSERVICE_EVENT_HISTORY.

File Listing and Content (2026-04-02 17:37:17)

[heshun.lxd4--2026-04-02 17:37:17 /data/1/oceanbase/seekdb/run]$ ls -lrt
total 12
-rw-rw-r--+ 1 root users 591 Mar 27 17:11 telemetry.json
lrwxrwxrwx  1 root users  15 Mar 27 17:31 seekdb -> /usr/bin/seekdb
-rw-------+ 1 root users   7 Mar 27 17:31 seekdb.pid
srwxr-xr-x+ 1 root users   0 Mar 27 17:31 sql.sock
srwxr-xr-x+ 1 root users   0 Mar 27 17:31 daemon.sock
-rw-r--r--+ 1 root users   7 Mar 27 17:31 daemon.pid
srwxr-xr-x+ 1 root users   0 Mar 27 17:31 lua.sock

[heshun.lxd4--2026-04-02 17:37:19 /data/1/oceanbase/seekdb/run]$ cat telemetry.json | jq .
{
  "content": {
    "id": "8331F63A2E0BECC33E2606B2A45EF83FF7E30FDD434FE4828B78E96534407F5B",
    "host": {
      "os": "alinux",
      "cpu": "Intel(R) Xeon(R) Platinum 8369B CPU @ 2.90GHz",
      "cpuCount": 8,
      "osVersion": "3",
      "memorySize": "61.1645927G"
    },
    "event": "bootstraped",
    "version": "%",
    "instance": {
      "port": 62881,
      "hostHash": "12CA17B49AF2289436F303E0166030A21E525D266E209267433801A8FD4071A0",
      "createTimestamp": 1774602670401611
    },
    "reporter": "systemd",
    "resource": {
      "cpuCount": 4,
      "logDiskSize": "0G",
      "memoryLimit": "2G",
      "dataFileSize": "0.03125G"
    },
    "telemetryVersion": 1
  },
  "component": "seekdb"
}

Confirmation of Configuration Change (2026-03-27 17:31:37.619459)

[heshun.lxd4--2026-04-02 17:37:28 /data/1/oceanbase/seekdb/run]$ seek oceanbase
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 3221645612
Server version: 5.7.25 OceanBase% seekdb (r) (Built 100000222026032420-bde98aeaa8740119c4a2aa420138c838312e6708 Mar 24 2026)

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [oceanbase]> select usec_to_time(1774603897619459),* from DBA_OB_ROOTSERVICE_EVENT_HISTORY where event like '%config%' and value2 like '%memory_limit%' \G
*************************** 1. row ***************************
usec_to_time(1774603897619459): 2026-03-27 17:31:37.619459
                    TIMESTAMP: 1774603897619459
                      MODULE: root_service
                       EVENT: admin_set_config
                       NAME1: ret
                      VALUE1: 0
                       NAME2: arg
                      VALUE2: {name:"memory_limit", value:"4g", comment:"", zone:"", server:"%:0", tenant_name:"", exec_tenant_id:1, tenant_ids:[], want_to_set_tenant_config:false}
                       NAME3: is_inner
                      VALUE3: False
                       NAME4:
                      VALUE4:
                       NAME5:
                      VALUE5:
                       NAME6:
                      VALUE6:
                 EXTRA_INFO:
1 row in set (0.006 sec)

MySQL [oceanbase]>

Other

Note on issue classification for externally reported business-side problems:

• Customer Service Feedback: Refers specifically to problems before production deployment/POC issues, clearly identified as product bugs requiring fixes and release versions.
• Online Issue: Problems that have occurred after production deployment, clearly identified as product bugs, but not defined as failures.
• Online Failure: Problems that have occurred after production deployment, clearly identified as product bugs, causing business errors or public opinion impact on the customer side (the interpretation of whether it's a failure belongs to the delivery service team).

Start by locating the code that generates telemetry.json and the handling of the alter system set memory_limit='4g' configuration change. Reproduce the issue with the documented RPM setup, then trace why the telemetry file is not regenerated; done means its timestamp changes and resource.memoryLimit reflects the new value.