Bug #94360 | Contribution by Facebook: Don't force flush relay log info | ||
---|---|---|---|
Submitted: | 16 Feb 2019 4:44 | Modified: | 8 Feb 2022 19:35 |
Reporter: | FBContrib Admin | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 8.0.13 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[16 Feb 2019 4:44]
FBContrib Admin
[16 Feb 2019 4:44]
FBContrib Admin
Don't force flush relay log info (*) This code is contributed under the Facebook agreement
Contribution: fb_patch_106.txt (text/plain), 514 bytes.
[8 Feb 2022 19:35]
Omer Barnir
Posted by developer: The solution to the described problem was addressed as part of a larger effort that aimed not only to reduce the flushing frequency of replication related metadada but also reduce the dependency on position information when using GTIDs. The specific issue described in this contribution was addressed but under some constraints. In 8.0.27 when configuration conditions are met (GTID_MODE=ON, SOURCE_AUTO_POSITION=1, REQUIRE_ROW_FORMAT=1) the user can now use on replication channels the option GTID_ONLY=1 that will remove the per-transaction persistence of information associated to what files and positions are being replicated, so only GTIDs are used to track the replication/execution of transactions. Thanks to Facebook for offering the contribution
[16 Feb 2022 18:29]
Margaret Fisher
Noted in the changelog entry for WL #7491 in 8.0.27. Thanks for offering the contribution!