Edit 2021-02-21: I've confirmed this solution works with both heroku-18 and heroku-20 stacks.
What follows is my solution for having mysql2
gem compiled and working against MySQL v5.7 (rather than v8+) on the heroku-20
stack. This is how I've managed to make it work:
- Add the apt buildstack ahead of your standard buildpack (in my case, that's Ruby):
$ heroku buildpacks:add --index 1 heroku-community/apt
- Create an
Aptfile
in the root of your project, and add the MySQL 5.7 client tools (as a URL for the deb file) to it:
# in Aptfile:
https://cdn.mysql.com/Downloads/MySQL-5.7/libmysqlclient-dev_5.7.32-1ubuntu18.04_amd64.deb
- Ensure that the
mysql2
gem compiles using the Apt-provided library (viaBUNDLE_BUILD__MYSQL2
) and that, when the library loads, it knows how to find libstdc++ (viaLD_PRELOAD
). I've found thatLD_PRELOAD
isn't already set to anything in my apps - but yours may be different, so do check before running this command.
$ heroku config:set \
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 \
BUNDLE_BUILD__MYSQL2=--with-mysql-config
- Update your app to use the
heroku-20
stack if you haven't already:
$ heroku stack:set heroku-20
- Deploy this Aptfile to your app, and it should work. If the gems are cached from a previous build (for example, if you had already changed the stack and deployed other changes), you will need to clear your build cache prior to deploying, to ensure the
mysql2
gem is recompiled.
If anyone has any questions or thoughts about this, do let me know.
Hi Conor, great to know things have been super stable for you :) and those are great questions!
With regards to the
mysql2
gem, my understanding is that it can be compiled for either v5.7 or v8 support, but not both. Sphinx prior to the v3.1.1 release only supported MySQL v5.7 client libraries (and I realise it's worth noting, for anyone not aware: Sphinx's main query approach uses the MySQL protocol, hence this dependency).Flying Sphinx doesn't have Sphinx v3.3.1 available, only v3.1.1 and v3.0.3 of the 3.x releases. Unfortunately, I've found that all v3.x releases do not work well when you're using PostgreSQL as your database and with SQL-backed indices. This is the most common approach for Flying Sphinx customers (understandably, given the ease of using PostgreSQL on Heroku), hence I've held off on adding v3.3.1 to the Flying Sphinx servers.
It's also important to note that - at least at this point - Flying Sphinx's servers are all expecting the MySQL v5.7 protocol, and I'm not sure if v8 will work at all. Managing both protocols at the same time isn't something I've yet looked into, and I strongly recommend sticking with v5.7 protocols (and thus, using this gist's approach).
With all of that in mind, I recommend one of the three options:
:with => :active_record
in your index definitions). This means the changes outlined in this gist are required, because you must use the MySQL v5.7 client libraries.ts:index
) of indices doesn't need to happen so often (ideally the callbacks cover all changes, but it's good to have reprocessing take place nonetheless - especially if you're adding/editing data in ways that don't fire ActiveRecord callbacks).Thinking Sphinx, even the latest v5 releases, continues to support Sphinx v2.2.11. But upgrading Thinking Sphinx to v5 will not change which version of the MySQL client libraries are required. That's entirely tied to Sphinx/Manticore versions. If/when you do upgrade, please see the documentation about what must be changed - v5 removed implicit callbacks, so you'll want to add them in yourself.
Managing Sphinx/Manticore versions for Flying Sphinx apps is all done via
config/thinking_sphinx.yml
and theversion
andengine
keys. For example:The defaults are Sphinx and v2.2.11 for all new apps. Older apps may have a different (older) Sphinx version if they've not configured one.
I hope this covers all of your questions - but certainly do ask if there are things I've missed :)