I am making use of Redmine a web based software tracking tool, its perfect for my needs. However, I keep coming across this error in my production.log.
ActiveRecord::StatementInvalid
(Mysql::Error: MySQL server has gone
away: SELECT * FROM issue_relations
WHERE (issue_relations.issue_from_id
= 6) ): app/models/issue.rb:234:in after_save'
app/controllers/issues_controller.rb:196:in
edit'
When I add a ticket or update a ticket I get the below error and the above is recorded in my logs. It returns this via the browser after about 15 seconds. I have tried it several times, other areas of the app work fine.
Internal error
An error occurred on the page you were
trying to access. If you continue to
experience problems please contact
your redMine administrator for
assistance.
Back
I am using Ruby on Rails 2.3.8 on Phusion Passenger. Gem version 1.3.7. Active record 2.3.8. mysql (2.8.1 ruby x86-mingw32 x86-mswin32, 2.7.3 mswin32).
I am not a Ruby on Rails programmer and I am at loss on what else I can do to narrow this down. I had quick Google and found that as of rails 2.3 there is an option to reconnect so in my database.yml file I placed a reconnect true, but this didn't help!
Thanks all for any help
The list of usual suspects: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html (all checkable on the MySQL-side of things).
Try putting the code from this Gist in a file in {rails application}/config/initializers/active_record_connections.rb: http://gist.github.com/238999
That said, this should probably not be happening in the first place - and if requests are taking 15 seconds to load, that also suggests that something else is going on. Can you share what appears in the logs before this error?
Related
I'm using Flask Security Too (https://flask-security-too.readthedocs.io/en/stable/index.html) to authenticate users on a test server. I followed the instructions in the documentations to get it up and running. It all works perfect, however for some reason the application is losing the connection to the MySQL server and starts returning an Internal Server Error. In Sentry I see the following error message:
(sqlalchemy.exc.InvalidRequestError) Can't reconnect until invalid transaction is rolled back
[SQL: SELECT anon_1.user_id AS anon_1_user_id, anon_1.user_email AS anon_1_user_email, anon_1.user_first_name AS anon_1_user_first_name, anon_1.user_last_name AS anon_1_user_last_name, anon_1.user_password AS anon_1_user_password, anon_1.user_last_login_at AS anon_1_user_last_login_at, anon_1.user_current_login_at AS anon_1_user_current_login_at, anon_1.user_last_login_ip AS anon_1_user_last_login_ip, anon_1.use...
This error usually appears when the site has not been accessed for several hours during night. Restarting the Flask app solves the problem.
I tried changing the SqlAlchemy options, without success. Since I'm using a MySQL database on a dedicated server I also tried using a local MySQL database, I'm having the same issue here.
I would like to solve this issue before spending more time on integrating this into my website.
Does anyone know what can cause this problem?
I have seen this (and there have been bugs) when using psycopg2 - where a PRIOR error (such as select on a column with an incompatible type - causes the connection to permanently be unusable. From my testing - there wasn't an obvious way to even know this had happened until the query that throws this error - since it was a coding error - I fixed a few bugs in that area. Note that was with psycopg2 - which I don't think you are using.
I would look at logs or turn on complete mysql query logging to look at what might be querying it during the evening.
Another thought - which I don't think would cause THIS error - is that many DBs drop connections after some period of time out. Make sure you are using Flask-SQLAlchemy 2.4.0 or greater and put in the config:
app.config["SQLALCHEMY_ENGINE_OPTIONS"] = {"pool_pre_ping": True}
which will make sure the connection is valid PRIOR to returning the connection to be used.
I'm trying to update a rails application on our production server to ruby 1.9. We have several production sites, some of which have more critical uptime requirements so it would be really beneficial to update each site one at a time to ensure the least amount of downtime on the more critical sites.
Phusion Passenger 4 allows to easily run sites using different ruby versions which would be great functionality for ensuring a staggered transition to 1.9 (and later 2.0). Currently the server is working under Apache module Passenger 3.0.11 and using the system ruby-1.8.7-352.
To start the update I have installed rvm and ruby-1.9.2-p320. Using the new ruby I install passenger 4.0.10. I then updated the httpd.conf with:
LoadModule passenger_module /path/to/mod_passenger.so
PassengerRoot /path/to/gems/passenger-4.0.10
PassengerDefaultRuby /path/to/ruby-1.9.2-p320/ruby
Then in the site.conf
PassengerRuby /path/to/old/ruby
This means that the sites should be using the system ruby, just as before, and the only thing to be updated is Phusion Passenger. The result is that the production applications have started throwing ActiveRecord::StatementInvalid exceptions maybe once every 3000 requests. The exception rate is obviously higher during high traffic periods. The error is as follows:
Exception Class: ActiveRecord::StatementInvalid
Message: Mysql2::Error: Lost connection to MySQL server during query: SELECT ...
I have example of the error on several pages but mostly on those with "large" sql queries (maybe up to 0.4 second query, 1.7 sec request).
I have since restored the httpd.conf with the old passenger and the errors have ceased.
Can anyone help diagnose the source of the query deaths?
Thanks.
=== Edit 1 ===
I've tried adding PassengerSpawnMethod direct to httpd.conf so it now reads:
LoadModule passenger_module /path/to/mod_passenger.so
PassengerRoot /path/to/gems/passenger-4.0.10
PassengerDefaultRuby /path/to/ruby-1.9.2-p320/ruby
PassengerSpawnMethod direct
but still have the same error occurring with seemingly the same frequency.
=== Edit 2 ===
I've also tried out of desperation installing passenger 4.0.10 under the system 1.8 ruby with the same results. Is there anything more I can do or should I just assume passenger isn't ready to be updated? Is there anything I can look for in my code that could be causing this? I've checked mysql error logs and there's nothing. Can anyone suggest anything else worth looking at? As for moving forward I'm not planning to spend much more time on this, I'll be testing the production site under ruby 1.9 over weekends and just bite the bullet and move them all over under passenger 3.
=== Edit 3 ===
I've now setup passenger so there is only one passenger process for each application under passenger 4. There are still these errors! So not a spawning/multiple access problem. I can't see passenger messing with the application connection to the db but passenger is the only thing I'm changing. I'm using the standard msyql2 gem for my rails app. The requests that are failing are largish select queries (on the order of a second to complete).
Having updated my apps to ruby 1.9 the errors have ceased. I never found out what was causing them but I wanted to answer here in case anyone else runs into the same problem.
I had the same issue, but not with phusion. Turned out these "larger" queries were being killed by the ActiveRecord connection pool reaper (reaping_frequency config). See: https://stackoverflow.com/a/22423893/72176
Not sure if this is your issue as it seems yours fixed itself, but if others have this error message – that is definitely one avenue to check.
I'm working on my first rails app deploy and the database data from my local computer doesn't seem to be getting loaded into the database on the server when I deploy with capistrano. I'm not clear as to whether capistrano takes care of this or not. I have also tried running 'rake db:schema:load' from the /current release directory. Here's the log of what happens when I try to load the app (on the remote webserver) in a browser.
Started GET "/" for XX.XX.XX.XX at 2012-04-04 13:26:46 -0700
Processing by PagesController#home as HTML
Completed 500 Internal Server Error in 3ms
ActiveRecord::StatementInvalid (Mysql::Error: Table 'project.users' doesn't exist: SHOW FIELDS FROM `users`):
app/models/user.rb:61:in `authenticate_with_salt'
app/helpers/sessions_helper.rb:50:in `user_from_remember_token'
app/helpers/sessions_helper.rb:13:in `current_user'
app/helpers/sessions_helper.rb:17:in `signed_in?'
app/controllers/pages_controller.rb:5:in `home'
So the problem seems to be that the app loads, but the DB isn't populated with tables and data.
I'm sure I'm missing a relatively basic detail of the deployment process, but thus far it escapes me... Any help would be mucho appreciated! Thanks.
What does your Capfile look like?
Neither Rails nor Capistrano will copy data from your development environment to your deployment environment—db:migrate:* and db:schema:* only handle database structure. Before using rake db:schema:load make sure your development environment migrations have been run and your latest db/schema.rb is checked in to your repo.
If you want certain data to be in your database upon deployment look in db/seeds.rb. There are also many gems for seeding database data.
After upgrading several parts of my Rails app (Ruby 1.9.2, Rails 3.0.4, Datamapper 1.1.0) and moving to Passenger Standalone, we started getting weird MySQL connection errors, including:
Field-count mismatch
Lost connection to MySQL server during query
MySQL server has gone away
Then I remembered that Passenger forks processes and you need to re-open new connections for things like redis, memcache, etc. or the data stream will get garbled, and I found another post regaling similar adventures due to the same problem with MySQL.
But I also recalled reading here that Passenger took care of the database connections automatically.
So I have two questions:
1) How do I tell DataMapper to create and use a new database connection? And/or:
2) Does forking Passenger take care of the forking database connections automatically or not? For fork's sake... ;)
To answer #2, no, Passenger itself does not handle closing file handles after forking. You have to manage it yourself, unless your gem does it for you.
To answer #1, I cobbled together some things I found. Add to environment.rb and let me know if it works!
if defined?(PhusionPassenger)
PhusionPassenger.on_event(:starting_worker_process) do |forked|
if forked
# We're in smart spawning mode.
DataObjects::Pooling.pools.each do |pool|
pool.dispose
end
else
# We're in direct spawning mode. We don't need to do anything.
end
end
end
I got a OSX Server, i updated it to 10.6.5 from 10.6.4.
Since then my Ruby on Rails Application (leihs) gibes me an Error.
"your config/databse.yml may not be written correctly. Please check it and fix any errors.
Your databse schema may be out of date or nonexistant. ....
The database server may not be running. Please check whether it's running, and start if it isn't
Error message:
Can't connect to local MySQL server through socket '/var/mysql/mysql.sock' (2) (Mysql:error)
Then a looong list of backtraces whitch dont really help me.
The Socket file does NOT exist, and i cant find it on other places.
Please help me, this is making me crazy.
Thanks for your time & help
I appears that your mysql server is not running. You should debug that portion of your system before looking at your rails app.
A few things to checK:
Can you connect from the command line?
Are there startup errors in your mysql log file?
Did you change IP addresses, share names or anything else that might have stuffed your mysql install?
I solved the Problem!
Reinstalling the 10.6.5 Combo Update helped.
-Download the correct Combo Update (same version (server/normal), same build)
-Stop the Services (like Web and so on..)
-Install the Update
-Restart
-Start Services
-All should work again
Thanks to all of you guys for their help.