Clean Up Data Storage

Overview

This page describes how to remove orphaned binary data from the content repository data store in Bloomreach Content.

Purpose

Eliminate unused binary data (orphaned blobs) from the repository's data store to reclaim storage space.

When to Use

Use this procedure when you need to clean up binary data that is no longer referenced by any nodes in the repository. This is relevant if your repository stores large binaries in a separate database table and you want to ensure that unused data does not accumulate.

How Binary Data Storage Works

In Bloomreach Content, binaries larger than a configurable threshold are stored in a dedicated database table. Multiple nodes with identical binary properties reference the same blob entry to optimize storage. When a property referencing a blob is removed, the system does not automatically check if the blob can be deleted from the data store. As a result, orphaned binaries may remain in the database.

The Checker Tool provides a janitor option that identifies and removes these orphaned binaries.

Prerequisites

Access to the environment where the repository is running.
The Checker Tool downloaded and configured.
- For brXM 16+, use version 3.1.1 or higher.
Sufficient permissions to run maintenance operations on the database.

Procedure: Clean Up Binary Data Using the Checker Tool

Download and configure the Checker Tool as described in the Checker Tool documentation.
- For brXM 16+, ensure you use version 3.1.1 or later.

Run the data store cleanup command:

java -jar hippo-addon-checker-<version>.jar cleands

This command scans the data store for binary blobs that are no longer referenced by any repository nodes and removes them.

Chunked Deletion for Large Data Stores

The cleanup deletes orphaned binaries in chunks instead of with a single DELETE statement. Each binary is deleted in its own transaction, so the cleanup does not exceed database transaction size limits, such as MySQL group replication's group_replication_transaction_size_limit, on a large data store.

Requires a Checker Tool version 4.3.0 or higher. The repository configuration generated by the config command already uses the chunked deletion.
If you use a checker-repository.xml created with an earlier version, change the class attribute of the DataStore element from org.apache.jackrabbit.core.data.db.DbDataStore to org.apache.jackrabbit.core.data.db.CheckerDbDataStore.
Set the chunk size with cleands.delete.chunksize in checker.properties (default 1000). The chunk size only bounds memory use and how often progress is logged. Setting it to 0 deletes all orphaned binaries with a single statement, as in earlier versions.
Progress is logged per chunk, for example Deleting binaries not modified since [timestamp] in chunks of 1000, followed by Processed chunk 1 ending at id [...].

Additional Steps for MySQL InnoDB

The InnoDB storage engine in MySQL does not automatically shrink its data files after data is deleted. To reclaim disk space after running the cleanup, perform an OPTIMIZE TABLE operation on the relevant tables.

Verification

Confirm that the Checker Tool reports successful removal of orphaned binaries.
Check database storage metrics to verify that space has been reclaimed (after running OPTIMIZE TABLE if using InnoDB).