MySQL Bugs: #12365: can't create tables when mysqld runs with ndbcluster option

Bug #12365	can't create tables when mysqld runs with ndbcluster option
Submitted:	4 Aug 2005 7:11	Modified:	28 Oct 2005 11:59
Reporter:	Kai Voigt	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.1,5.0	OS:	MacOS (MacOSX, Linux)
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
MySQL won't let you create tables when ndbcluster is enabled but no cluster is running.

> create table a (b int);
ERROR 1050 (42S01): Table 'a' already exists

How to repeat:
Put the "ndbcluster" option in the [mysqld] section of /etc/my.cnf

Don't have any other cluster parts configured or running, i.e. no ndb_mgmd, no ndbd

Start mysqld as usual

Make sure your default storage engine is something "normal"
> show variables like 'storage_engine';

Create some table.
> use test
> create table a (b int);

See the error:
ERROR 1050 (42S01): Table 'a' already exists 

Suggested fix:
no idea

I have the same issue on a source-built 4.1.13 on Linux; nmb enabled:

mysql> create table a (b int);
ERROR 1050 (42S01): Table 'a' already exists

nmb disabled:

mysql> create table a (b int);
Query OK, 0 rows affected (0.01 sec)

System Details;
Slackware-current, Kernel 2.4.31, i686
GNU C Library stable release version 2.3.5, Compiled by GNU CC version 3.3.5, Compiled on a Linux 2.4.30 system on 2005-05-15, 
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        linuxthreads-0.10 by Xavier Leroy
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Thread-local storage support included.

MySQL built using gcc 3.3.6:
CFLAGS="-O3 -march=i686 -mcpu=i686" CXX=gcc CXXFLAGS="-O3 -march=i686 -mcpu=i686 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-big-tables --with-gnu-ld --with-mysqld-user=mysql --without-debug --with-openssl=/usr --with-extra-charsets=all --with-archive-storage-engine --with-csv-storage-engine --with-ndbcluster

see also bug #12666

This sounds like it is by-design.

If you're not connected to the cluster, you cannot know what tables are stored there. If we created a table with the same name as one in the cluster, what would happen when we reconnect to the cluster and access that table name? Do we access the local one or the one on the cluster?

Unless there's further insight, we should probably put this into Documenting so this can be made clear in the manual.

This has been like this since the start.

Reason being that if mysqld is not connected to the cluster, one cannot know that some other mysqld has created a table with the same name in ndbcluster.   Error message should be different though.

Please tell us which way you think it should be, and motivate the reason for it.

We could instead let the user create the table, but issue a warning.

The strange thing about this is that i can't reproduce it on my local installation of 4.1.12,
i can't create tables with enginge=ndb:

> create table m5(i int) engine=ndb;
ERROR 1005 (HY000): Can't create table './test/m5.frm' (errno: 4009)

but i can create myisam tables just fine ...

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/31605

To allow creation of a table without being able to check in NDB Cluster if table already exists is not a desired behaviour. Since the MySQL Server was started with --ndbcluster option it has to ask NDB if the table exists there before allowing it to be created.

Thus if you want to create the table locally wihtout contacting NDB start the MySQL Server without --ndbcluster option. It is however not recomended to do that.