Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-6615

Maxscale doesn't allow granular control over repl channels

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 24.02.9
    • None
    • Monitor
    • None
    • debian 12

    Description

      I have a use case for a downstream cluster that maxscale consistently breaks my intended replication flow.

      We have an external master sending a specific schema/table list that should go to the local cluster's master always, with the other node being a full slave of the "Master, Running, Slave of External Server".

      External Master

      │ host_master (filtered schemas)

      [Active Master] ──── '' (no filters) ────► [Active Slave]

      On failover, the promoted node already has host_master from my.cnf to define those outside schemas. I intended to have the a node rejoin on channel '' but from code I see

      auto_rejoin selects the channel to redirect by taking m_slave_status[0], the first channel in SHOW ALL SLAVES STATUS order and since host_master is defined in my.cnf it starts first on boot and is always index 0. MaxScale redirects it to the new cluster master, leaving the returning node replicating via a filtered channel — silently dropping writes to non-filtered schemas. MaxScale reports the node as Slave, Running with no error. Slave status ends up looking like

      [13:22:45] root@localhost:(none) > show all slaves status\G
      *************************** 1. row ***************************
                     Connection_name: host_master
                     Slave_SQL_State: Slave has read all relay log; waiting for more updates
                      Slave_IO_State: Waiting for master to send event
                         Master_Host: Internal_master
                         Master_User: repl
                         Master_Port: 3306
                       Connect_Retry: 60
                     Master_Log_File: mysql-bin.001043
                 Read_Master_Log_Pos: 11781707
                      Relay_Log_File: relay-bin-host_master.000002
                       Relay_Log_Pos: 7424
               Relay_Master_Log_File: mysql-bin.001043
                    Slave_IO_Running: Yes
                   Slave_SQL_Running: Yes
                     Replicate_Do_DB: db_domain,db_feedback,db_kpi,db_non_shared,db_program_config,db_scoring,db_service_catalog,db_user,db_user_activity,db_unbounce,db_billing,db_email,sg
                 Replicate_Ignore_DB:
                  Replicate_Do_Table:
              Replicate_Ignore_Table: db_non_shared.email_track,db_email.recipient_status_queue,db_non_shared.email_bounce,db_user_activity.tbl_username_log_archive,db_user.tbl_bill_html_archive,db_email.queue_archive,db_email.user_email_status_archive,db_user.tbl_email_queue_archive,db_email.recipient_status_queue_archive,db_email.all_queue
      

      There is no configuration option to tell mariadbmon which channel name to use for internal cluster replication in my case.

      I built maxscale with a change to allow a rejoin_channel monitor variable and am able to set that to 'int_master' via a code change to cluster_manipulation.cc and am able to properly let maxscale maintain my desired architecture. More than will to share those full changes

      I set this as a bug because it can cause dataloss in my setup but it does seem more on the feature side.

      Thanks,
      Bryan

      Attachments

        Activity

          People

            Unassigned Unassigned
            bryan.bancroft Bryan
            Votes:
            0 Vote for this issue
            Watchers:
            1 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.