Bug #41036 Easier Configuration Change On Cluster Disk Objects

• Submitted: 25 Nov 2008 22:23
• Reporter: Mikiya Okuno
• Status: Verified
• Category: MySQL Cluster: Disk Data
• Severity: S4 (Feature request)
• Version: mysql-5.1-telco-7.0
• OS: Any
• CPU Architecture: Any

[25 Nov 2008 22:23] Mikiya Okuno

Description:
Currently, we create disk objects on the cluster using SQL syntax from mysql CLI like following:

mysql> CREATE LOGFILE GROUP lg_1
    -> ADD UNDOFILE 'undo_1.dat'
    -> INITIAL_SIZE 16M
    -> UNDO_BUFFER_SIZE 2M
    -> ENGINE NDB;

mysql> ALTER LOGFILE GROUP lg_1
    -> ADD UNDOFILE 'undo_2.dat'
    -> INITIAL_SIZE 12M
    -> ENGINE NDB;

mysql> CREATE TABLESPACE ts_1
    -> ADD DATAFILE 'data_1.dat'
    -> USE LOGFILE GROUP lg_1
    -> INITIAL_SIZE 32M
    -> ENGINE NDB;

mysql> ALTER TABLESPACE ts_1
    -> ADD DATAFILE 'data_2.dat'
    -> INITIAL_SIZE 48M
    -> ENGINE NDB;

However, this method is not convenient in may case. Because...

o We cannot change the disk data object locations, size, number and so on without dropping/re-creating them.
o ndbd doesn't remove disk data objects on initial restart.
o Rolling restart cannot help reconfiguring disk data objects.

Instead of the above, if we can configure disk data objects using config.ini file, it will be very useful. If so, config.ini file content could be the following:

[UNDOLOG]
Name=lg1
File=undo_1.dat,16M
File=undo_2.dat,12M

[TABLESPACE]
Name=ts1
UndoLog=lg1
File=data_1.dat,32M
File=data_2.dat,48M

Alternative configuration style could be...
[NDBD DEFAULT]
LogfileGroup=lg1:undo_1.dat,16M:undo_2.dat,12M
TableSpace=ts1:undolog,lg1:data_1.dat,32M,data_2.dat,48M

This kind of configuration style which we can complete by editing only config.ini file is very intuitive, it's easy to understand, easy to review and easy to reconfigure, so it will ease our life.

The bad side effect of this way could be that it is necessary to do rolling restart when re-configuring the disk data objects. However, I don't think configuration changes happen often in production environment, so it could not be a problem. Reconfiguring=Rolling-Restart is a very natural way for cluster.

How to repeat:
n/a

Suggested fix:
n/a