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
Triage: Triaged: D4 (Minor)

[15 Dec 2003 13:53] Guilhem Bichot
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.
[30 Jan 2004 5:56] Michael Widenius
If one changes hostname then one must (for now) use --log-bin=old-hostname to refer to the old file(s)
[30 Jan 2004 5:57] Guilhem Bichot
In our internal Worklog system there is an entry WL#1401 for this.
[23 Apr 2004 6:06] Ben Clewett
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.
[17 Jan 2005 20:41] Guilhem Bichot
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).
[17 Jan 2005 21:32] Guilhem Bichot
Fixed by adding a startup warning in 5.0 masters.
[25 Jan 2005 9:53] Guilhem Bichot
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.
[24 Apr 2005 21:11] Guilhem Bichot
Will be fixed in 5.1 (new binlog naming conventions, automatic renaming at upgrade, to be done by Lars and me).
[11 Oct 2005 8:33] Bugs System
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
[11 Oct 2005 8:35] Guilhem Bichot
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.
[11 Oct 2005 13:03] Bugs System
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
[9 Aug 2006 7:38] John Saul
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.
[13 Sep 2007 11:54] Lars Thalmann
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.
[15 Dec 2012 9:57] Hartmut Holzgraefe
> We are analyzing this and will fix it after 5.1 is released. 

Any news on this now that we are approaching 5.6?