still have to talk to people about standards for this sort of thing and all that. But as a first checkin – funkyness++!

mysql> select * from INFORMATION_SCHEMA.DATAFILES;  select * 
from INFORMATION_SCHEMA.TABLESPACES;
Empty set (0.03 sec)

Empty set (0.00 sec)

mysql> CREATE TABLESPACE ts1 ADD DATAFILE 'datafile.dat' USE 
LOGFILE GROUP lg1 INITIAL_SIZE = 12M ENGINE NDB;
Query OK, 0 rows affected (2.35 sec)

mysql> select * from INFORMATION_SCHEMA.DATAFILES;  select * 
from INFORMATION_SCHEMA.TABLESPACES;
+--------------+--------+--------------+----------+------+------------+
| NAME         | ENGINE | PATH         | SIZE     | FREE | TABLESPACE |
+--------------+--------+--------------+----------+------+------------+
| datafile.dat | NDB    | datafile.dat | 12582912 |   11 |            |
+--------------+--------+--------------+----------+------+------------+
1 row in set (0.00 sec)

+------+--------+---------+-------------+-----------------------+
| NAME | ENGINE | VERSION | EXTENT_SIZE | DEFAULT_LOGFILE_GROUP |
+------+--------+---------+-------------+-----------------------+
| ts1  | NDB    |       1 |     1048576 |                     0 |
+------+--------+---------+-------------+-----------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLE t1 
(pk1 int not null primary key auto_increment,
 b int not null, 
c int not null) 
tablespace ts1 storage disk engine ndb; 
Query OK, 0 rows affected (0.62 sec)

mysql> insert into t1 (b,c) values (1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),
(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),
(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4),(1,2),(2,3),(3,4);
Query OK, 36 rows affected (0.11 sec)
Records: 36  Duplicates: 0  Warnings: 0

mysql> select * from INFORMATION_SCHEMA.DATAFILES;  select * 
from INFORMATION_SCHEMA.TABLESPACES; 
+--------------+--------+--------------+----------+------+------------+ 
| NAME         | ENGINE | PATH         | SIZE     | FREE | TABLESPACE |
+--------------+--------+--------------+----------+------+------------+
| datafile.dat | NDB    | datafile.dat | 12582912 |    9 |            |
+--------------+--------+--------------+----------+------+------------+
1 row in set (0.02 sec)

+------+--------+---------+-------------+-----------------------+
| NAME | ENGINE | VERSION | EXTENT_SIZE | DEFAULT_LOGFILE_GROUP |
+------+--------+---------+-------------+-----------------------+
| ts1  | NDB    |       1 |     1048576 |                     0 |
+------+--------+---------+-------------+-----------------------+
1 row in set (0.00 sec)

mysql> CREATE TABLESPACE ts2 ADD DATAFILE 'datafile2.dat' 
USE LOGFILE GROUP lg1 INITIAL_SIZE = 12M ENGINE NDB;
Query OK, 0 rows affected (2.18 sec)

mysql> select * from INFORMATION_SCHEMA.DATAFILES;  select * 
from INFORMATION_SCHEMA.TABLESPACES;
+---------------+--------+---------------+----------+------+------------+
| NAME          | ENGINE | PATH          | SIZE     | FREE | TABLESPACE |
+---------------+--------+---------------+----------+------+------------+
| datafile2.dat | NDB    | datafile2.dat | 12582912 |   11 |            |
| datafile.dat  | NDB    | datafile.dat  | 12582912 |    9 |            |
+---------------+--------+---------------+----------+------+------------+
2 rows in set (0.02 sec)

+------+--------+---------+-------------+-----------------------+
| NAME | ENGINE | VERSION | EXTENT_SIZE | DEFAULT_LOGFILE_GROUP |
+------+--------+---------+-------------+-----------------------+
| ts1  | NDB    |       1 |     1048576 |                     0 |
| ts2  | NDB    |       1 |     1048576 |                     0 |
+------+--------+---------+-------------+-----------------------+
2 rows in set (0.00 sec)

mysql> ALTER TABLESPACE ts1 ADD DATAFILE 'datafile3.dat' 
INITIAL_SIZE=12M ENGINE NDB;
Query OK, 0 rows affected (1.85 sec)

mysql> select * from INFORMATION_SCHEMA.DATAFILES;  select *
 from INFORMATION_SCHEMA.TABLESPACES;
+---------------+--------+---------------+----------+------+------------+
| NAME          | ENGINE | PATH          | SIZE     | FREE | TABLESPACE |
+---------------+--------+---------------+----------+------+------------+
| datafile2.dat | NDB    | datafile2.dat | 12582912 |   11 |            |
| datafile3.dat | NDB    | datafile3.dat | 12582912 |   11 |            |
| datafile.dat  | NDB    | datafile.dat  | 12582912 |    9 |            |
+---------------+--------+---------------+----------+------+------------+
3 rows in set (0.02 sec)

+------+--------+---------+-------------+-----------------------+
| NAME | ENGINE | VERSION | EXTENT_SIZE | DEFAULT_LOGFILE_GROUP |
+------+--------+---------+-------------+-----------------------+
| ts1  | NDB    |       1 |     1048576 |                     0 |
| ts2  | NDB    |       1 |     1048576 |                     0 |
+------+--------+---------+-------------+-----------------------+
2 rows in set (0.00 sec)

the ‘free’ column is really the number of free extents. Not exactly ideal… maybe… but since that’s the unit of allocation in the data files, it sort of makes sense. The other option is to list number of extents * extent size. Maybe that’s clearer for people… there is the option of denormalising the tables and have extent size in the DATAFILES table too. There is something in my brain that makes that a hard leap though.

Although…. if you’re going to be querying the tables directly and not just using a pretty gui on top of it all, you should probably know what you’re doing anyway.

Although, both a great benefit (and curse) of commoditising the database market is the fact that you get all sorts as users. This is interesting in cluster as it is naturally a bit more complex than a simple client-server RDBMS.

we also need a NODE column as well. which will probably cause confusion for non-cluster users and the like :)

(for the unintiated, this is work being done in a branch off the 5.1 tree for NDB disk data. we’ll push it to the main 5.1 tree at some point). don’t go thinking this is production ready any time soon (in other words insert a standard disclaimer).

I’m getting responses of people wanting to come to the next meeting. This is all good. Looks like we’ll have more people than last time (which is good). So growing it is.

Considering that a lot of people got information on the last one less than a week before the event, and this time it’s about two weeks – I feel good about it.

Full details at: http://mysql.meetup.com/93/

(insert disclaimer about this being my own views – no that of MySQL AB)

Slashdot | MySQL and SCO Join Forces

Some people seem to think that porting your application to a newer version of an OS, having a trial version of your subscribtion-based support shipping with every copy of that OS and access through that OS vendors reseller channel is a bad thing.

Granted, a lot of people think that certain actions of said OS vendor are just plain retarded. Myself included – it would be much better if they actually focused on products. That being said, there’s more than one OS vendor that does just plain dumb stuff – or, to use the more emotive “evil” word.

Of course, there’s part of the /. crowd that seem to think we must be evil for porting to a SCO platform – but by their silence (and sometimes “screw you guys, I’m going to X RDBMS”) it must be okay for others to do it (note that X RDBMS already supports SCO platforms)?

Besides, anybody who’s really used MySQL will know how easy it is to move your database from one platform to another – really empowering you to make sure you OS vendor gives you the best deal possible – because you can easily move to where the grass is greener.