Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-32969

Mariadb-dump --delete-master-logs May Not Delete Binary Logs

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL)
    • 10.5, 10.6, 10.11
    • None

    Description

      Because --delete-master-logs immediately purges logs after flushing, if there are any active dump threads on the master, they may still be using the old binary log when the purge executes, disallowing the file from being deleted.

      Workarounds are either to manually re-run PURGE BINARY LOGS TO once the dump threads have caught up, or to temporarily disconnect replicas before performing the dump.

      Test case 8 in mysql-test/main/rpl_mysqldump_slave.test implements the second work-around for consistent behavior to pass. Depending on the resolution of this ticket, that test may need to be fixed to remove the work-around.

      Attachments

        Issue Links

          Activity

            I don't think this requires any changes in the code.

            The --purge-master-logs is a somewhat strange option. It goes back to 2003, it used to do RESET MASTER to really delete the binlogs. Then in 2007 (MySQL Bug#24733) it was changed to use PURGE instead, making the name somewhat misleading.

            It looks to me as if the original purpose was to take a mysqldump to setup a slave, then RESET MASTER on the master at the point corresponding to the dump. This way the new slave could start replicating from the empty position to setup consistent replication. Nowadays we have the much better way of eg. --single-transaction --master-data to setup a slave without removing binlogs on the master.

            So in summary, the option no longer appears very useful (if it ever was?). But it does what it is documented to do, and doesn't harm anything. It's just a way to run purge, and purge always respects running slaves (as well as pending checkpoints).

            knielsen Kristian Nielsen added a comment - I don't think this requires any changes in the code. The --purge-master-logs is a somewhat strange option. It goes back to 2003, it used to do RESET MASTER to really delete the binlogs. Then in 2007 (MySQL Bug#24733) it was changed to use PURGE instead, making the name somewhat misleading. It looks to me as if the original purpose was to take a mysqldump to setup a slave, then RESET MASTER on the master at the point corresponding to the dump. This way the new slave could start replicating from the empty position to setup consistent replication. Nowadays we have the much better way of eg. --single-transaction --master-data to setup a slave without removing binlogs on the master. So in summary, the option no longer appears very useful (if it ever was?). But it does what it is documented to do, and doesn't harm anything. It's just a way to run purge, and purge always respects running slaves (as well as pending checkpoints).

            People

              bnestere Brandon Nesterenko
              bnestere Brandon Nesterenko
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.