Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2.11, 10.1(EOL)
-
None
-
CentOS7.3, CentOS7.4
Description
In centos7.3,7.4 , mariadb (10.1.28,10.1.29,10.2.11，)has the following problem:
comand like this:
/usr/bin/mysqlbinlog --raw --read-from-remote-server --stop-never --host=localhost --port=3306 --user=root --password=root --result-file=/backup/binlog/ mysql-bin.000001
lastest backupfile size is 0:
- ll
rw-rw-r- 1 mysql mysql 441 Dec 7 09:22 mysql-bin.000076
rw-rw-r- 1 mysql mysql 3230 Dec 8 03:20 mysql-bin.000077
rw-rw-r- 1 mysql mysql 0 Dec 8 03:20 mysql-bin.000078
OTHER:
mariadb10.1.29 In Cent6.8, percona5.7,mysql5.7 in centos7.3,cent7.4 , There is no such problem
Attachments
Activity
I think this is is not a bug , Actually culprit is fwrite , which buffers the data
So cli_safe_read(mysqlbinlog) reads the actual data from server binlog file
And handle_event_raw_mode calls the fwrite which should have written data but it writes into its buffer
(for proof ) I have changed the my_fwrite function to add fflush in end , with this modification tha latest binlog file(created by myysqlbinlog) was no longer of zero size (edited)
drwxr-xr-x 2 sachin users 4.0K Oct 21 21:10 .
drwxr-xr-x 28 sachin users 4.0K Oct 21 21:05 ..
rw-rr- 1 sachin users 314 Oct 21 21:10 master-bin.000001
sachin.setiya.007 You mention fflush is not done. Probably it's not done too when there's nothing to retrieve from
the server in which case I believe we should take care of doing that.
bnestere, the patch looks good. Thanks for taking the time on it. I also spent a little time figuring out if fflush could be executed
not per event but rather when the source file is found empty (that is before sink to waiting).
However there seems to be no straightforward way and a non-blocking attempt read would be required
inside a low-level ma_net_safe_read.
Manual cherry picking resulted in no merge conflicts in later versions.
Thanks for the report.
I'm not sure about the difference on different versions of CentOS, but the problem is reproducible on my machine (Debian Jessie) with 10.1 and 10.2, and not reproducible on the same machine with MySQL 5.7.