I do not think that the location matters rather it is a matter of personal preference, and the MySQL installer will automatically update the my.cnf file for you.
However I would rather go with D:\mysql as the installation directory because its lowercase, has no special characters (spaces, capital letters) and is not in the Program Files directory which you may need to clean out for a new install or upgrade.
You may also need to add the D:\mysql\bin directory to the PATH environment variable so that you can run the MySQL commands from any command prompt
((100G is not the same as 100M. typo was fixed))
The line you gave is what you do -- in my.cnf. (Double check the syntax.)
That configuration was very important 15 years ago -- when some operating systems could not create a file bigger than 2GB (or 4GB). Now is is just an artifact. Most people simply have autoextend
on the last entry and forget about it.
The config says, as you say, "fill up one before moving on to the next". The number (eg, "100M") is the pre-allocated size.
Why do you want this config? I am curious as to whether you have a use case for current machines.
It is usually better to have innodb_file_per_table=ON
. Each table that you subsequently CREATE
or ALTER
is put into it's own "tablespace", which is identified by a file: <tablename>.ibd
. At that point, you don't need a huge, growing, set of ibdata*
files. (Leave autoextend
on the last one, just in case.)
Limitations... There is no way to have that config automatically add another ibdata* file name, only autoextend
the last one. Once created, you can't get rid of any of the files without dumping and reloading.
EDIT. "but we have many dynamically created tables per second" -- Ouch! How many tables do you have? How tiny are they? In general, thousands of tables is bad. Might it make sense to combine tables in some way? Would you care to elaborate on the design that 'needs' lots of tables?
Lots of tiny tables are better off in ibdata* (file_per_table = OFF). The OS overhead for more files is non-zero. (For big tables, the maintenance benefit of .ibd wins.) Regardless of the setting, there will be a .frm file per table.
Yes, lots of ibdata* files would let you migrate some to new drives. Use "symbolic links" (if unix) or the equivalent if Windows (Junctions?).
Best Answer
Disclaimer : Never Used
MySQL Enterprise Monitor
In reality, you do not need the first one as it has not been written in years. However, the default
datadir
for a MSI-installed mysql instance is"C:\Program Files\MySQL\MySQL Server 5.0\data"
. You should leave it alone in case you want to create another local instance of MySQL or use it as a template datadir for another local instance.As for the other two
ibdata1
files, one may be needed by MySQL Enterprise Monitor and the other for your actual data.To be sure, you need to check if you are running Multiple Instances of MySQL.
There are two methods
METHOD #1 Check via the Services List
If you see multiple MySQL services defined in
Services
, you have multiple MySQL instances running.METHOD #2 : Check via the Task Manager
Task Manager
Processes
Tabmysqld.exe
entries you seeIf you see multiple
mysqld.exe
entries in theTask Manager
, you have multiple MySQL instances running.NEXT STEP
Judging from the date and time of each ibdata1 file and their respective folders, my guess is that you have MySQL Enterprise running and it has its own MySQL instance. You need to check the MySQL Enterprise Documentation on moving Enterprise Monitoring Information to anther disk location.
As for
C:\MySQL Datafiles
, you need to locate themy.ini
being used. You should be able to have MySQL Enterprise Monitor tell you. In the event MySQL Enterprise Monitor does not any mechanisms for editing the datadir or migrating the MySQL data folder, you could also get it from theServices
entry:my.ini
Once you find the
my.ini
datadir
setting to new folder location on Drive E:\Migrate the Data from C: to E: with something like this:
Then startup MySQL. If the MySQL Enterprise Monitor cannot be used to start MySQL then do
net start mysql
.While you could move the whole folder
C:\Program Files\MySQL\Enterprise\Monitor\mysql\data
over to Drive E:\ withyou need to make sure MySQL Enterprise Monitor is full shut down. You also need to check for configuration settings for MySQL Enterprise Monitor to make sure it knows where its mysql data is located. Please don't move anything until you find this out. Consult either the Documentation or the Enterprise Forums on this aspect.
Sorry, I am not a user of MySQL Enterprise Monitor, but I hope I gave you a starting point.