Running MTR Tests for MyRocks

This page describes an outsider' view of running MTR tests for MyRocks Storage Engine.

Running the tests

As mentioned in the Build-Steps, you need to pass several options to {{mysql-test-run}}. It is convenient to have a script

cat > rocksdb-mtr.sh <<EOF
#!/bin/bash -x

./mysql-test-run --mysqld=--default-storage-engine=rocksdb \
  --mysqld=--skip-innodb --mysqld=--default-tmp-storage-engine=MyISAM \
  --mysqld=--rocksdb "\$@"
EOF
chmod +x rocksdb-mtr.sh

Sizing

Tests are CPU and memory-heavy.

Running with --mem

This is the faster option. Known issues are:

rocksdb.persistent_cache will fail an assertion https://github.com/facebook/mysql-5.6/issues/579
Some tests require a lot of disk space. The biggest hogs seem to be rocksdb.bulk_load{,_rev_cf,_rev_cf_and_data} each of which will require require about 2.4G of disk space. It's easy to run out of space in /dev/shm and then these (or other) tests will fail with an error and/or assertion failure.
Ballpark figures for test runtime: --parallel=2 takes 60 min, --parallel=4 takes 30 min.

Running without --mem

Is slow, even on SSD.

These tests may not not finish within the default 900-seconds time limit:

rocksdb.rocksdb_deadlock_stress_rr (1249 sec)
rocksdb.rocksdb_table_stats_sampling_pct_change (write_prepared: 1060 sec)
rocksdb.blind_delete_without_tx_api (write_preared: 1223 sec)
rocksdb.rpl_read_free (1592 sec)

These tests may not finish even with 1800 seconds time limit:

rocksdb.deadlock 
rocksdb.drop_table2
rocksdb.bloomfilter
rocksdb.drop_table
rocksdb.optimize_table
rocksdb.rocksdb_deadlock_stress_rc
rocksdb.commit_in_the_middle_ddl