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

Add an option to keep retrying when MariaDB encounters a full disk error while trying to open a new binary log file

Details

    Description

      MariaDB already retries writes when full disk situation is encountered while writing to the existing binary log file. See https://mariadb.com/kb/en/library/using-and-maintaining-the-binary-log/#effects-of-full-disk-errors-on-binary-logging:

      "If MariaDB encounters a full disk error while trying to write to a binary log file, then it will keep retrying the write every 60 seconds. Log messages will get written to the error log every 600 seconds."

      This is a request to add an option (maybe set by default) to get the same behavior for the opening new binary log file case, instead of current:

      "...if MariaDB encounters a full disk error while trying to open a new binary log file, then it will disable binary logging entirely."

      Disabling binary logging prevents further point in time recovery even after disk space is freed and logging is again enabled.

      See also related MDEV-17856. When that feature is implemented and IGNORE_ERROR is set, retries should continue for opening new binary log as well.

      Attachments

        Issue Links

          Activity

            Elkin Andrei Elkin added a comment -

            The 60 sec sleep and 600 sec period warning, it's done in the ever lasting loop only interrupted
            when the write is finally completed.

            Elkin Andrei Elkin added a comment - The 60 sec sleep and 600 sec period warning, it's done in the ever lasting loop only interrupted when the write is finally completed.
            Elkin Andrei Elkin added a comment - - edited

            valerii: Strictly speaking PITR can't be 100% with this requirement, if the max retry policy will allow to commit
            upon reaching the max with no success to log. That is some number of trx:s can be lost in binlog.
            Sure that is still better than currently.

            The same max retry policy should apply to binlog rotating thread as well. So it may error out eventually, which won't lead
            to the persistent read-only mode.

            I hope this short remark goes inline with your thinking.

            Cheers.

            Elkin Andrei Elkin added a comment - - edited valerii : Strictly speaking PITR can't be 100% with this requirement, if the max retry policy will allow to commit upon reaching the max with no success to log. That is some number of trx:s can be lost in binlog . Sure that is still better than currently. The same max retry policy should apply to binlog rotating thread as well. So it may error out eventually, which won't lead to the persistent read-only mode. I hope this short remark goes inline with your thinking. Cheers.

            People

              ParadoxV5 Jimmy HĂș
              valerii Valerii Kravchuk
              Votes:
              3 Vote for this issue
              Watchers:
              12 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.