Bug #19546 Duplicate databases in Replicate_Do_DB
Submitted: 4 May 2006 20:54 Modified: 17 Jun 2008 19:05
Reporter: Xin Li Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server Severity:S2 (Serious)
Version:5.0.19 OS:Linux (Linux)
Assigned to: CPU Architecture:Any

[4 May 2006 20:54] Xin Li
Description:
when I setup replication, I specify a database in my.cnf - replicate-do-db=mydb; however, when I start slave and "show slave status", I saw 2 databases: "Replicate_Do_DB: mydb,mydb", which is just an extra duplicate database.

How to repeat:
set up replication, put "replicate-do-db=mydb" in my.cnf file; start both of master and slave; start slave; show slave status;
[6 May 2006 15:16] MySQL Verification Team
Thank you for the bug report. I was unable to repeat the behavior
reported:

miguel@hegel:~/dbs/5.0s> bin/mysql --defaults-file=/home/miguel/dbs/5.0s/var/my.cnf -uroot
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2 to server version: 5.0.22-debug

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CHANGE MASTER TO
    -> MASTER_HOST='localhost',
    -> MASTER_USER='miguel',
    -> MASTER_PASSWORD='slaveuser',
    -> MASTER_LOG_FILE='mysql-bin.000001',
    -> MASTER_LOG_POS=306;
Query OK, 0 rows affected (0.03 sec)

mysql> START SLAVE;
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: localhost
                Master_User: miguel
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000001
        Read_Master_Log_Pos: 306
             Relay_Log_File: hegel-relay-bin.000002
              Relay_Log_Pos: 235
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: mydb
        Replicate_Ignore_DB: 
         Replicate_Do_Table: 
     Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 306
            Relay_Log_Space: 235
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.01 sec)

mysql>
[8 May 2006 12:55] Xin Li
I still got the duplicate database names when I show slave status!

when I have "replicate-do-db=bugs,test" in my.cnf, I got:

Replicate_Do_DB: bugs,test,bugs,test

when I have "replicate-do-db=bugs", I got 

Replicate_Do_DB: bugs,bugs

I'm using mysql-standard-5.0.19-linux-i686-glibc23 on Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
[8 May 2006 12:56] Xin Li
By the way, can you please post your my.cnf here?
[8 May 2006 13:17] MySQL Verification Team
Hi,

Master my.cnf

miguel@hegel:~> cat /home/miguel/dbs/5.0/var/my.cnf 
[client]
port=3306
socket=/home/miguel/dbs/5.0/mysql.sock

[mysqld]
basedir=/home/miguel/dbs/5.0/
datadir=/home/miguel/dbs/5.0/var
port=3306
socket=/home/miguel/dbs/5.0/mysql.sock
log-bin=mysql-bin
server-id=1

I deleted my slave installation, however I did something like below:

[client]
port=3307
socket=/home/miguel/dbs/5.0s/mysql.sock

[mysqld]
basedir=/home/miguel/dbs/5.0s/
datadir=/home/miguel/dbs/5.0s/var
port=3307
socket=/home/miguel/dbs/5.0s/mysql.sock
log-bin=mysql-bin
server-id=2
replicate-do-db=mydb
[8 May 2006 14:21] Xin Li
I just installed MySQL 5.0.19 (Without installer) for Windows, and setup a replication in the same way I did for Linux. This time, I got correct value:

Replicate_Do_DB: bugs

Why?

Are you using Linux version or Windows version of MySQL 5.0.19 for your testing?
[8 May 2006 14:31] MySQL Verification Team
I tested with current source server on Suse Linux 10.0.
[8 May 2006 14:54] Xin Li
I updated MySQL to 5.0.21 for Linux, I got the same behaviour:

