how mydumper (should) handle sql errors ?

Asked by CHANIAL David

Hi,

As we can see below, a thread encountering an error is not stopping, and is retrying all each remaining tables.
I suppose it is an historic behavior.

But is it a wanted behavior ? Should mydumper have to be updated to handle this kind of error in a "proper" way ?

/usr/bin/mydumper --outputdir /home/dumps_mydumper/2015-02-24_14-33 --rows 400000 --build-empty-files --compress --logfile /home/dumps_mydumper/2015-02-24_14-33/mydumper.log --host 127.0.0.1 --port 3306 --threads 1 --verbose 3
[...]
15-02-24 14:33:43 [INFO] - Thread 1 dumping data for `mysql`.`user`
2015-02-24 14:33:43 [INFO] - Thread 1 dumping data for `eCrm`.`tNewsletterElements`
2015-02-24 14:33:43 [INFO] - Non-InnoDB dump complete, unlocking tables
2015-02-24 14:33:45 [ERROR] - Could not read data from eCrm.tNewsletterElements: Got packet bigger than 'max_allowed_packet' bytes
2015-02-24 14:33:45 [INFO] - Thread 1 dumping data for `mysql`.`gtid_slave_pos`
2015-02-24 14:33:45 [ERROR] - Error dumping table (mysql.gtid_slave_pos) data: MySQL server has gone away
2015-02-24 14:33:45 [INFO] - Empty table mysql.gtid_slave_pos
2015-02-24 14:33:45 [INFO] - Thread 1 dumping data for `mysql`.`innodb_index_stats`
2015-02-24 14:33:45 [ERROR] - Error dumping table (mysql.innodb_index_stats) data: MySQL server has gone away
[...]

Question information

Language:
English Edit question
Status:
Answered
For:
MySQL Data Dumper Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Max Bubenick (max-bubenick) said :
#1

Yes, is an historic behavior and Im aware of it, you can fill a bug if doesn't exist already. About this, mydumper must exit all threads in this case, as we dont want to retry with other and end running with less threads than expected.

Can you help with this problem?

Provide an answer of your own, or ask CHANIAL David for more information if necessary.

To post a message you must log in.