MySQL Bugs: #2122: changing hostname confuses master or slave

Bug #2122	changing hostname confuses master or slave
Submitted:	15 Dec 2003 13:53	Modified:	13 Sep 2007 11:54
Reporter:	Guilhem Bichot	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	4.0,5.1	OS:	Any (all)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
Because the index file which lists the names of the binary logs or relay logs, has name `hostname`-bin.index, after a hostname change, mysqld does not find the file it expects (as the old index file is not `hostname`-bin.index anymore) so creates a new one. So mysqld won't be able to find the logs of before the renaming. Can confuse:
- replication
- SHOW MASTER LOGS
- PURGE MASTER LOGS

How to repeat:
see description

Suggested fix:
One option is to cancel the current `hostname`-bin.index naming convention, and choose a fixed name instead like 'mysql-bin.index' and 'mysql-relay-bin.index' (it's no problem that binary logs or relay logs still have the hostname in their name; only the index file is causing bugs; and it's good that a binary log or relay log has a name identifying its origin, when it is copied to another machine...).
For compatibility, we shall find a solution so that when users/customers upgrade from versions of before-the-naming-convention-change, the new mysqld is able to find the old index file and use it.

If one changes hostname then one must (for now) use --log-bin=old-hostname to refer to the old file(s)

In our internal Worklog system there is an entry WL#1401 for this.

This problem (identified by the error "ERROR 1201: Could not initialize master info structure, check permisions on master.info" during a slave startup) may be more in depth.

I have this problem, yet have not changed my host name.  However, the machine has many host names.  It may be using the wrong one.

In 5.0 I just added a big warning at master's start if the DBA didn't give any indication for the binlog index file name (thus causing MySQL to pick `hostname`-bin.index which is error-prone).

Fixed by adding a startup warning in 5.0 masters.

But slave can be confused too if it has its hostname changed (won't find its old relay logs).
So we either need: to warn if on slave --relay-log was not used, or to find something more automatic.

Will be fixed in 5.1 (new binlog naming conventions, automatic renaming at upgrade, to be done by Lars and me).

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/30900

I just added this kind of warning if the server is a replication slave:
051011 10:26:18 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=gbichot3-relay-bin' to avoid this problem.
This way people may less hit the problem, until it is properly fixed (by using a different naming for logs) in MySQL 5.1.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/internals/30915

It should be fixed sooner, by not giving a default value of hostname for it. Some of my colleagues have had to create new snapshots etc. just to get this fixed. A hostname change must not affect mysql, and mysql shouldn't use changable values from the server.

We are analyzing this and will fix it after 5.1 is released.  It is,
unfortunately, not likely that this will be fixed in 5.1, but we
prioritize it for the next version.

> We are analyzing this and will fix it after 5.1 is released. 

Any news on this now that we are approaching 5.6?