If you’re using Heroku, then you cannot install Sphinx directly within your application. There is an add-on that allows you to use Sphinx with your Heroku apps though: Flying Sphinx.
Essentially, the following steps need to be performed for a deployment:
- stop Sphinx
searchd(if it’s running)
- generate Sphinx configuration
- start Sphinx
- ensure index is regularly rebuilt
Configuring Sphinx for our production environment includes setting where the PID file and the index files are stored. In your
config/thinking_sphinx.yml file, set up the following additional parameters:
Please make sure all of the above files (configuration file, pid file, index files, binlog path) are located in a shared directory (instead of a directory tied to a specific deployed release). Otherwise, running rake tasks will become difficult and unreliable.
Symlinked directories are strongly discouraged as an alternative to (or in combination with) shared paths. Symlinked paths can be translated to release-specific paths when generating configuration, and this can lead to data inconsistency problems.
Thinking Sphinx v1/v2
Note: If you are using an older version of Thinking Sphinx, then the file is
config/sphinx.yml, and the second setting is
searchd_file_path (and the third and fourth can be skipped):
You’ll want to make sure that the application shared folder has
tmp subdirectories (or whatever is appropriate for your settings). You’ll also want to double check the permissions of these folders so that the user the application and searchd both runs as can write to both folders.
Before deploying, we generally assume that the Sphinx
searchd search daemon is running. You may need to manually configure and run the daemon the first deployment with ThinkingSphinx support added.
Deploying With Capistrano
Deploying via Capistrano is simplified by the included recipe file that comes with the ThinkingSphinx plugin.
The first step is to include the recipe in order to define the necessary tasks for us:
Thinking Sphinx v1/v2
Note: If you are using an older version of Thinking Sphinx and you've not set your paths up to be outside of a specific deployed release directory, then you'll need to add some extra code to your
deploy.rb file to make sure that Sphinx is properly configured, indexed, and started on each deploy.
It is far better, though, to use the configuration options mentioned above and avoid release-specific paths.
The above makes sure we stop the Sphinx
searchd search daemon before we update the code. After the code is updated, we reconfigure Sphinx and then restart. You should also setup a `cron` job to keep the indexes up-to-date.
Regularly Processing the Indices
One of the side effects of the Sphinx indexing methodology is that it is necessary to regularly process your indices in order to be able to search with recent changes. In order to do this, we set up a
cron job to run the appropriate command.
/etc/crontab file, add the following line to the bottom:
Also, you can use the whenever gem to control your Cron tasks from the Rails app. The same job for
config/schedule.rb looks like this: