Purge view_log table

Hello everyone,

While digging through the files on my MySQL server used by Metabase, I discovered the view_log.ibd file, which corresponds to the view_log table. From what I've read, this table was used with version 0.50 and then became an option available only in the Enterprise version. No problem with this idea, except that the table takes up 4.8 GB on my disk, and I have no idea what procedure to follow to purge it and free up space on my server.

Just in case, I did a SELECT on this table, and the last record dates from 2024-07-15. Is there any documentation on how to purge this table?

{
  "browser-info": {
    "language": "fr",
    "platform": "Linux x86_64",
    "userAgent": "Mozilla/5.0 (X11; Linux x86_64; rv:134.0) Gecko/20100101 Firefox/134.0",
    "vendor": ""
  },
  "metabase-info": {
    "databases": [
      "mysql"
    ],
    "run-mode": "prod",
    "plan-alias": "",
    "version": {
      "date": "2024-11-04",
      "tag": "v0.51.2",
      "hash": "8bdb22c"
    },
    "settings": {
      "report-timezone": "Europe/Paris"
    },
    "hosting-env": "unknown",
    "application-database": "mysql",
    "application-database-details": {
      "database": {
        "name": "MariaDB",
        "version": "10.5.15-MariaDB-0+deb11u1"
      },
      "jdbc-driver": {
        "name": "MariaDB Connector/J",
        "version": "2.7.10"
      }
    }
  },
  "system-info": {
    "file.encoding": "UTF-8",
    "java.runtime.name": "OpenJDK Runtime Environment",
    "java.runtime.version": "11.0.15+10-post-Debian-1deb11u1",
    "java.vendor": "Debian",
    "java.vendor.url": "https://tracker.debian.org/openjdk-11",
    "java.version": "11.0.15",
    "java.vm.name": "OpenJDK 64-Bit Server VM",
    "java.vm.version": "11.0.15+10-post-Debian-1deb11u1",
    "os.name": "Linux",
    "os.version": "5.10.0-14-amd64",
    "user.language": "fr",
    "user.timezone": "Europe/Paris"
  }
}

Thank you in advance.

That is still available but it used to keep the data forever but then the default was set to 2 years:

Only pro are able to change that ... In terms of what needs to be done from your end simply drop the rows from a point you don't need. Say if you want to only keep the last 4 months just drop everything before that.

Always make sure to take a backup just in caser!

1 Like

Thank you for your response.

Indeed, modifying this environment variable is reserved for the pro version. In my case, I am still using the community version and I have well over 2 years of recordings.

MariaDB [metabase]> select MAX(timestamp) from view_log;
+----------------------------+
| MAX(timestamp)             |
+----------------------------+
| 2024-07-15 10:25:48.000000 |
+----------------------------+
1 row in set (0.000 sec)

MariaDB [metabase]> select MIN(timestamp) from view_log;
+----------------------------+
| MIN(timestamp)             |
+----------------------------+
| 2021-06-07 17:10:48.000000 |
+----------------------------+
1 row in set (0.000 sec)

I have the impression that the maximum duration of 2 years is not being respected. Would a truncate deletion solve the problem, and what could be the side effects?

For the audit_log table, I have the same phenomenon.

MariaDB [metabase]> select MAX(timestamp) from audit_log;
+----------------------------+
| MAX(timestamp)             |
+----------------------------+
| 2023-12-11 11:31:16.000000 |
+----------------------------+
1 row in set (0.019 sec)

MariaDB [metabase]> select MIN(timestamp) from audit_log;
+----------------------------+
| MIN(timestamp)             |
+----------------------------+
| 2021-05-27 14:52:32.000000 |
+----------------------------+
1 row in set (0.001 sec)

Philippe

No side effects, just truncate the table

1 Like