Details

    Description

      MySQL has had the binlog_error_action variable since MySQL 5.6.22:

      binlog_error_action

      Property Value
      Command-Line Format --binlog-error-action[=value]
      Introduced 5.6.22
      System Variable binlog_error_action
      Scope Global
      Dynamic Yes
      Type Enumeration
      Default Value IGNORE_ERROR
      Valid Values
      IGNORE_ERROR
      ABORT_SERVER

      Controls what happens when the server cannot write to the binary log, which can cause the master's log to become inconsistent and replication slaves to lose synchronization. Previous releases used the name binlogging_impossible_mode.

      In MySQL 5.6, the default for binlog_error_action is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues performing updates; this is to provide backward compatibility with older versions of the MySQL Server. Setting this variable to ABORT_SERVER makes the server halt logging and shut down whenever it cannot write to the binary log; this is the recommended setting, particularly in complex replication environments.

      https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_error_action

      Is it worth porting to MariaDB?

      I think binlog_error_action=ABORT_SERVER would probably be most useful to prevent issues in complex replication environments where some errors such as full disk can cause binary logging to be completely disabled, which means that transactions which have been committed to the local server won't be able to get replication to any of the system's slaves.

      Attachments

        Issue Links

          Activity

            GeoffMontee Geoff Montee (Inactive) created issue -
            GeoffMontee Geoff Montee (Inactive) made changes -
            Field Original Value New Value
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            valerii Valerii Kravchuk made changes -
            Support case ID not-24069 not-24069 27934
            GeoffMontee Geoff Montee (Inactive) made changes -
            Assignee Andrei Elkin [ elkin ]
            julien.fritsch Julien Fritsch made changes -
            Assignee Andrei Elkin [ elkin ] Ralf Gebhardt [ ralf.gebhardt@mariadb.com ]
            rupert Rupert Harwood (Inactive) made changes -
            ralf.gebhardt Ralf Gebhardt made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 90940 ] MariaDB v4 [ 130947 ]
            AirFocus AirFocus made changes -
            Description MySQL has had the binlog_error_action variable since MySQL 5.6.22:

            {quote}
            binlog_error_action

            Property Value
            Command-Line Format --binlog-error-action[=value]
            Introduced 5.6.22
            System Variable binlog_error_action
            Scope Global
            Dynamic Yes
            Type Enumeration
            Default Value IGNORE_ERROR
            Valid Values
            IGNORE_ERROR
            ABORT_SERVER

            Controls what happens when the server cannot write to the binary log, which can cause the master's log to become inconsistent and replication slaves to lose synchronization. Previous releases used the name binlogging_impossible_mode.

            In MySQL 5.6, the default for binlog_error_action is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues performing updates; this is to provide backward compatibility with older versions of the MySQL Server. Setting this variable to ABORT_SERVER makes the server halt logging and shut down whenever it cannot write to the binary log; this is the recommended setting, particularly in complex replication environments.
            {quote}

            https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#sysvar_binlog_error_action

            Is it worth porting to MariaDB?

            I think binlog_error_action=ABORT_SERVER would probably be most useful to prevent issues in complex replication environments where some errors such as full disk can cause binary logging to be completely disabled, which means that transactions which have been committed to the local server won't be able to get replication to any of the system's slaves.
            MySQL has had the binlog_error_action variable since MySQL 5.6.22:

            {quote}
            binlog_error_action

            Property Value
            Command-Line Format --binlog-error-action[=value]
            Introduced 5.6.22
            System Variable binlog_error_action
            Scope Global
            Dynamic Yes
            Type Enumeration
            Default Value IGNORE_ERROR
            Valid Values
            IGNORE_ERROR
            ABORT_SERVER

            Controls what happens when the server cannot write to the binary log, which can cause the master's log to become inconsistent and replication slaves to lose synchronization. Previous releases used the name binlogging_impossible_mode.

            In MySQL 5.6, the default for binlog_error_action is IGNORE_ERROR, meaning the server logs the error, halts logging, and continues performing updates; this is to provide backward compatibility with older versions of the MySQL Server. Setting this variable to ABORT_SERVER makes the server halt logging and shut down whenever it cannot write to the binary log; this is the recommended setting, particularly in complex replication environments.
            {quote}

            https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary\-log.html#sysvar_binlog_error\_action

            Is it worth porting to MariaDB?

            I think binlog_error_action=ABORT\_SERVER would probably be most useful to prevent issues in complex replication environments where some errors such as full disk can cause binary logging to be completely disabled, which means that transactions which have been committed to the local server won't be able to get replication to any of the system's slaves.
            ralf.gebhardt Ralf Gebhardt made changes -
            Assignee Ralf Gebhardt [ ralf.gebhardt@mariadb.com ]
            julien.fritsch Julien Fritsch made changes -
            Issue Type Task [ 3 ] New Feature [ 2 ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Assignee Andrei Elkin [ elkin ]
            ralf.gebhardt Ralf Gebhardt made changes -
            Fix Version/s 11.7 [ 29815 ]
            mariadb-jira-automation Jira Automation (IT) made changes -
            Zendesk Related Tickets 202273 190105 144017
            serg Sergei Golubchik made changes -
            Fix Version/s 11.8 [ 29921 ]
            Fix Version/s 11.7 [ 29815 ]
            julien.fritsch Julien Fritsch made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            bnestere Brandon Nesterenko made changes -
            Assignee Andrei Elkin [ elkin ] Jimmy Hú [ JIRAUSER55761 ]
            ParadoxV5 Jimmy Hú made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            danblack Daniel Black made changes -
            ParadoxV5 Jimmy Hú made changes -
            ParadoxV5 Jimmy Hú made changes -
            Status In Progress [ 3 ] Stalled [ 10000 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 11.9 [ 29945 ]
            Fix Version/s 11.8 [ 29921 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 11.10 [ 29992 ]
            Fix Version/s 11.9 [ 29945 ]

            People

              ParadoxV5 Jimmy Hú
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              8 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.