By default, RocksDB’s information logs residence in the same directory as your database. Look for for the most recent log file, and LOG.* files for older ones. If you’ve explicitly set option.db_log_dir, find the logs there. The log file names will be contain information of the paths of your database.

Some users have overridden the default logger or use non-default ones and they’ll need tp find the logs accordingly. If options. Be aware that the default log level is INFO. With DEBUG level you’ll see more information, and with WARN level less.

With the default logger, a log line might look like this:

After the timestamp, 7fef48069300 is the thread ID. Since usually a flush or compaction happens in one same thread, the thread ID might help you correlate which lines belong to the same job. shows the source file and line number where the line is logged. It might be cut short to avoid long log lines. default is the column family name.

Start with examining the data with get and scan commands. These commands will only examine keys visible to users. If you want to examine invisible keys, e.g. tombstones, older versions, you can use idump command. Another useful command is manifest_dump, which shows the LSM-tree structure of the database. This can help narrow down the problem to LSM-tree metadata or certain SST files.

If you use a customized comparator, merge operator or Env, you may need to build a customized for it to work with your database. You can do it by building a binary which calls LDBTool::Run() with customized options, or register your plug in using object registry before calling the function. See ldb_tools.h for details.

To examine a specific SST file, use sst_dump tool. Starting with scan to examine the logical data. If needed, command raw can help examine data in more details.

See —help and for more details about the two tools.

We use github issues only for bug reports, and use RocksDB’s Google Group or for other issues. It’s not always clear to users whether it is RocksDB bug or not. Pick one using your best judgement.

To help the community to help more efficiently, provide as much information as possible. Try to include:

• Your environment.
• The language binding you are using: C++, C, Java, or third-party bindings.
• Options used (e.g. paste the option file under the DB directory).
• Findings when examining the database with or sst_dump, related statistics, etc.
• You can even consider to attach the information files. Data itself is not logged there.

When reporting bugs, MyRocks’s bug reporting guidelines might be helpful too.

For performance related questions, it may be helpful to check .