| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <fb79e430-97fb-176e-fc64-2c32a9d8a94f@huawei.com> Date: Thu, 7 Dec 2023 14:41:01 +0800 From: Baokun Li <libaokun1@...wei.com> To: Theodore Ts'o <tytso@....edu> CC: Jan Kara <jack@...e.cz>, <linux-mm@...ck.org>, <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>, <willy@...radead.org>, <akpm@...ux-foundation.org>, <ritesh.list@...il.com>, <linux-kernel@...r.kernel.org>, <yi.zhang@...wei.com>, <yangerkun@...wei.com>, <yukuai3@...wei.com>, Baokun Li <libaokun1@...wei.com> Subject: Re: [PATCH -RFC 0/2] mm/ext4: avoid data corruption when extending DIO write race with buffered read 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 .
Powered by blists - more mailing lists