Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-253 Multi-source replication
  3. MDEV-555

Multi-source: More status variables need to be either local for a replication connection, or truly global across all slaves



    • Type: Technical task
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:


      Slave_heartbeat_period currently shows the value for the connection with an empty name, even if default_master_connection is set differently.
      Same for Slave_received_heartbeats.
      A test case for heartbeats is below. It is supposed to be used with my.cnf from the multi_source suite. There is no need to add the test to the suite, it will be a part of a bigger test.

      I don't have a strong opinion whether Slave_retried_transactions should be local or global, I guess either is fine, but if it's global, it should show the total number of retried transactions for all slaves, which now does not seem to be the case. I will add a test case for it when we have a decision how it should work.

      Slave_open_temp_tables seems to show the overall number of open temporary tables across all slaves, which probably makes sense, since the idea is to use it to make sure that it's save to shutdown the slave server, which means we need to know that there are no open temporary tables across all replication connections. So, it already works.

      Test case for heartbeats. The idea is the following:

      • in initial configuration, it sets different master_heartbeat_period for two connections, and later checks the value of 'Slave_heartbeat_period'. Currently it shows the same value for both connections (I believe it always shows the value of an anonymous connection, whether it's configured or not).
      • then, the slave is stopped, the period is changed to a really short value (1-2 sec), started again, and the test waits for the value of Slave_received_heartbeats to be increased. First, it does so for the anonymous connection, and waits for 2 heartbeats. Then it stops the slave, switches default_master_connection to a named connection, and attempts to do the same, only now it waits for 1 heartbeat. The waiting ends with a timeout, because the variable still shows the value of the anonymous connection (2), so it never becomes equal 1.

      cat suite/multi_source/heartbeats.test

      --connect (slave,,root,,,$SERVER_MYPORT_3)
      # Start replication from the first master
      --replace_result $SERVER_MYPORT_1 MYPORT_1
      eval change master 'master1' to
      master_heartbeat_period = 25;
      start slave 'master1';
      set default_master_connection = 'master1';
      --source include/wait_for_slave_to_start.inc
      # Set up a 'default' anonymous connection to master2
      set default_master_connection = '';
      --replace_result $SERVER_MYPORT_2 MYPORT_2
      eval change master to
      start slave;
      --source include/wait_for_slave_to_start.inc
      set default_master_connection = '';
      show status like 'Slave_heartbeat_period';
      stop slave;
      --source include/wait_for_slave_to_stop.inc
      change master to master_heartbeat_period=1;
      start slave;
      --source include/wait_for_slave_to_start.inc
      --let $status_var = Slave_received_heartbeats
      --let $status_var_value = 2
      # The units are tens of seconds
      --let $status_timeout = 30
      --source include/wait_for_status_var.inc
      show status like 'Slave_received_heartbeats';
      stop slave;
      --source include/wait_for_slave_to_stop.inc
      set default_master_connection = 'master1';
      show status like 'Slave_heartbeat_period';
      stop slave;
      change master to master_heartbeat_period=2;
      start slave;
      --source include/wait_for_slave_to_start.inc
      --let $status_var_value = 1
      --source include/wait_for_status_var.inc
      show status like 'Slave_received_heartbeats';




            monty Michael Widenius
            elenst Elena Stepanova
            0 Vote for this issue
            2 Start watching this issue



                Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.