Page MenuHomePhabricator

Provide import/restore guidance for "max_allowed_packet" and "innodb_log_file_size"

Authored by epriestley on Jul 22 2019, 5:05 PM.



Ref T13347. The gunzip dump.sql.gz | mysql incantation can fail for various reasons. Explicitly document how to identify and resolve two of them:

We have setup guidance around "max_allowed_packet" and even-slightly-modern MySQL seems to raise a good, explicit error message about this, but I believe older MySQL clients raised an opaque error message if a statement in the dumpfile exceeded the packet length ("2006 server has gone away" with no pointer toward packet length).

The InnoDB log issue in T13347 is new to me, and has opaque client errors as of whatever mysql version we have in production (Ubuntu "Ver 14.14 Distrib 5.5.62").

I'll wait until T13347 is actually confirmed as resolved in production to deploy this since I'm not 100% the InnoDB log issue is really the issue, although it seems likely.

Test Plan

Read text, will continue working toward a resolution of T13347.

Diff Detail

rP Phabricator
Lint OK
No Unit Test Coverage
Build Status
Buildable 23180
Build 31839: Run Core Tests
Build 31838: arc lint + arc unit

Event Timeline

epriestley created this revision.Jul 22 2019, 5:05 PM
epriestley requested review of this revision.Jul 22 2019, 5:06 PM
epriestley edited the summary of this revision. (Show Details)Jul 22 2019, 5:07 PM
epriestley added inline comments.

I got rid of this extra sentence since I think it's from an older version of the document, and we're clearly recommending a compressed workflow here now.

epriestley planned changes to this revision.Jul 22 2019, 6:16 PM

Let me hold this until I'm more confident I'm on the right track.

epriestley abandoned this revision.Jul 23 2019, 1:24 PM

I'm likely going to propose some variation of this change, but focus it on max_allowed_packet and on emphasizing that there are two different copies of this setting with different error/failure behavior.