IO thread on crash safe replication uses older binary coordinates after slave server restarts after a crash

Bug #1239958 reported by Jaime Sicam
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Invalid
Undecided
Unassigned
5.1
Invalid
Undecided
Unassigned
5.5
Expired
High
Unassigned
5.6
Invalid
Undecided
Unassigned

Bug Description

Tested on VirtualBox VM running MySQL Sandbox:

Crash resistant replication enabled:
innodb_recovery_update_relay_log=1

Ran this on master:
mysql --port=22987 < employees.sql

Turned off VirtualBox, turned it on and started MySQL slave instances. Relevant error log below:
InnoDB: Warning: innodb_overwrite_relay_log_info is enabled. Updates by other storage engines may not be synchronized.
InnoDB: relay-log.info is detected.
InnoDB: relay log: position 39469633, file name ./mysql_sandbox22988-relay-bin.000008
InnoDB: master log: position 39469487, file name mysql-bin.000003
***
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 40495923, file name mysql-bin.000003
InnoDB: and relay log file
InnoDB: position 40496069, file name ./mysql_sandbox22988-relay-bin.000008
***
131015 7:16:07 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000003' at position 40495923, relay log './mysql_sandbox22988-relay-bin.000008' position: 40496069
131015 7:16:07 [Note] Slave I/O thread: connected to master 'rsandbox@127.0.0.1:22987',replication started in log 'mysql-bin.000003' at position 39469487

Note:
Tried to kill mysql slave instances with kill -9 and kill -11 but could not reproduce it so I tried turning of Virtual Box instead.

Jaime Sicam (jssicam)
summary: IO thread on crash safe replication uses older binary coordinates after
- slave server restarts
+ slave server restarts after a crash
Revision history for this message
George Ormond Lorch III (gl-az) wrote :

Trying to reproduce this particular issue on current PS 5.5 trunk (revno 588) and continually hit a different bug that I reported as 1243953. I can't seem to reproduce this exactly as described above ut that is likely just due to timing differences.

Revision history for this message
Muhammad Irfan (muhammad-irfan) wrote :

I tested it with Percona Server 5.6 for Oracle crash-safe slaves feature and i didn't able to reproduce it atleast on crash-safe slaves feature.

Revision history for this message
Muhammad Irfan (muhammad-irfan) wrote :

I tried to simulate this on Percona Server 5.1.73 but i am not able to reproduce it. I used mysqlslap utility to generate write load on master and shutdown mysql forcefully by poweroff virtualbox, kill -9 mysqld process but found that this feature worked as expected.

tags: added: i41005
tags: added: crash-resistant-slave-5.5
Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Everybody affected by this bug -

Can you still reproduce it, or have there been any past incidents, with --relay_log_recovery set to ON? The requirement for this setting has not been documented in our crash-resistant slave docs.

Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

See https://bugs.launchpad.net/percona-server/5.6/+bug/1406482 for the related documentation request.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Percona Server 5.5 because there has been no activity for 60 days.]

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-131

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.