Replicate_Do_DB: bugs, test,bugs, test
[8 May 2006 15:10] Xin Li
Can you please try to use binary installation? Thanks.
[22 May 2006 4:22] Ed Ayvazyan
Same issue is here, both servers (master and slave) are mysqld  Ver 5.0.21-standard-log for pc-linux-gnu on i686 (MySQL Community Edition - Standard (GPL)) installed from MySQL-server-5.0.21-0.i386.rpm on Fedora Core 4, kernel 2.6.11-1.1369_FC4smp

Below is the output of show slave status
mysql> show slave status\G
*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: ***
                Master_User: ***
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: us-bin.000030
        Read_Master_Log_Pos: 49675530
             Relay_Log_File: ***-relay-bin.000134
              Relay_Log_Pos: 146689
      Relay_Master_Log_File: us-bin.000030
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        Replicate_Ignore_DB: horde,information_schema,eximstats,horde,information_schema,eximstats
         Replicate_Do_Table: 
     Replicate_Ignore_Table: see my comments below!!
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
                 Last_Errno: 0
                 Last_Error: 
               Skip_Counter: 0
        Exec_Master_Log_Pos: 49675530
            Relay_Log_Space: 146689
            Until_Condition: None
             Until_Log_File: 
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File: 
         Master_SSL_CA_Path: 
            Master_SSL_Cert: 
          Master_SSL_Cipher: 
             Master_SSL_Key: 
      Seconds_Behind_Master: 0
1 row in set (0.00 sec)

Replicate_ignore_table looks even more interesting. Unfortunately, I cannot publish the table names, hence they belong to our customers, but the situation is the same as with the databases (duplicated twice), the only difference is databases look ordered (db1,db2,db3,db1,db2,db3) while tables are chaotic (table1,table2,table3,table2,table1,table3)
Before upgrading to 5.0.21 I was using 5.0.18. 
This problem did not exist in 5.0.18 with the same configuration.
[22 May 2006 17:43] Xin Li
So, does it mean the "bug" was introduced since 5.0.19?
[5 Jul 2006 8:45] Alex Lapin
I am also having this bug in my installation of 5.0.22 . I just upgraded 2 slave servers from 5.0.15 and got this bug on both ones.
[23 Sep 2006 19:07] MySQL Verification Team
This behavior could also be related to the report here:
http://bugs.mysql.com/bug.php?id=20748

All users should check to see if they have multiple config files and resolve any duplication issues to see if this resolves the reported behavior.
[25 Sep 2006 14:37] Xin Li
I checked my env, there is no /etc/my.cnf. We do have 2 symlinks which are

1) /usr/local/mysql -> /usr/local/mysql-standard-5.0.19-linux-i686-glibc23
2) /usr/local/mysql/data -> /home/mysql/data/

our my.cnf file is in /usr/local/mysql/data dir.

Here is the setting for /etc/init.d/mysql.server:

basedir=/usr/local/mysql
datadir=/usr/local/mysql/data

Here is the info for the processese:

mysql    6037     1  0 Sep12 ?        00:00:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/usr/local/mysql/data --pid-file=/usr/local/mysql/data/myhost.pid --user=mysql
mysql    6071  6037  0 Sep12 ?        02:31:33 /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --pid-file=/usr/local/mysql/data/myhost.pid --skip-locking --port=3306 --socket=/tmp/mysql.sock

By the way, we upgraded MySQL to 5.0.23 and still have the issue.
[16 Jun 2008 18:50] Mike Slywka
I am now seeing this bug in the following version:
mysqld  Ver 5.0.51a-community-log for redhat-linux-gnu on x86_64
Could someone please tell me in which release this will be fixed? Are there any known work arounds?
I have seen a patch that doesn't seem to apply to the version I have installed and forcing the server to start with the --defaults-file option doesn't work for me either.

Thanks
[17 Jun 2008 19:04] James Day
The fix for bug #20748 fixes this for most cases as of versions 5.0.54, 5.1.23 and 6.0.4. There's still a fix for a case where non-normalised names can cause it that hasn't yet been included in a release.

Since this is a duplicate bug please comment over in bug #20748 to ensure that your reports aren't missed.