I compiled MyRocks for MySQL 8 on Ubuntu 20.04 and will soon use it for performance tests. I did this because I am upgrading my NUC cluster to Ubuntu 20 and am not willing to get an older gcc toolchain on it to build MyRocks in MySQL 5.6 from source. It took a few hours to figure this out, but that is a one time cost.
This explains how to build from the Facebook MySQL fork in Github. I suggest that everyone else use MariaDB or Percona Server if they want to try MyRocks. I write posts like this because I am likely to need this information in the future.
The steps are:
- Install dependencies listed here. I might be missing a few as I did this on an install I have been using for a while and might have installed others in the past.
- Get the source from github
- Checkout the 8.0.17 branch via git checkout remotes/origin/fb-mysql-8.0.17 -b fb8017
- cd fb8017
- Get RocksDB source via git submodule init; git submodule update
- Get Boost 1.69. The previous step installed it as a submodule but I wasn't able to use it and just copied it from elsewhere.
- mkdir build; cd build
- Run cmake via this script. The script is good for me. It might not be good for you. But it is important to set extra compile flags for RocksDB, otherwise you risk having a non-performant build. See problem 4 below. The script expects Boost 1.69 to be copied to $BUILD/../boost_1_69_0
Problems:
- This is harder than it should be but the FB MySQL tree isn't meant for the community to build from. It is there to share diffs with the community.
- Some RocksDB #defines don't have ROCKSDB_ as a prefix so there is a greater chance of conflict with code from elsewhere
- I wasn't able to figure out how to get the Boost submodule working so I copied Boost 1.69 from elsewhere
- Some RocksDB compilation flags that are used for a pure-RocksDB build are not used in the MyRocks build and this can hurt performance. So I build RocksDB directly and copy some of the flags from there into my cmake script. This is a hassle and is error prone, but again, this source tree isn't mean for community builds
One hint that you have a non-performant RocksDB build is this string in the LOG file
Fast CRC32 supported: Not supported on x86
While this string is OK:
Fast CRC32 supported: Supported on x86
Hi Mark,
ReplyDeleteWhy do you modify "CMAKE_CXX_FLAGS"? All "ROCKSDB_" flags should be set automatically.
My "cmake" parameters are following:
-DCMAKE_BUILD_TYPE=$BUILD
-DBUILD_CONFIG=mysql_release
-DFEATURE_SET=community
-DREPRODUCIBLE_BUILD=OFF
-DENABLE_DOWNLOADS=1
-DDOWNLOAD_BOOST=1
-DWITH_BOOST=../_deps
-DWITH_SYSTEM_LIBS=ON
-DWITH_MECAB=system
-DWITH_NUMA=ON
-DWITH_LZ4=bundled
-DWITH_ZSTD=bundled
Regarding boost there are 2 options:
1. Use "-DDOWNLOAD_BOOST=1" like for upstream and allow cmake to download it automatically.
2. Use "boost" submodule with -DWITH_BOOST='./boost'
The flags below are set for pure-RocksDB builds (just RocksDB, no MySQL) but not set for RocksDB built as part of MySQL. Some of them are significant if you care about performance, like using a fast CRC-32. I didn't try to confirm whether all are significant.
DeleteAs I write in the blog post, check the RocksDB LOG file for the message about CRC-32 or profile your mysqld binary. Or do "make VERBOSE=1" to see which flags are used for RocksDB when MyRocks is compiled. You want to have something like -march=native.
I tried -DWITH_BOOST=../boost but that didn't work. Will try again today. I am not a fan of "download during build" (thus I am not a fan of Maven) so I didn't try that.
Checking email, I have debugged problems like this a few times for my builds, and a few years ago for Percona & MariDB MyRocks -- MyRocks isn't easy to build.
-faligned-new
-fno-builtin-memcmp
-march=native
-DHAVE_ALIGNED_NEW
-DHAVE_AVX2
-DHAVE_BMI
-DHAVE_LZCNT
-DHAVE_PCLMUL
-DHAVE_SSE42
-DHAVE_UINT128_EXTENSION
-DNUMA
-DROCKSDB_AUXV_GETAUXVAL_PRESENT
-DROCKSDB_BACKTRACE
-DROCKSDB_JEMALLOC
-DROCKSDB_MALLOC_USABLE_SIZE
-DROCKSDB_PTHREAD_ADAPTIVE_MUTEX
-DROCKSDB_RANGESYNC_PRESENT
Hi Mark, you recommend using the MariaDB or Percona version, but you do not explain why you are not using one of these yourself, could you share this with us ? Thanks, JFG
ReplyDeleteI use it today because I used it yesterday. Even more, I used to support it in production so I know it. For MariaDB I don't want to deal with the switching costs -- small things change and disrupt my scripts, build and more has changed.
DeleteWhen I spend my limited time on things that are different, I prefer to focus on things that are very different rather than moving sideways. For example, this year I learned a lot about Postgres and MongoDB.