Linux 32-bit, Debian Wheezy 7.5, MariaDB installed from MariaDB repository

Thanks for the report.
It looks like an upstream issue.

As a workaround, please try to disable 'syslog' in mysqld_safe config file.

Thank you Elena.

Do you consider --flush-logs necessary for backing up a master server?

Hi Vasilis,

I don't have a well-argumented opinion on the subject; but here is the vision of my colleague knielsen who is a replication expert:

<knielsen>: here is a use: mysqldump --master-data --flush-logs; then after you can look in the dump for the binlog position and copy binlogs up to that point, and you have a backup that includes binlogs consistent with your data
<knielsen>: that might be the purpose of it, that could be useful
<knielsen>: (the point being that the binlogs are rotated at that point, so the backup position will be at the end of one log / start of the next one, not in the middle of a binlog file)
<knielsen>: if you lose the master, you want to restore it from backup - and that requires also restoring the binlog files - but you must only restore up to the point of the backup, otherwise the slave will get extra transactions that are not (any longer) on the restored master
<knielsen>: but it could be argued that accurate binlogs are not that useful anyway. Since you would need to re-create all slaves from scratch also - and then you don't really need the old binlogs

So, as you can see, there is some doubt it's necessary.
If you explain why you chose to use it in the first place, or if you point us at the source where it was recommended, maybe we could look at it from a new perspective, it's quite possible that we are not taking into account some particular real-life scenario.

Thank you Elena for your comment.

I don't remember reading somewhere that --flush-logs is necessary for a master server, but after going through mysqldump's man page, I figured this would be good to have enabled. I disabled log_error for the master server and reenabled --flush-logs in my backup script. This is an acceptable workaround for me, but I thought about reporting the error anyway. Kristian's comments are useful too.

Thank you for the great work!

We will need to re-report it to MySQL in order to inform them, we always do so for upstream bugs.
Do you want to file a bug report at bugs.mysql.com, or should I do so on your behalf?

For a note, the problem is not with mysqldump itself of course, it is with executing FLUSH TABLES on the server side, which mysqldump calls when the option is enabled.

I don't feel like reporting the bug to Oracle's issue tracker, they've always been slow at responding or providing any feedback regarding issues. If you feel like reporting the bug, feel free to do so. However, from your reply I understand that you already found out the cause of this issue. Why don't you patch the source code in the MariaDB tree and have this issue fixed in the next release?

Maybe we will, but we should report it to them anyway, for the sake of collaboration. I'll do that.
I didn't find the exact cause of the issue yet, I have some general suspicions, but it will require some more investigation. Apparently it has something to do with the interaction between syslog and the usual log, and possibly with the service or the way it starts mysqld_safe / mysqld, and with how they open logs.

I could reproduce it on MySQL 5.1 and 5.5 from the official repo (filed as http://bugs.mysql.com/bug.php?id=72598), but not on MySQL 5.6 from dotdeb repo. If it's not just the packaging difference, but the problem was actually fixed in 5.6, there's no chance it will be fixed in earlier versions, so we'll need to do it on our own anyway.

• install MySQL server from an official MariaDB repo (apt-get install mariadb-server);
• make sure that --syslog is enabled in the special config file;
• connect to the server and run FLUSH LOGS (works all right);
• add log-error=<path-to-file> to /etc/mysql/my.cnf, [mysqld] section;
• run /etc/init.d/mysql stop;
• if the <path-to-file> already exists, remove the file (it might be not necessary, but existence of the file seemed to affect the experiments somehow);
• run /etc/init.d/mysql start;
• connect to the server and run FLUSH LOGS (fails)

Is there some progress regarding this issue? I'm using 5.5.41 from MariaDB's official Debian repository and the issue still exists.