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

gtid_current_pos is not updated with slave transactions from old master

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • 10.1.14
    • 10.2(EOL)
    • Replication
    • None

    Description

      Hi everybody,

      According to the documentation, the gtid_current_pos should be updated with transactions from the slave threads as well:
      https://mariadb.com/kb/en/mariadb/gtid/#gtid_current_pos

      While this is not a problem in traditional replication setups (we can use slave_pos instead of current_pos) it can be a problem with setups with intermediate masters where the higher master is older version:
      Server 1 (5.5) -> Server 2a (10.1) -> server 2b (10.1)

      If we want to switch roles between 2a and 2b we stop replication from server 1 to 2a (to failover afterwards). However we cannot use gtid_slave_pos or gtid_current_pos because they are not updated: 

      MariaDB [mariadb]> select @@gtid_binlog_pos, @@gtid_slave_pos, @@gtid_current_pos;
      		 
      +------------------------+--------------------------+--------------------------+
      		 
      | @@gtid_binlog_pos      | @@gtid_slave_pos         | @@gtid_current_pos       |
      		 
      +------------------------+--------------------------+--------------------------+
      		 
      | 0-201-55312,1-1-113229 | 0-201-55312,1-102-110354 | 0-201-55312,1-102-110354 |
      		 
      +------------------------+--------------------------+--------------------------+
      		 
      1 row in set (0.00 sec)

      If we perform a transaction on server 2a the current_pos at least is updated:

      MariaDB [mariadb]> insert into test values(NULL);
      		 
      Query OK, 1 row affected (0.01 sec)
      		 
       
      		 
      MariaDB [mariadb]> select @@gtid_binlog_pos, @@gtid_slave_pos, @@gtid_current_pos;
      		 
      +--------------------------+--------------------------+--------------------------+
      		 
      | @@gtid_binlog_pos        | @@gtid_slave_pos         | @@gtid_current_pos       |
      		 
      +--------------------------+--------------------------+--------------------------+
      		 
      | 0-201-55312,1-101-113230 | 0-201-55312,1-102-110354 | 0-201-55312,1-101-113230 |
      		 
      +--------------------------+--------------------------+--------------------------+
      		 
      1 row in set (0.00 sec)

      Please make it so that current_pos (and slave_pos?) is also updated from transaction that come in from old master, as the documentation states.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-17853 Document that gtid_binlog_pos can lag behind gtid_current_pos after RESET MASTER

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-16834 GTID current_pos easily breaks replication

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-17156 Local transactions on a Slave don't update GTID's gtid_current_pos after RESET MASTER on Slave (master_use_gtid value is not relevant)

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-20122 Deprecate MASTER_USE_GTID=Current_Pos to favor new MASTER_DEMOTE_TO_SLAVE option

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Activity

            People

              Elkin Andrei Elkin
              michaeldg Michaël de groot
              Votes:
              0 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.