CODEWITHSUNDEEP
ruby-on-rails-3.2thinking-sphinx
Jerome
Jerome

Reputation: 6189

Thinking Sphinx not accessing local index

A rails 3.2.18 with thinking_sphinx 3.1.1 is being passed from development to production mode. In the process, while any of the following work:

bundle exec rake ts:rebuild
bundle exec rake ts:index
bundle exec rake ts:stop
bundle exec rake ts:start

searches are ending up with 

ActionView::Template::Error (unknown local index [...]

I initially realised that I hade 2 search pids running on the application because development had a shared directory in which the sphinx indicies and tmp/pid file were placed. That was being carried over and therefore creating two pids: one from within the shared folder, another within the application release's shared folder. Duh!

still a ps aux | grep searchd is returning two processes for
/fna/shared/config/development.sphinx.conf The pids does not match that in the shared folder and they call development Another application, still in development (!) also has two processes

1) is it normal to have two processes?
2) how to get the pids to start for the production.shpinx.conf (and get rid of incidental pollution) ?

I realise this may also be impacted by the capistrano deployment and would welcome suggestions to get matters done properly.

Update ps ax | grep "searchd" gave proper active pids to

kill 99335

ran

RAILS_ENV=production bundle exec rake ts:rebuild
[...]
Started searchd successfully (pid: 7086)

now two pids are for the proper environment

shared/config/production.sphinx.conf

and redeployed. with success. so the remaining doubt is in capistrano deployment. Given that indexing is run nightly (and is acceptable as such), should the deploy.rb file include:

invoke_command "cd #{release_path} && RAILS_ENV=#{rails_env} bundle exec rake ts:rebuild"

Upvotes: 0

Views: 434

Answers (1)

pat
pat

Reputation: 16226

You don't need to run ts:rebuild after every deploy - it's like db:migrate, it's only needed when you change the structure of your indices, or add/remove indices. If you just want to update the data in the indices, use the ts:index task (as you're doing regularly already).

It's worth making sure your paths are set up correctly to ensure all production Sphinx files are outside of a specific release directory - best to put them in the shared directory or something similar (rather than relying on symlinked files). If this is all set up, then no TS tasks need to be run as part of a deploy.

Also: Thinking Sphinx v3 uses Sphinx's threaded workers, so there's always at least two processes - one being the master, and one waiting for the first connection. If there are more concurrent connections, then there are more searchd processes.

Upvotes: 1

Related Questions