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

FR: Indicate GTID-based start position in the error log on slave start

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 10.0.4
    • None
    • None

    Description

      When a slave starts in the old-style way, the record in the server error log contains information about start coordinates:

      130506 18:25:24 [Note] Slave I/O thread: Start asynchronous replication to master 'root@127.0.0.1:3306' in log 'ubuntu12-04-bin.000002' at position 377
      		 
      130506 18:25:24 [Note] Slave SQL thread initialized, starting replication in log 'ubuntu12-04-bin.000002' at position 377, relay log './ubuntu12-04-relay-bin.000001' position: 4
      		 
      130506 18:25:24 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:3306',replication started in log 'ubuntu12-04-bin.000002' at position 377

      But with GTID, the position is always zero, both for SQL and IO thread:

      130506 18:23:57 [Note] Slave I/O thread: Start asynchronous replication to master 'root@127.0.0.1:3306' in log 'FIRST' at position 0
      		 
      130506 18:23:57 [Note] Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log './ubuntu12-04-relay-bin.000001' position: 4
      		 
      130506 18:23:57 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:3306',replication started in log 'FIRST' at position 0

      I suppose it might be impossible to log the old-style position at this point since it might be unknown (right?), but then it would be good to log the GTID position which the slave attempts to acquire, otherwise it's totally impossible to understand where the slave was at the moment of (re)start.

      bzr version-info

      revision-id: knielsen@knielsen-hq.org-20130506123534-v8r8bhazhj5gr1he
      		 
      revno: 3628
      		 
      branch-nick: 10.0-base

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-26 Global transaction ID

          • Major - Major loss of function.
          • Closed

          Activity

            knielsen Kristian Nielsen added a comment -

            The current code in 10.0-base now gives better information
            about what it is doing, GTID-wise, when the slave is using GTID.

            There are still a couple of printouts that are done by plugins (I
            think semisync plugin). Those do not yet output any GTID info,
            as the interface and structs used there do not include the new
            GTID info. I think that is ok for now, there are other printouts
            that do have the GTID info. (We can maybe extend the
            plugin stuff later, or maybe leave it if not needed).

            knielsen Kristian Nielsen added a comment - The current code in 10.0-base now gives better information about what it is doing, GTID-wise, when the slave is using GTID. There are still a couple of printouts that are done by plugins (I think semisync plugin). Those do not yet output any GTID info, as the interface and structs used there do not include the new GTID info. I think that is ok for now, there are other printouts that do have the GTID info. (We can maybe extend the plugin stuff later, or maybe leave it if not needed).

            People

              knielsen Kristian Nielsen
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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