I had that issue initially, and changed the value to 64MB. It was originally 4MB, then I increased it to 16MB, it’s been at 64MB for some time.
The maximum size of one packet or any generated or intermediate string, or any parameter sent by the
mysql_stmt_send_long_data() C API function.
#max_allowed_packet=4M
#max_allowed_packet=16M
max_allowed_packet=64M
It’s the oddest thing. The backups were working perfectly through most of December. Sometime between the week of Christmas and now it seems to have “blown up”. As a work around right now, I’ve split the backup in two pieces: just attachments, and everything else. That appears to be working but I can’t seem to explain why this has happened.
Stephen Cena
Senior Systems Administrator
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-general@qvii.commailto:hd-general@qvii.com
To report email issues: postmaster@qvii.commailto:postmaster@qvii.comFrom: Thomas Bätzler [mailto:t.baetzler@bringe.com]
Sent: Thursday, January 19, 2017 3:04 AM
To: ‘rt-users@lists.bestpractical.com’ rt-users@lists.bestpractical.com
Cc: Cena, Stephen (ext. 300) SJC@qvii.com
Subject: AW: [rt-users] MySQL backups of RT 4.4.1 truncated
Hello Stephen,
just a stab in the dark, but could you please check the value set for “max_allowed_packet” in the mysqldump section of /etc/mysql/my.cnf (or whatever your my.cnf file is named)? If you try to dump mysql objects that are larger than this size, mysqldump will stop; probably with a message like “mysql server has gone away”. You can raise that value for mysqldump just by editing that file; no server restart is required.
HTH,
Thomas Bätzler
BRINGE Informationstechnik GmbH
Zur Seeplatte 12
D-76228 Karlsruhe
Germany
Fon: +49 721 94246-0
Fon: +49 171 5438457
Fax: +49 721 94246-66
Web: http://www.bringe.de/
Geschäftsführer: Dipl.-Ing. (FH) Martin Bringe
Ust.Id: DE812936645, HRB 108943 Mannheim
Von: rt-users [mailto:rt-users-bounces@lists.bestpractical.com] Im Auftrag von Cena, Stephen (ext. 300)
Gesendet: Mittwoch, 18. Januar 2017 18:23
An: ‘rt-users@lists.bestpractical.com’ <rt-users@lists.bestpractical.commailto:rt-users@lists.bestpractical.com>
Betreff: Re: [rt-users] MySQL backups of RT 4.4.1 truncated
I just ran a test with the attachments table “ignored”, and the backup worked perfectly. As a “sanity check”, I also ran mysqlcheck on the schema & no errors were found. Should I split my backup job into two pieces, or is there a better way to get a backup all in one shot?
Message: 4
Date: Wed, 18 Jan 2017 13:54:57 +0000
From: “Cena, Stephen (ext. 300)” <SJC@qvii.commailto:SJC@qvii.com>
To: “‘rt-users@lists.bestpractical.com’”
<rt-users@lists.bestpractical.com<mailto:rt-users@lists.bestpractical.com>>
Subject: [rt-users] MySQL backups of RT 4.4.1 truncated
Message-ID:
<87F81E27495DC8489147E34A4152E268A49508BA@MailStore2010.ogp.qvii.com<mailto:87F81E27495DC8489147E34A4152E268A49508BA@MailStore2010.ogp.qvii.com>>
Content-Type: text/plain; charset=“us-ascii”
I’m currently running RT 4.4.1 on Ubuntu 14.04 LTS with MySQL 5.6 on Windows Server 2012. Recently, we enabled full-text indexing in native MySQL & everything is great. After doing some work on the server over the weekend, I discovered that the .sql files being generated for the backup are being “truncated” after the attachments table (~18-19GB). After reviewing your documentation (Backups - RT 4.4.1 Documentation - Best Practical) I realized my mysqldump command was incorrect. I’m working in a lab environment now to see how I can optimize/change my script to more closely match yours. The only thought I have right now is to exclude the data from the AttachmentsIndex as that would get rebuilt on restoration anyways. Is there any other reason that the backup would just “stop” after the attachment table? I apologize if this is beyond the scope of the forums thread.
Thank you in advance!
Stephen Cena
Senior Systems Administrator
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-general@qvii.com<mailto:hd-general@qvii.commailto:hd-general@qvii.com<mailto:hd-general@qvii.com>
To report email issues: postmaster@qvii.com<mailto:postmaster@qvii.commailto:postmaster@qvii.com<mailto:postmaster@qvii.com>
Stephen Cena
Senior Systems Administrator
Quality Vision International, Inc.
Phone: (585) 544-0450 x300
To notify helpdesk: http://helpdesk.ogp.qvii.com or email: hd-general@qvii.commailto:hd-general@qvii.com
To report email issues: postmaster@qvii.commailto:postmaster@qvii.com
