MDEV-39091 BACKUP SERVER of ENGINE=RocksDB to the local file system

[Thirunarayanan]

Wire the RocksDB (MyRocks) engine into BACKUP SERVER TO and BACKUP SERVER WITH (streaming). RocksDB SST files are immutable, so a consistent point-in-time snapshot is obtained cheaply with a rocksdb::Checkpoint. The checkpoint is frozen at BACKUP_PHASE_NO_COMMIT because the checkpoint files are immutable, the actual copy is deferred to BACKUP_PHASE_FINISH, after the backup MDL has been released, and the server-side checkpoint is removed at end of FINISH. No user-level lock is needed: MDL_BACKUP_START already serializes concurrent BACKUP SERVER.

Files are copied into the target's "#rocksdb" subdirectory. The default rocksdb_datadir ("./#rocksdb") makes restore transparent: on restore the files land at /#rocksdb, so pointing a server at the extracted backup just works, with no copy-back and no RocksDB prepare step.

storage/rocksdb/rdb_backup_server.{h,cc}:
New RocksDB_backup context and the three handlerton hooks.
The checkpoint file list is drained across N CONCURRENT step threads via a lock-free atomic cursor; each file is copied with copy_entire_file() (directory target) or backup_stream_*(). Since SSTs are immutable, the sendfile(2) fast path (backup_stream_append_async) is used for the stream target.

rdb_create_checkpoint(): Factor the checkpoint creation
rdb_remove_checkpoint(): Remove the checkpoint creation logic.
rdb_get_datadir(): Get the rocksdb data directory.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[gemini-code-assist]

Code Review

This pull request implements BACKUP SERVER support for the RocksDB (MyRocks) storage engine, introducing new backup hooks to create consistent checkpoints and copy or stream the immutable checkpoint files. The review feedback highlights several critical issues: a potential security and correctness risk where an empty datadir could write to the root directory, potential backup corruption due to an unrestored file offset after calling lseek, a resource leak on backup abort because cleanup is only executed during the finish phase, and a potential crash on Windows if target.path is null.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

If rdb_get_datadir() returns nullptr or an empty string, dir will resolve to / after appending the slash, causing the checkpoint directory to be created at /mariabackup-checkpoint. This is a security and correctness risk as it attempts to write to the root of the filesystem. Defaulting to the current directory . when the datadir is empty or null is much safer.

  const char *datadir= rdb_get_datadir();
  if (!datadir || !*datadir)
    datadir= ".";
  std::string dir(datadir);

[dr-m]

rocksdb_datadir can never be nullptr. Elsewhere, it is assumed that it cannot refer to an empty string either, even though this might not be enforced:

std::string rdb_corruption_marker_file_name() {
  std::string ret(rocksdb_datadir);
  ret.append("/ROCKSDB_CORRUPTED");
  return ret;
}

[gemini-code-assist]

Using lseek(src, 0, SEEK_END) to determine the file size leaves the file offset at the end of the file. If the underlying implementation of backup_stream_append_async (or any fallback path) relies on the current file offset (e.g., using read() instead of pread()), it will read 0 bytes, leading to silent backup corruption. The file offset must be restored to the beginning of the file using lseek(src, 0, SEEK_SET) before proceeding.

    uint64_t end= uint64_t(lseek(src, 0, SEEK_END));
    if (lseek(src, 0, SEEK_SET) == (off_t)-1 ||
        backup_stream_start(sink.stream, rel.c_str(), 0644, end, nullptr, 0) ||
        backup_stream_append_async(src, sink.stream, 0, end))

[gemini-code-assist]

If the backup is aborted, rocksdb_backup_end is called with BACKUP_PHASE_ABORT. Currently, the cleanup logic (removing the checkpoint and deleting the bk context) is only executed when phase == BACKUP_PHASE_FINISH. This causes a memory leak and leaves stale checkpoint directories on disk when a backup fails or is aborted. The cleanup should be performed on both BACKUP_PHASE_FINISH and BACKUP_PHASE_ABORT.

  if (phase == BACKUP_PHASE_FINISH || phase == BACKUP_PHASE_ABORT)
  {
    bk->remove_checkpoint();
    delete bk;
  }

[dr-m]

This looks mostly OK to me. The interesting part is RocksDB_backup::copy_one(), which copies or streams a file.

We are lacking some test coverage.

[dr-m]

This is failing on Windows:

backup.backup_rocksdb                    w8 [ fail ]
        Test ended at 2026-07-15 12:53:53
CURRENT_TEST: backup.backup_rocksdb
mysqltest: At line 47: query 'BACKUP SERVER WITH 2 CONCURRENT '$script'' failed: ER_IO_WRITE_ERROR (1811): IO Write error: (2, No such file or directory) BACKUP SERVER

Curiously, for the CMAKE_BUILD_TYPE=Debug build on Windows, this test is being skipped:

backup.backup_rocksdb                    w15 [ skipped ]  Test requires MyRocks engine

[dr-m]

If the streaming tools are missing, we’re skipping all test coverage, even though it is technically possible to cover backup to a mounted file system.

[dr-m]

We might want to reduce the peak memory usage.

[dr-m]

Instead of implementing this function, please rebase the branch to and use either variant of backup::copy_or_stream() that were implemented in 69dad73.