Skip to main content

Check Space and Clean Metadata Tables in the Built-in NineData MetaDB

This article describes space checks and metadata table cleanup for the built-in MetaDB in all NineData Community Edition versions, including older versions, and all Dedicated Cluster versions. External MetaDB deployments are out of scope. The cleanup procedure empties entire tables and does not filter records by task. Confirm the target instance, backup, and cleanup conditions before proceeding.

Retrieve the MetaDB Username and Password​

Run the commands for the relevant deployment type in a terminal with access to the deployment host. These commands apply to deployments that use the standard container and namespace names documented by NineData. If the container or namespace was customized, first adjust the commands to match the actual deployment configuration.

Community Edition​

docker exec -it ninedata sh -lc "kubectl get cm jzcloud-console-config -n ninedata -o jsonpath='{.data.spring\.datasource\.druid\.username}'"
docker exec -it ninedata sh -lc "kubectl get secret ninedata-secret -n ninedata -o jsonpath='{.data.mysqlPassword}' | base64 -d"

Dedicated Cluster​

docker exec -it ninedata sh -lc "kubectl get secret mysql-privsecrets -n ninedata -o jsonpath='{.data.clusterAdminUsername}' | base64 -d"
docker exec -it ninedata sh -lc "kubectl get secret mysql-privsecrets -n ninedata -o jsonpath='{.data.clusterAdminPassword}' | base64 -d"

The password commands print the password in the terminal. Run them only in a controlled terminal. Do not copy the password into tickets, chats, documents, screenshots, or logs.

Access MetaDB from the Console​

Use the MetaDB data source already registered in the console to access the built-in MetaDB. You do not need to enter the password again in the SQL window.

  1. Sign in to the NineData console.

  2. In the left navigation, click "SQL Console".

  3. Open the existing MetaDB tab in the SQL window. The database list contains information_schema and replication_metastore.

  4. Confirm that the current database is information_schema, then run this read-only query in the SQL editor to view the data and index space values for each table in replication_metastore. The result is in MiB:

    SELECT TABLE_NAME,
           ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS SIZE_MIB
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA = 'replication_metastore'
    ORDER BY DATA_LENGTH + INDEX_LENGTH DESC;

The result comes from MySQL information_schema table metadata and does not represent free space on the host file system. Space usage changes across instances and over time. Do not use values from a screenshot of another environment as a cleanup threshold for this instance.

To connect to MySQL from the command line, first confirm the MetaDB service address and port from the actual deployment configuration. This article does not provide a generic mysql -h command.

Clean Metadata Tables​

The following steps clean entire tables. They do not delete only records associated with terminated or deleted tasks. TRUNCATE empties all data in the target table; do not treat it as a task-filtered deletion.

  1. Confirm that the connection is to the built-in MetaDB and that the target tables exist in replication_metastore. Do not use these steps for an external MetaDB.

  2. Back up replication_metastore using the backup procedure for the deployment type, and confirm that the backup is recoverable before continuing.

  3. If space is insufficient and you need to clear column metadata, run:

    TRUNCATE TABLE replication_metastore.capture_meta_column;

    Then verify that the table is empty:

    SELECT COUNT(*) AS row_count
    FROM replication_metastore.capture_meta_column;

  4. Only after confirming that all replication tasks have ended or been deleted, and if index metadata space still needs to be reclaimed, run:

    TRUNCATE TABLE replication_metastore.capture_meta_index;

    Then verify that the table is empty:

    SELECT COUNT(*) AS row_count
    FROM replication_metastore.capture_meta_index;

  5. Do not clean capture_meta_ddl, capture_meta_table_revision, or capture_meta_table.

  6. After cleanup, rerun the space query in this article and verify that the target table row count is 0 and its space value has changed accordingly. If the result differs from expectations or a task behaves abnormally, stop further operations and follow the backup recovery procedure.

The cleanup rules apply to the built-in MetaDB versions in this article's scope. Table schemas can differ between versions; confirm that the target table exists and recheck the backup before executing. Do not apply these commands to other capture_meta_* tables.