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

Implement asynchronous connection failover mechanism to automatically establish an asynchronous replication when current master is un-reachable..

Details

    • Task
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • Replication
    • None

    Description

      Hi Team,

      Customers requesting to implement asynchronous connection failover mechanism to automatically establish an asynchronous replication when master is un-reachable..

      In this feature already available in MySQL 8.0

      For more reference - https://dev.mysql.com/doc/refman/8.0/en/replication-asynchronous-connection-failover.html

      Attachments

        Activity

          We are expecting this mainly for Galera cluster.. From Galera cluster to asynchronous external slave server. If one of the cluster is down then it should automatically connect to the other Galera available node.

          naresh.chandra@copart.com Naresh Chandra added a comment - We are expecting this mainly for Galera cluster.. From Galera cluster to asynchronous external slave server. If one of the cluster is down then it should automatically connect to the other Galera available node.
          johan.wikman Johan Wikman added a comment -

          ralf.gebhardt In the case of a MariaDB cluster this is already possible using MaxScale.

          Suppose you have a MariaDB cluster consisting of servers S1, S2, S3 and S4 and an external slave server SX. Further, assume S1 is master and that SX is replicating from it.

          If the MaxScale MariaDB monitor is now setup to monitor S1, S2, S3, S4 and SX, and the monitor configuration contains

          servers_no_promotion=SX
          

          and the MaxScale service is configured to only use S1, S2, S3 and S4, then I think the behaviour should match what is wanted.

          If the current master S1 goes down and the MariaDB monitor promotes, say, S2 to new master, it will reconfigure not only S3 and S4, but also SX to replicate from S2.

          The Galera monitor is not smart enough for this.

          johan.wikman Johan Wikman added a comment - ralf.gebhardt In the case of a MariaDB cluster this is already possible using MaxScale. Suppose you have a MariaDB cluster consisting of servers S1, S2, S3 and S4 and an external slave server SX. Further, assume S1 is master and that SX is replicating from it. If the MaxScale MariaDB monitor is now setup to monitor S1, S2, S3, S4 and SX, and the monitor configuration contains servers_no_promotion=SX and the MaxScale service is configured to only use S1, S2, S3 and S4, then I think the behaviour should match what is wanted. If the current master S1 goes down and the MariaDB monitor promotes, say, S2 to new master, it will reconfigure not only S3 and S4, but also SX to replicate from S2. The Galera monitor is not smart enough for this.

          People

            Unassigned Unassigned
            ponsuresh.pandians Pon Suresh Pandian (Inactive)
            Votes:
            2 Vote for this issue
            Watchers:
            6 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.