New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make some options dynamically configurable #43
Comments
Comment by jkedgar Does this mean that you want a global variable in MyRocks so that you can configure this option by using "Set rocksdb_bytes_per_sync = "? What other options should be this way? |
Comment by yoshinorim I'd like to start from dynamically configurable DB options. Static options such as wal_dir, rocksdb_data_dir are not targets. For CF/Table options, I think we need more discussions. |
Comment by jkedgar Is there a list of dynamically configurable options? |
Comment by yoshinorim |
Comment by siying Search options.h and all dynamic configurable options will write in comments "dynamic changeable". |
Comment by jkedgar The SetOptions() method appears to operate on a column family - the default column family if no column family is specified. Do I need to iterate through all the column families when an option is set via MySQL or do I just set it for the default column family? The bytes_per_sync setting does not appear to be dynamically configurable. It is not listed as such in options.h and doesn't show up in util/options_helper.cc. Am I missing something? |
I didn't receive any comments on my questions. The questions are again:
|
cc @yoshinorim |
|
|
DBOptions are not dynamically changeable. eg. bytes_per_sync and rate_limiter |
So there are database-wide options that are not dynamically changeable and there are some column family options which are dynamically changeable. Here's a list of the options that I see that are dynamically configurable: Memtable options:
Compaction options:
Miscellaneous options:
How many of these make sense to change via MySQL 'SET' statements? And should they be global across the entire database or should we have some way of setting them for different column families (indexes)? |
After getting confirmation that I do have to update each column family to set any of these values as well as information that the rate limiter option is set-able using a different method, I've been thinking more about how this will work. My assumption is that calling Also, if I think I probably need to keep track of the current set options for the database so that if a new column family is created (via a new index), I can set the options for this column family to match the rest of them. Does that sound correct? |
In MySQL-land SET options only exist for the life of the process. MySQL On Wed, Sep 30, 2015 at 9:28 AM, Jay Edgar notifications@github.com wrote:
Mark Callaghan |
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue #43 (#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Fix issue #42. Also issue #43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue #43 (#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Fix issue #42. Also issue #43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue #43 (#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Test Plan: mtr t/rocksdb_range.test, used gcov to check the new code is covered Reviewers: maykov, hermanlee4, jonahcohen, jtolmer, yoshinorim Reviewed By: yoshinorim Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue mysql#43 (facebook/mysql-5.6#43) Test Plan: MTR with expanded rocksdb_rate_limiter_bytes_per_sec_basic.test Reviewers: maykov, yoshinorim, hermanlee4 Reviewed By: hermanlee4 Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 274226e
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 274226e
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 48004e0
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 274226e
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 1a1e8075190
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 1a1e8075190
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 1a1e8075190
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 1a1e8075190
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103 fbshipit-source-id: 7ed432226c3
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339 fbshipit-source-id: 1a1e8075190
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
…lumn family Summary: Fix issue facebook#42. Also issue facebook#43: Ranges on t.key > const are not handled efficiently: Make ha_rocksdb::index_read_map() do the right thing when invoked with find_flag=HA_READ_KEY_OR_NEXT, both for forward and reverse column families. Detailed explanation of actions is provided in rocksdb-range-access.txt Differential Revision: https://reviews.facebook.net/D35103
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue facebook#43 (facebook#43) Differential Revision: https://reviews.facebook.net/D48339
Summary: Currently rocksdb_rate_limiter_bytes_per_sec can only be used to set up a rate limiter during startup. If the bytes_per_sec value needs to change after startup, that is not possible. Change this to allow for this possibility. If no rate limiter was setup during startup you won't be able to start and if one is set up during startup you won't be able to disable it. But if one is set up during startup the value for the bytes_per_sync will be changeable Issue percona#43 (facebook/mysql-5.6#43) Differential Revision: https://reviews.facebook.net/D48339
Issue by yoshinorim
Friday May 29, 2015 at 00:18 GMT
Originally opened as MySQLOnRocksDB#74
Some options like rocksdb_bytes_per_sync should be configurable dynamically.
The text was updated successfully, but these errors were encountered: