MySQL Bugs: #32913: Multiple errors on a slave

Bug #32913	Multiple errors on a slave
Submitted:	2 Dec 2007 20:23	Modified:	18 Aug 2008 7:32
Reporter:	Oleksiy Kovyrin	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.0.45	OS:	Linux
Assigned to:		CPU Architecture:	Any
Tags:	binlog, filters, replication, slave

Description:
We have a set of servers using 5.0.45 (one master and a bunch on slaves). Now we're trying to add a new slave to our system with a following changes:

1) database name changed (needs rewriting)
2) only a small subset of tables needed on a slave

So, we're trying to use following config on the slave:

# Change database in replication
replicate-rewrite-db="collegelist_production->texts"

# Replication for these tables only:
replicate-wild-do-table=collegelist_production.collegelist_production
replicate-wild-do-table=collegelist_production.word_documents
replicate-wild-do-table=collegelist_production.word_tags
replicate-wild-do-table=collegelist_production.word_documents_word_tags
replicate-wild-do-table=collegelist_production.word_requests
replicate-wild-do-table=collegelist_production.word_uploads
replicate-wild-do-table=collegelist_production.word_users
replicate-wild-do-table=collegelist_production.groups
replicate-wild-do-table=collegelist_production.word_stats

When we try to start this slave, error log is full of following messages:

071202  2:32:43 [Note] Slave: connected to master 'repl@10.10.170.8:3306',replication resumed in log 'binlog.000406' at position 955691279
071202  2:32:43 [Note] Slave: received end packet from server, apparent master shutdown: 
071202  2:32:43 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'binlog.000406' position 955692237
071202  2:32:43 [Note] Slave: connected to master 'repl@10.10.170.8:3306',replication resumed in log 'binlog.000406' at position 955692237
071202  2:32:43 [Note] Slave: received end packet from server, apparent master shutdown: 
071202  2:32:43 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'binlog.000406' position 955692237

And it continue tries every few milliseconds (100s times per second).

On the master on this position we have a correct statements (I mean binlog position is correct, master was not restarted).

If we try to change a position on a slave, it does not help at all.

How to repeat:
Really don't know.

Suggested fix:
Really don't know.

Changed replicate-*-table statements to use rewritten name of the database:

    Replicate_Wild_Do_Table: texts.texts, texts.word_documents, texts.word_tags, texts.word_documents_word_tags, texts.word_requests, texts.word_uploads, texts.word_users, texts.groups, texts.word_stats, texts.texts, texts.word_documents, texts.word_tags, texts.word_documents_word_tags, texts.word_requests, texts.word_uploads, texts.word_users, texts.groups,texts.word_stats

And now it worked. But anyways, this looks like a bug.

Actually, it started crashing when slave caught up.

Switched new server to replicate from one of the slaves - works fine so far.

Thank you for a problem report. Is this bug repeatable with a new setup? If yes, please, try to check if it is still repeatable with a newer version, 5.0.51a, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Oleksiy,

did I understand you right?
This won't happen by using newer version?
Can we close this issue?

Actually, we've tried 5.0.51 and it was crashing too. We've changed our replication scheme now and it is not crashing anymore, but I do not think that but is fixed - this is just a workaround.

Thank you for the feedback.

> We've changed our replication scheme now and it is not crashing anymore, but I do not think that but is fixed - this is just a workaround.

There was not real crash, but replication stopped working. Also changing scheme is not workaround, but only correct way to do what you need if you use option replicate-rewrite-db. Only problem which I can see here is not nice error message in the error log file, although is not clear why mysqld should guess what you want to do. So I close the report as "Not a Bug".