mirror of
https://we.phorge.it/source/phorge.git
synced 2024-11-27 01:02:42 +01:00
Manually set "max_allowed_packet" to 1GB for "mysqldump"
Summary: We have one production instance with failing database backups since they recently uploaded a 52MB hunk. The production configuration specifies a 64MB "max_allowed_packet" in `[mysqld]`, but this doesn't apply to `mysqldump` (we'd need to specify it in a separate `[mysqldump]` section) and `mysqldump` runs with an effective limit of the default (16MB). We could change our production config to specify a value in `[mysqldump]`, but just change it unconditionally at execution time since there's no reason for any user to ever want this command to fail because they have too much data. Test Plan: Dumped locally, will verify production backup goes through cleanly. Reviewers: amckinley Reviewed By: amckinley Differential Revision: https://secure.phabricator.com/D18834
This commit is contained in:
parent
7cbbe2ccf7
commit
8dccf05c4c
1 changed files with 16 additions and 0 deletions
|
@ -187,6 +187,22 @@ final class PhabricatorStorageManagementDumpWorkflow
|
|||
$argv[] = '-h';
|
||||
$argv[] = $host;
|
||||
|
||||
// MySQL's default "max_allowed_packet" setting is fairly conservative
|
||||
// (16MB). If we try to dump a row which is larger than this limit, the
|
||||
// dump will fail.
|
||||
|
||||
// We encourage users to increase this limit during setup, but modifying
|
||||
// the "[mysqld]" section of the configuration file (instead of
|
||||
// "[mysqldump]" section) won't apply to "mysqldump" and we can not easily
|
||||
// detect what the "mysqldump" setting is.
|
||||
|
||||
// Since no user would ever reasonably want a dump to fail because a row
|
||||
// was too large, just manually force this setting to the largest supported
|
||||
// value.
|
||||
|
||||
$argv[] = '--max-allowed-packet';
|
||||
$argv[] = '1G';
|
||||
|
||||
if ($port) {
|
||||
$argv[] = '--port';
|
||||
$argv[] = $port;
|
||||
|
|
Loading…
Reference in a new issue