Reporting bugs and asking for help

Reporting bugs

First of all, thank you for taking the time and reporting any issues with the product you have experienced! Bug reports help us to improve the product and make things better for all the users. To make sure that we can investigate and fix any issues quickly, it will be very helpful to add the following information to the bug report:

Details about MyRocks

• Version of MyRocks: If you are using MyRocks directly from the FB MySQL branch then tell us what git hashes were used via mysql -e 'show global status' | grep -i hash and tell us the values for git_hash and rocksdb_git_hash. These are also written to the database error log.
• Did you link with jemalloc, tcmalloc or glibc malloc? MyRocks performs much better with tcmalloc or jemalloc. If you aren't sure then try nm /path/to/mysqld | grep -i jemalloc and nm /path/to/mysqld | grep -i tcmalloc
• If this is a performance problem then we frequently want to see the output from mysql -e 'SHOW ENGINE ROCKSDB STATUS' after mysqld has been running for a while.
• We usually ask for configuration information returned by mysql information_schema -e "select * from global_variables where variable_name like 'rocksdb%'" and mysql information_schema -e "select * from rocksdb_cf_options"
• In the worst case we might ask for information written to the RocksDB LOG file at $datadir/.rocksdb/LOG

Operating system used. Getting this information varies between the OS-s, but generally you can do the following:

• Linux: uname -a or depending on the particular distribution you may choose to include the output from lsb_release -a or cat /etc/redhat-release or cat /etc/fedora-release as well.
• OS X: uname -a.
• Windows: ver or systeminfo | findstr /c:"OS".

Type of the build used. Given that different types of builds are supported then it'll helpful to specify if it was (for example in case of MySQL) Debug, RelWithDebInfo or Release build. Please also mention what was the state of the source tree when product was built, e.g., last Git commit in your repo. If you have made any local code changes then it will be good to describe them as well, e.g., "After adding a call to printf() in foo() I noticed that bar() started crashing with SIGSEGV.

Steps to reproduce a bug. Please indicate if the problem can be consistently reproduced or it just happens occasionally. Having a set of precise steps is the most important part of the bug report, so please document what commands with what specific parameters you executed; what was the output; is there a specific sequence of SQL statements or any other commands which causes the issue to happen; any other observations you can make.

Going the extra mile! If you had a chance to debug the issue (either using gdb, lldb, Visual Studio, WinDBG etc.) then any type of debugging information like stack traces, values of local variables in the relevant stack frame, process memory usage, mutex contention etc. will help us to reach the root cause of the problem faster.

Armed with all that information the only left to do is to create a new issue!

Asking for help

If you have any questions about the design decisions or you notice something weird with the product or have a proposal for the new API call which will help you then a preferred way for communicating is to use the Facebook group or e-mail list associated with the particular product.

• MySQL: MySQL on RocksDB (Public) and MyRocks e-mail list.
• RocksDB: RocksDB Developers Public on Facebook and RocksDB e-mail list.

Members of our engineering teams are part of the groups relevant to their area of expertise and are more than willing to help you to debug and work through various issues.