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

Port rpl_semi_sync_master_wait_for_slave_count from MySQL

Details

    • New Feature
    • Status: Stalled (View Workflow)
    • Critical
    • Resolution: Unresolved
    • 12.1
    • Replication
    • None
    • Q2/2025 Development

    Description

      MySQL 5.7.3 added the rpl_semi_sync_master_wait_for_slave_count option for semisynchronous replication:

      The number of slave acknowledgments the master must receive per transaction before proceeding. By default rpl_semi_sync_master_wait_for_slave_count is 1, meaning that semisynchronous replication proceeds after receiving a single slave acknowledgment. Performance is best for small values of this variable.

      For example, if rpl_semi_sync_master_wait_for_slave_count is 2, then 2 slaves must acknowledge receipt of the transaction before the timeout period configured by rpl_semi_sync_master_timeout for semisynchronous replication to proceed. If less slaves acknowledge receipt of the transaction during the timeout period, the master reverts to normal replication.

      Note
      This behavior also depends on rpl_semi_sync_master_wait_no_slave

      This variable is available only if the master-side semisynchronous replication plugin is installed.

      https://dev.mysql.com/doc/refman/5.7/en/replication-options-master.html#sysvar_rpl_semi_sync_master_wait_for_slave_count

      Can we port this from MySQL?

      Attachments

        Issue Links

          Activity

            Elkin Andrei Elkin added a comment -

            GeoffMontee: Thanks for reporting it! The counter may help to raise HA level, but it does not cancel semisync architectural limitation (such as lack of membership consensus). I think we are better off to drive towards full synchronous replication MDEV-19410. ralf.gebhardt@mariadb.com ^

            Elkin Andrei Elkin added a comment - GeoffMontee : Thanks for reporting it! The counter may help to raise HA level, but it does not cancel semisync architectural limitation (such as lack of membership consensus). I think we are better off to drive towards full synchronous replication MDEV-19410 . ralf.gebhardt@mariadb.com ^
            ParadoxV5 Jimmy Hú added a comment -

            The new duplicate brought this to our attention again, and we were talking about adding this anyway to spearhead Full-Sync.

            ParadoxV5 Jimmy Hú added a comment - The new duplicate brought this to our attention again, and we were talking about adding this anyway to spearhead Full-Sync.

            Added to the 12.1 roadmap. Estimated timeline (10d) would be

            • 3 days to port the code-portion of the patch
            • 3 days to write the MTR tests
            • 1 day for patch cleanup
            • Half-day for review
            • One-day to address review findings
            • Half-day for documentation

            ParadoxV5, with your recent introduction to semi-sync, this is a great ticket to start learning more about the different semi-sync components

            Note that in MySQL, semi-sync is (still) a plugin, and the code structure is a fair bit different than ours nowadays. So the patch won't be a straight-forward pick (and likely will more-so serve as a guideline to write ours from scratch, rather than trying to merge it at all).

            bnestere Brandon Nesterenko added a comment - Added to the 12.1 roadmap. Estimated timeline (10d) would be 3 days to port the code-portion of the patch 3 days to write the MTR tests 1 day for patch cleanup Half-day for review One-day to address review findings Half-day for documentation ParadoxV5 , with your recent introduction to semi-sync, this is a great ticket to start learning more about the different semi-sync components Note that in MySQL, semi-sync is (still) a plugin, and the code structure is a fair bit different than ours nowadays. So the patch won't be a straight-forward pick (and likely will more-so serve as a guideline to write ours from scratch, rather than trying to merge it at all).
            ParadoxV5 Jimmy Hú added a comment -

            The feature should be implemented. While it’s ready for review besides testing, I would prefer we first refactor our code to solve the hindrances I encountered.
            As they are code-specific and not relevant to the logic of features, I leave the details here: https://github.com/MariaDB/server/pull/4037#discussion_r2087535165

            ParadoxV5 Jimmy Hú added a comment - The feature should be implemented. While it’s ready for review besides testing, I would prefer we first refactor our code to solve the hindrances I encountered. As they are code-specific and not relevant to the logic of features, I leave the details here: https://github.com/MariaDB/server/pull/4037#discussion_r2087535165

            People

              ParadoxV5 Jimmy Hú
              GeoffMontee Geoff Montee (Inactive)
              Jimmy Hú Jimmy Hú
              Brandon Nesterenko Brandon Nesterenko
              Susil Behera Susil Behera
              Votes:
              1 Vote for this issue
              Watchers:
              5 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.