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

Parallel replication with --log-slave-updates=0 is very slow

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.8
    • Fix Version/s: N/A
    • Component/s: Replication
    • Labels:
      None

      Description

      In parallel replication, given transactions T1,T2 in the binlog, the code
      needs to have T2 wait sufficiently long that T1 will commit before T2 on the
      slave, preserving binlog order.

      The binlog commit code is optimised to handle this wait well with respect to
      performance. However, when binlog is not used on the slave, commit is handled
      instead by the normal commit code in handler.cc and InnoDB, which is missing
      these optimisations. This results in poor performance, to the point that
      turning off the binlog when parallel replication is enabled actually
      decreases the performance.

      This should be improved by implementing similar wait optimisations for the
      non-binlog case as for the binlog case. Possibly, all that is needed is for
      InnoDB to call THD::wakeup_subsequent_commits as soon as the commit order for
      the transaction has been decided.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            knielsen Kristian Nielsen added a comment -

            InnoDB/XtraDB now calls wakeup_subsequent_commits after "fast" part of commit, in the case where binlogging is not done (this was done some time ago).

            Hopefully this fixes the problem. If benchmarks later show that things are still slower than expected, we can re-open this.

            Show
            knielsen Kristian Nielsen added a comment - InnoDB/XtraDB now calls wakeup_subsequent_commits after "fast" part of commit, in the case where binlogging is not done (this was done some time ago). Hopefully this fixes the problem. If benchmarks later show that things are still slower than expected, we can re-open this.

              People

              • Assignee:
                knielsen Kristian Nielsen
                Reporter:
                knielsen Kristian Nielsen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: