Details
-
New Feature
-
Status: In Progress (View Workflow)
-
Critical
-
Resolution: Unresolved
-
None
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_SERVERControls 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.
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
- blocks
-
MDEV-20796 Add an option to keep retrying when MariaDB encounters a full disk error while trying to open a new binary log file
- Open
- duplicates
-
MDEV-17866 FR: Add binlog_error_action variable
- Closed
- relates to
-
MDEV-17855 Provide documentation of error 28 with binary logging
- Closed
- links to