MySQL Bugs: #60947: create database if exists cause a loop in master/slave replication

Bug #60947	create database if exists cause a loop in master/slave replication
Submitted:	21 Apr 2011 16:10	Modified:	19 Oct 2016 23:01
Reporter:	Cyril SCETBON	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S1 (Critical)
Version:	5.1.51-ndb-7.1.10	OS:	Linux (ubuntu lucid x86)
Assigned to:	MySQL Verification Team	CPU Architecture:	Any
Tags:	cluster, replication

Description:
we have an architecture with one master and one slave. Both hosts are connected on the same cluster cause we need to access both clustered/non-clustered tables. So we need to replicate non-clustered tables from the master to the slave.

However we noticed that when we do a 'CREATE DATABASE IF NOT EXISTS' on the master, the order loops forever between the slave and the master. However, if we use 'CREATE DATABASE' instead of 'CREATE DATABASE IF NOT EXISTS' we don't meet this issue. The order is well replicated on the slave and is not redone forever by the master. up to now, if we want to stop this loop, we have to stop the slave

How to repeat:
use our architecture, and try a 'create database if exists d1' on the master

Suggested fix:
use a drop+create database sequence (without if not exists) instead

I've tested with the last GA and got the same issue. I'll test with the last development release

verified too in 5.1.51-ndb-7.2.0-devmilestone-cluster-gpl-log

Below is our architecture

| cluster1 ] <---> Master B -------> Master A <----------------> | cluster2 |
                                         |                            ^ 
                                         ----------> Slave C <--------|

This bug is related to the variable log-slave-updates which is set in our master (A) configuration file. We need this variable as our master (A) is the slave of another master host (B) on which cluster tables and non-clustered tables (not modified on A or C) are updated, in order to get this modifications being replicated to our slave host (C).
master B stores clustered tables as non clustered tables, so we want it to replicate everything to our master (A) and we use replicate_wild_ignore_table on our slave (C) to not replicate clustered tables modifications as slave C and master A are connected to the same cluster.

I can't reproduce this on any of the latest releases