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

Implement crash-safe logging of the user XA

Details

    • Bug
    • Status: Stalled (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.5
    • 10.6
    • Replication

    Description

      This task is ensued by MDEV-742 and implements the upstream's Bug#76233

      In fact there's no issue in the ordering of logging of XA PREPARE into the binary log and transaction preparing in Engine. The chosen by upstream method of the logging goes first is not really incorrect but just needs
      some refinement of the server recovery.

      So in case the server crashes having XA-prepared "transaction" binlogged but not yet
      prepared in Engine, its next recovery must be augmented with identifying the XA-prepared's events in the binlog and resubmitting the transaction for preparing in Engine.

      XA-COMMIT or XA-ROLLBACK are logged compatibly with XA-PREPARE and therefore
      a similar issue arises when the server crashes after binary logging but before actual transaction completion in Engine. The same technique must be used to identify and resubmit to commit-or-rollback.

      Attachments

        Issue Links

          Activity

            MySQL 8.0.30 includes WL#11300 Crash-safe XA + binary log. However, MySQL Bug #76233 XA prepare is logged ahead of engine prepare has not been closed yet.

            marko Marko Mäkelä added a comment - MySQL 8.0.30 includes WL#11300 Crash-safe XA + binary log . However, MySQL Bug #76233 XA prepare is logged ahead of engine prepare has not been closed yet.

            Changed the relationship from blocks to relates to. In reality, MDEV-21117 (already closed) provided the base for this patch, and likely, the dependency with MDEV-18959 is reversed, i.e. MDEV-21469 would depend on the framework laid out by this patch.

            bnestere Brandon Nesterenko added a comment - Changed the relationship from blocks to relates to. In reality, MDEV-21117 (already closed) provided the base for this patch, and likely, the dependency with MDEV-18959 is reversed, i.e. MDEV-21469 would depend on the framework laid out by this patch.

            Changed the fix version to 10.6 because the patch for MDEV-21117 was committed into 10.6, and refactored a lot of the binlog recovery logic which is well suited to this work.

            bnestere Brandon Nesterenko added a comment - Changed the fix version to 10.6 because the patch for MDEV-21117 was committed into 10.6, and refactored a lot of the binlog recovery logic which is well suited to this work.

            Note that we have to ensure that this MDEV and MDEV-31949 are both solved and tested together

            monty Michael Widenius added a comment - Note that we have to ensure that this MDEV and MDEV-31949 are both solved and tested together

            Repeating my comment from MDEV-31949:

            Let me just state once and for all:

            The idea to binlog first and prepare in engine later for XA prepare will not be approved. Don't spend more effort in this direction.

            • The engines, InnoDB in particular, have very mature and carefully designed and optimized write-ahead logging. This should be the primary source of recovery, not the binlog which is not very well designed or suitable as a high-performance and scalable write-ahead log. And the binlog is optional, the engine needs to implement recovery from its own log anyway. This should not be duplicated in the binlog.
            • For normal transactions, we call innobase_xa_prepare() before binlogging. We should not do the opposite semantics for user XA PREPARE.
            • Recovering the transaction from the binlog is not possible in all cases. Statement-based binlogging is a supported user configuration and does not admit this, even row-based binlogging doesn't support it in all cases.

            For these reasons, the engine prepare must come before the binlog write for XA PREPARE. Again, patches that does the opposite will be rejected in review.

            knielsen Kristian Nielsen added a comment - Repeating my comment from MDEV-31949 : Let me just state once and for all: The idea to binlog first and prepare in engine later for XA prepare will not be approved. Don't spend more effort in this direction. The engines, InnoDB in particular, have very mature and carefully designed and optimized write-ahead logging. This should be the primary source of recovery, not the binlog which is not very well designed or suitable as a high-performance and scalable write-ahead log. And the binlog is optional, the engine needs to implement recovery from its own log anyway. This should not be duplicated in the binlog. For normal transactions, we call innobase_xa_prepare() before binlogging. We should not do the opposite semantics for user XA PREPARE. Recovering the transaction from the binlog is not possible in all cases. Statement-based binlogging is a supported user configuration and does not admit this, even row-based binlogging doesn't support it in all cases. For these reasons, the engine prepare must come before the binlog write for XA PREPARE. Again, patches that does the opposite will be rejected in review.

            People

              bnestere Brandon Nesterenko
              Elkin Andrei Elkin
              Votes:
              2 Vote for this issue
              Watchers:
              17 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.