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

        • Type: Task
        • Status: Closed
        • Priority: Minor
        • Resolution: Fixed
        • Fix Version/s: 10.0.4
        • Component/s: None
        • Labels:
          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

            Gliffy Diagrams

              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

                  Hide
                  Permalink
                  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).

                  Show
                  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

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

                      Dates

                      • Created:
                        Updated:
                        Resolved: