-
Notifications
You must be signed in to change notification settings - Fork 675
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
slow dumping of mysql in production #10
Comments
You can inform this option in your configuration file using 'additional_options' like this:
|
This isn't really an issue, but we could perhaps just implement that this is default behavior. What are the pros en cons of using |
As far as I know you almost always want to use |
Thanks for pointing that out, I will mark this as a consideration. Might be a good idea set these options as defaults. |
Mysql doesn't support transactions, some storage engine does, like InnoDB. I don't think this option should be enabled by default, because other people uses other storage engines. |
Good point, I did not know that. In that case it's not wise to set it as default since it will literally break MySQL adapter for some users. I guess the commented out template in the backup configuration file will be enough to point out the option IS available but needs to be activated: We could additionally add this that line: |
I will add the |
That sounds like a great idea. Thanks. |
Just to let people know, I have a very large mysql database, and dumping it using backup gem takes a LONG time, and it locks all the tables, making the site unusable.
A solution is to add --single-transaction to the mysql dump command.
More info at http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction
Perhaps meskyanichi will integrate this?
It's pretty straight forward and it means it can then be used in production for large mysql databases.
Steve
The text was updated successfully, but these errors were encountered: