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. 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
