PS-11054 fix: cannot replicate because the source purged required binary logs#118
Merged
Conversation
…ary logs https://perconadev.atlassian.net/browse/PS-11054 It is now possible to start replication from MySQL servers that have non-empty purged GTID set ('@@global.gtid_purged'). Internally, if we identify that the specified storage is empty, we try to extract the set of GTIDs that were purged on the server side via 'SELECT '@@global.gtid_purged' and pass this info to the storage object. This helps to make sure that the very first binlog will have this purged GTID set stored in the 'previous_gtids' field of its metadata file (before this change, the 'previous_gtids' in the very first metadata file was always empty). Because of this change when we switch the connection to the replication mode we also pass this purged GTID set as the initial GTID state to the 'mysql_binlog_open()' client API call and don't get the 'Cannot replicate because the source purged required binary logs' errors anymore. 'easymysql::connection' class extended with the new 'execute_select_query_string_result()' method that can be used for executing single-value (single row + single column) queries returning a string value. 'binsrv::storage' class extended with new 'purged_gtids_' member that is used to store information about purged GTIDs identified when storage was initialized for the first time. Raised log message severity from 'info' to 'error' for some connection exceptions. Added new MTR test case 'binlog_streaming.gtid_purged' that checks if PBS can start replicating from a server that has the very first binlog file purged. Fixed README.md - the correct JSON filed name in the 'result' section of the query responses is 'previous_gtids' (not 'initial_gtids').
kamil-holubicki
added a commit
that referenced
this pull request
May 26, 2026
* PS-10622 feature: Change version to 0.2.0 when GTID support is complete (#103) https://perconadev.atlassian.net/browse/PS-10622 Version bump to '0.2.0': * Updated 'app_version.hpp' * Updated 'README.md' * Updated Deb packaging files * Updated RPMs packaging files Enabled GitHub Actions for the '0.2' branch. Added missing 'search_by_gtid_set' command to the console application 'help' message. * Fix debian builds (#107) * PS-10910 fix: Bucket name is missing in search_* outputs (#108) https://perconadev.atlassian.net/browse/PS-10910 Fixed an issue with forming URLs in search results for 'search_by_timestamp' / 'search_by_gtid_set' operations when for S3 storage backends with custom endpoint URLs the name of the bucket was omitted. * PS-11002 fix: changing storage prefix fails (#113) https://perconadev.atlassian.net/browse/PS-11002 Having just single 'metadata.json' in the storage is no longer considered an integrity violation for the 'storage' initialization logic. In this case we simply validate this storage metadata file and return early (basically, consider this layout an empty storage). * PS-10281 postfix: Implement logic for search_by_gtid_set mode (#114) https://perconadev.atlassian.net/browse/PS-10281 'gtid_set_test' (BOOST_TEST_MODULE GtidSetTests) unit test extended with new test case 'GtidSetSimulateSearchByGTIDSet' which simulates the logic of 'search_by_gtid_set' main application operation mode. Updated unit tests 'CMakeLists.txt' file . We now run unit tests with '--no_color_output' command line option which helps with better integration with VS Code. * PS-10911 fix: unexpected binlog position in artificial rotate event (#115) https://perconadev.atlassian.net/browse/PS-10911 Fixed problem with not being able to properly process ROTATE (artificial) events after reconnection in GTID-based replication mode (in the 'pull' operation mode). Original 'position' field checking in the artificial ROTATE event post-header makes sense only for the position-based replication mode. Extended 'log_storage_config_info()' - we now also print the masked storage URI (the one with hidden 'user' / 'password' components) to the log. Minor improvements in the log message formatting - now all 'trace' / 'debug' / 'info' / 'warning' / 'error' / 'fatal' log severity labels are padded to the same width. * PS-10321 postfix: binlog-server fails to read the new events after upgrading server from 8.0 to 8.4 (#116) https://perconadev.atlassian.net/browse/PS-10321 Fixed 'binlog_streaming.data_directory_8_0_to_8_4_upgrade' MTR test case that started to fail after 30 days since it was created. The problem turned out to be connected with enabled automatic purging of binary log files (set to 30 days) that started to happen upon MySQL Server restart during 8.0 -> 8.4 data directory upgrade. Fixed by adding the "--log-error=$MYSQLD_LOG --binlog_expire_logs_auto_purge=OFF" command line option to the restart command. Stabilized running MTR in GitHub Actions by adding timeout parameters to the "./mtr ..." commands: * 'testcase-timeout' - 30 minutes * 'suite-timeout' - 60 minutes * 'shutdown-timeout' - 600 seconds * Version changed to 0.2.1 (#117) * PS-11054 fix: cannot replicate because the source purged required binary logs (#118) https://perconadev.atlassian.net/browse/PS-11054 It is now possible to start replication from MySQL servers that have non-empty purged GTID set ('@@global.gtid_purged'). Internally, if we identify that the specified storage is empty, we try to extract the set of GTIDs that were purged on the server side via 'SELECT '@@global.gtid_purged' and pass this info to the storage object. This helps to make sure that the very first binlog will have this purged GTID set stored in the 'previous_gtids' field of its metadata file (before this change, the 'previous_gtids' in the very first metadata file was always empty). Because of this change when we switch the connection to the replication mode we also pass this purged GTID set as the initial GTID state to the 'mysql_binlog_open()' client API call and don't get the 'Cannot replicate because the source purged required binary logs' errors anymore. 'easymysql::connection' class extended with the new 'execute_select_query_string_result()' method that can be used for executing single-value (single row + single column) queries returning a string value. 'binsrv::storage' class extended with new 'purged_gtids_' member that is used to store information about purged GTIDs identified when storage was initialized for the first time. Raised log message severity from 'info' to 'error' for some connection exceptions. Added new MTR test case 'binlog_streaming.gtid_purged' that checks if PBS can start replicating from a server that has the very first binlog file purged. Fixed README.md - the correct JSON filed name in the 'result' section of the query responses is 'previous_gtids' (not 'initial_gtids'). * Version changed to 0.2.2 (#119) * PS-11033 fix: crash when S3 bucket accumulates large number of objects; recovery requires manual intervention (#120) https://perconadev.atlassian.net/browse/PS-11033 Fixed problem with initializing a non-empty S3 storage that has more than 500 binlog files / binlog metadata files (1000 total). Implemented pagination for the 'ListObjectsV2()' AWS SDK C++ API call in the 's3_storage_backend::aws_context::list_objects()' method. S3 API has a hard limit that sets the max number of items in the 'ListObjectsV2' response to be no greater than 1000. In case when the storage has more than 1000 objects, we now perform several 'ListObjectsV2' calls with the continuation token. Added 'binlog_streaming.thousand_binlogs' MTR test case that executes 'FLUSH BINARY LOG' 1000 times and executes PBS two times, on an empty and populated storage. Co-authored-by: Copilot <copilot@github.com> * Version changed to 0.2.3 (#121) --------- Co-authored-by: Yura Sorokin <yura.sorokin@percona.com> Co-authored-by: Vadim Yalovets <vadim.yalovets@percona.com> Co-authored-by: Copilot <copilot@github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://perconadev.atlassian.net/browse/PS-11054
It is now possible to start replication from MySQL servers that have non-empty purged GTID set ('@@global.gtid_purged').
Internally, if we identify that the specified storage is empty, we try to extract the set of GTIDs that were purged on the server side via 'SELECT '@@global.gtid_purged' and pass this info to the storage object. This helps to make sure that the very first binlog will have this purged GTID set stored in the 'previous_gtids' field of its metadata file (before this change, the 'previous_gtids' in the very first metadata file was always empty). Because of this change when we switch the connection to the replication mode we also pass this purged GTID set as the initial GTID state to the 'mysql_binlog_open()' client API call and don't get the
'Cannot replicate because the source purged required binary logs' errors anymore.
'easymysql::connection' class extended with the new 'execute_select_query_string_result()' method that can be used for executing single-value (single row + single column) queries returning a string value.
'binsrv::storage' class extended with new 'purged_gtids_' member that is used to store information about purged GTIDs identified when storage was initialized for the first time.
Raised log message severity from 'info' to 'error' for some connection exceptions.
Added new MTR test case 'binlog_streaming.gtid_purged' that checks if PBS can start replicating from a server that has the very first binlog file purged.
Fixed README.md - the correct JSON filed name in the 'result' section of the query responses is 'previous_gtids' (not 'initial_gtids').