[rt-users] MySQL backups of RT 4.4.1 truncated

[Thomas Bätzler]

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 at lists.bestpractical.com] Im Auftrag
von Cena, Stephen (ext. 300)
Gesendet: Mittwoch, 18. Januar 2017 18:23
An: 'rt-users at lists.bestpractical.com' <rt-users at 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 at qvii.com <mailto:SJC at qvii.com> >

To: "'rt-users at lists.bestpractical.com'"

                <rt-users at lists.bestpractical.com
<mailto:rt-users at lists.bestpractical.com> >

Subject: [rt-users] MySQL backups of RT 4.4.1 truncated

Message-ID:

 
<87F81E27495DC8489147E34A4152E268A49508BA at MailStore2010.ogp.qvii.com
<mailto:87F81E27495DC8489147E34A4152E268A49508BA at 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 (https://docs.bestpractical.com/rt/4.4.1/backups.html) 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 at qvii.com
<mailto:hd-general at qvii.com%3cmailto:hd-general at qvii.com>
<mailto:hd-general at qvii.com>

To report email issues: postmaster at qvii.com
<mailto:postmaster at qvii.com%3cmailto:postmaster at qvii.com>
<mailto:postmaster at qvii.com>

 

Stephen Cena

Senior Systems Administrator 

Quality Vision International, Inc.

Phone: (585) 544-0450 x300

To notify helpdesk:  <http://helpdesk.ogp.qvii.com>
http://helpdesk.ogp.qvii.com or email:  <mailto:hd-general at qvii.com>
hd-general at qvii.com

To report email issues:  <mailto:postmaster at qvii.com> postmaster at qvii.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20170119/41679a4b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5050 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20170119/41679a4b/attachment.bin>