On 2023/12/7 5:55, Theodore Ts'o wrote:
On Tue, Dec 05, 2023 at 09:19:03PM +0800, Baokun Li wrote:
Thank you very much for your detailed explanation!
But the downstream users do have buffered reads to read the relay log
file, as I confirmed with bpftrace. Here's an introduction to turning on
relay logging, but I'm not sure if you can access this link:
https://blog.csdn.net/javaanddonet/article/details/112596148
Well, if a mysql-supplied program is trying read the relay log using a
buffered read, when it's being written using Direct I/O, that's a bug
in mysql, and it should be reported as such to the mysql folks.
I was mistaken here, it now looks like reads and writes to the relay
log are buffered IO, and I'm still trying to locate the issue.
It does look like there is a newer way of doing replication which
doesn't rely on messign with log files. From:
https://dev.mysql.com/doc/refman/8.0/en/replication.html
MySQL 8.0 supports different methods of replication. The
traditional method is based on replicating events from the
source's binary log, and requires the log files and positions in
them to be synchronized between source and replica. The newer
method based on global transaction identifiers (GTIDs) is
transactional and therefore does not require working with log
files or positions within these files, which greatly simplifies
many common replication tasks. Replication using GTIDs guarantees
consistency between source and replica as long as all transactions
committed on the source have also been applied on the replica. For
more information about GTIDs and GTID-based replication in MySQL,
see Section 17.1.3, “Replication with Global Transaction
Identifiers”. For information on using binary log file position
based replication, see Section 17.1, “Configuring Replication”.
Perhaps you can try and see how mysql handles GTID-based replication
using bpftrace?
Cheers,
- Ted
Thank you very much for your solution! I'll try it.
Thanks!
--
With Best Regards,
Baokun Li
.
