Cloned Instance Startup - laurynas-biveinis/mysql-5.6 GitHub Wiki

The current version of this page is at https://github.com/facebook/mysql-5.6/wiki/Cloned-Instance-Startup

After an in-place remote clone, the RocksDB data and WALs are in .rocksdb.cloned and .rocksdb.wal.cloned temporary directories respectively and must be moved to the final destination before the RocksDB initialization. For additional safety, any existing data in the destination is saved before the move and deleted afterwards.

But first, check if InnoDB has decided to rollback its clone, in which case rollback MyRocks clone too, regardless of anything else.

Then, before moving the temporary directories, check if the in-progress clone marker file .clone_in_progress is present in .rocksdb.cloned directory. Its presence means indicates the clone operation being incomplete, in which case startup aborts. As a corner case, an empty rocksdb.cloned directory is treated the same.

In the case of data (i.e. SST files), these operations are done at the directory level:

  1. The pre-existing RocksDB data directory (.rocksdb in default configuration) is moved to .rocksdb.saved. If the latter directory already exists, startup aborts.
  2. The cloned RocksDB data directory .rocksdb.cloned is moved to the configured instance data directory (e.g. .rocksdb).
  3. The saved .rocksdb.saved directory is removed.

Moving the logs into place would be handled in a similar way, but there is an additional complication that mysqld executable may not have the permissions to delete the rocksdb_wal_dir directory, only its contents, differently from rocksdb_datadir. To address this, for the rocksdb_wal_dir != rocksdb_datadir setup, moving the logs is done at a directory level below:

  1. Each pre-existing .log file under rocksdb_wal_dir is renamed to .log.saved.
  2. All the files from .rocksdb.wal.cloned are moved to rocksdb_wal_dir.
  3. .rocksdb_wal_cloned directory is removed.
  4. All files in rocksdb_wal_dir that end with .saved are removed. The rocksdb_wal_dir == rocksdb_datadir configuration is handled by a simpler move of .rocksdb_wal_cloned contents to rocksdb_datadir, where can be no pre-existing logs due to this directory having been just created and populated only with SSTs.