MIRA Options are not reflected in OPTIONS and LOG files

[sgerbino]

When setting values in database.cfg the corresponding OPTIONS and LOG files produced by RocksDB do not contain those values. Since rocksdb_advisor uses those files to make tuning suggestions it is important for us to address this.

The function maybe_create_schema() creates the database initially with default values and these are reflected in the LOG and OPTIONS files.

Later during execution, we open the database with user configuration and it does not show or produce files, however they seem to be applied.

[Gandalf-the-Grey]

they seem to be applied

I'm afraid that they aren't
I can't see the difference in runtime even with ridiculous settings like:

  "base": {
    "optimize_level_style_compaction": true,
    "increase_parallelism": true,
    "max_write_buffer_number": 4,
    "min_write_buffer_number_to_merge": 2,
    "max_bytes_for_level_base": 1024,
    "target_file_size_base": 1024,
    "block_based_table_options": {
      "block_size": 8,
      "cache_index_and_filter_blocks": true,
      "bloom_filter_policy": {
        "bits_per_key": 100,
        "use_block_based_builder": false
      }
    }

And now I actually have a proof that they aren't:

rocksdb_witness_object/LOG:2019/12/06-12:17:39.052289 7ff8c23f1f00 [WARN] [db/column_family.cc:738] [boost::mpl::v_item<steem::chain::by_id, boost::mpl::vector0<mpl_::na>, 0>] Stopping writes because we have 2 immutable memtables (waiting for flush), max_write_buffer_number is set to 2

Even if we assume that it does not show the option, in above example you can see that warning message show value of max_write_buffer_number set to 2 while in configuration it's set to 4.

Steps to reproduce: I just let it run for some more time and wait for WARN messages that prints current value of a variable that's set to a different than default value.