Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
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
-
-
- Closed
-