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

Bug #2122	changing hostname confuses master or slave
Submitted:	15 Dec 2003 14:53	Modified:	13 Sep 2007 13:54
Reporter:	Guilhem Bichot
Status:	Verified
Category:	Server: Replication	Severity:	S3 (Non-critical)
Version:	4.0,5.1	OS:	Any (all)
Assigned to:	Zhenxing He	Target Version:	6.x
Triage:	D4 (Minor)

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.