[MDEV-22594] consolidate server transactional logs Created: 2020-05-16  Updated: 2023-11-30

Status: Open
Project: MariaDB Server
Component/s: Server
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Sergei Golubchik Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Relates
relates to MDEV-3857 stress testing of the TC_LOG_MMAP code Open
relates to MDEV-20796 Add an option to keep retrying when M... Open
relates to MDEV-21053 Crash safety of foreign key DDL In Review

 Description   

Intro

The server has binary log, where transactions are recorded, a mmap-based "tc-log" for internal 2PC support (when binlog is disabled) and a ddl log for atomic partitioning DDLs. This latter log cannot be used as-is to make all DDLs atomic, so there's a chance there will be a third one.

This is three logs too many. The task is to remove partitioning ddl log and tc-log and use binlog for everything.

Benefits

  • only one implementation of logging
    • already supports group commits, rotation, purging
    • binlog-based crash recovery is already implemented and works
    • intensively used, so much better tested and trustworthy than the others
  • only one file to sync
  • only one file to perform recovery from

Drawbacks

  • binlog will contain events irrelevant for replication or backups
  • binlog cannot be turned off

Implementation considerations

  • Binlog cannot be turned off, so "binary logging disabled" will mean that DMLs will not be binlogged and only recovery-relevant events will be. One consequence of this is that we can remove all testing of 'binlog-is-open' in the code.
  • mysql_binlog_send(), probably, should filter out recovery events and not send them to slaves. Alternatively, it'll send everything and slaves ignore them
  • It's better to have just one new binlog event "DDL log" and sub-events in it. This would make it easier to filter it out and we avoid spamming binlog/replication with tens of irrelevant new event types.

Generated at Thu Feb 08 09:15:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.