Re: Partitioning to use multiple disks

[Zardosht Kasheff]

Hello Albert,

Unfortunately, this is not supported. All TokuDB files must be and are placed in one directory.

I have not heard of these options before. What build are you running?

-Zardosht

On Thursday, April 25, 2013 12:38:28 PM UTC-4, Albert Strasheim wrote:

Hello

We have a good reason (promise) for wanting to use partitioning to place TokuDB tables on specific disks.

I tried something like:

CREATE TABLE ts (

    id INT, purchased DATE

)

DATA DIRECTORY = '/mnt/sdb/mysql/data'

INDEX DIRECTORY = '/mnt/sdb/mysql/idx'

ENGINE=TOKUDB;

but all the tables still seem to end up in /var/lib/mysql.

Is this supported for TokuDB tables? Is there a way to turn this on if it isn't on by default?

Thanks.

Regards

Albert

[MARK CALLAGHAN]

The MySQL way is to put database files in per-database (per-schema) directories. InnoDB & MyISAM do that. Are there plans to change TokuDB to do the same?

--
You received this message because you are subscribed to the Google Groups "tokudb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tokudb-user...@googlegroups.com.
To post to this group, send email to tokud...@googlegroups.com.
Visit this group at http://groups.google.com/group/tokudb-user?hl=en.
 
 

--
Mark Callaghan
mdca...@gmail.com

[Zardosht Kasheff]

I don't know what the roadmap is. We have several ideas for reworking how data is laid out on disk, and putting database files in per-database directories is one idea. Another idea in its early stages is to do away with associating files to tables/indexes, and instead have files partition the blocks of data based on their size. That is, one file will contain blocks that are only 1MB-1.1MB, another 1.1MB-1.2MB, etc...

[Tim Callaghan]

On our product roadmap is to move the files into their appropriate database folders, plus have them maintain a file name consistent with the table name.

On Monday, April 29, 2013 8:29:11 AM UTC-4, Shlomi Noach wrote:

Support request to have files in relevant directories per schema.

Also use of internal MySQL names for files is a poor choice, as need interpretation via INFORMATION_SCHEMA. This is very user unfriendly; both features together make for hard time figuring out what's going on, dimensions of tables; the datadir is littered.

My two cents

[Shlomi Noach]

Just as comment, this might actually be a bug that they are named after temporary MySQL decision, since MySQL will clean up such tables upon restart, whilst TokuDB will not. Therefore it is possible to get future name collision between TokuDB's tables and what MySQL assumes to be free names.

[Zardosht Kasheff]

Hello Shlomi,

I don't think we need to worry about a file name collision. The
filename of a TokuDB dictionary is a function of the table name, key
name, and LSN position in the recovery log. So even if MySQL creates
another temporary table with the same name, the position in the
recovery log will be different, thus avoiding collision.

-Zardosht