Asynchronous slave thread remains stopped after node re-joins the cluster
Bug #1288479 reported by
markus_albe
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL patches by Codership |
Fix Released
|
High
|
Seppo Jaakola | |||
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Undecided
|
Unassigned | |||
5.6 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
When a node goes into non-primary state asynchronous slave thread is halted, but then remains stopped after node successfully re-joins the cluster.
It was mentioned by Seppo that "node could restart slave thread after he joined back in cluster", but he also mentioned a caveat: "automatic slave restart can be dangerous also, DBA may have started slave in some other cluster node during the node absense".
Thus, the ideal fix would be a switch "async_
tags: | added: i39956 |
Changed in codership-mysql: | |
assignee: | nobody → Seppo Jaakola (seppo-jaakola) |
importance: | Undecided → High |
status: | New → In Progress |
milestone: | none → 5.5.36-25.10 |
Changed in codership-mysql: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Replication slave thread is not stopped automatically when node changes to non primary state, but the slave thread stopping happens when next replication event tries to apply. Node in non primary state will return 'Unknown Error' to slave applier, and slave thread then decides to stop, error message in the log is:
140320 23:56:53 [ERROR] Slave SQL: Error 'Unknown command' on query. Default database: 'test'. Query: 'BEGIN', Error_code: 1047
140320 23:56:53 [Warning] Slave: Unknown command Error_code: 1047
140320 23:56:53 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysqlbin.000001' position 555