I have a MySQL-Server 5.5 with around 5.000.000 records in each table.
Now i want to activate the variable "innodb_file_per_table = 1".
Is this possible?
Is there any risk to do that?
The Reason is for activating the option, is to optimize performance.
Thanks and Regards
Chris
innodb_file_per_table is a dynamic variable -- changing it can safely be done without even restarting the server... but the big caveat is that you can never reclaim the disk space consumed by the ibdata file.
Tables that are rebuilt with the setting enabled will have their own tablespace files, but ibdata1 cannot be shrunk without a dump, followed by removal of ibdata1 and reinitialization of the server, and then a reload of all the data.
"Performance" is not necessarily a valid reason to change the setting on a working server.
It is possible. All advantages and possible disadvantages are mentioned in official docs
Also you should be aware that only new tables will be created in separated tablespace or you can rebuild any existing table to moved from shared tablespace.
Related
Say my website takes in lots of data from its users, and it goes to MySQL on my computer, but my computer runs out of space. If I connect a hard drive to my server computer, can I make it so I can put a new database on that hard drive, and all the data gets stored there? It would obviously be attached at all times.
This probably belongs on https://dba.stackexchange.com/ instead, and indeed there's quite a bit of in-depth discussion there about some of the techniques you could use.
One thing I've found helpful when working with large but temporary datasets is to enable innodb_file_per_table which — in my case — helps reclaim disk space when removing these temporary databases.
Moving the entire datadir
You can move the entire directory that MySQL uses to store files; this is called the datadir. Stop the MySQL daemon, move the folder, edit my.cnf to refer datadir = to the new folder location, and start the daemon.
File-per-table tablespace outside of the datadir
https://dev.mysql.com/doc/refman/5.6/en/tablespace-placing.html
You can use the file-per-table tablespace configuration (innodb_file_per_table in the [mysqld] portion of the configuration file) in conjunction with CREATE TABLE to actually place a tablespace outside the datadir. When you have innodb_file_per_table enabled, you can use statements like CREATE TABLE t1 (c1 INT PRIMARY KEY) DATA DIRECTORY = '/alternative/directory'; to put the datadir for that tablespace in a different directory.
Partitioning
Using partitioning, you can break up the databases, tables, and columns in to different storage partitions. This is probably not what you're looking for in this case because they still reside in the datadir. https://dev.mysql.com/doc/refman/5.7/en/partitioning.html
You can export the database via PhpMyAdmin and the pass the saved database file onto another computer.
Exporting the database:
https://serverpilot.io/community/articles/how-to-export-a-database-using-phpmyadmin.html
Importing the database:
https://serverpilot.io/community/articles/how-to-import-a-database-using-phpmyadmin.html
I have a script that needs to add data to a folder created in the mysql data folder and then in some way force the mysql server to reload the data so the database reliably shows up. I am currently using a system call to the /etc/init.d/mysql script to restart the server but this is quite slow, I couldn't find anyhting in mysql that would reload the database through a query of some kind.. I was just wondering if there was a way to do this that was slightly quicker?
This depends on the storage engine you're using.
MyISAM tables will be reloaded automatically as soon as the table is next touched by MySQL (obviously, you need to make sure the .MYI, .MYD and .frm files are consistent).
InnoDB is a bit more complex, and depends on whether it's a traditional configuration with all tables in the same tablespace, or if you're using innodb_file_per_table. With the former, you pretty much have to restart the server. With file-per-table, you can copy individual .ibd files, but then you have to use an ALTER TABLE statement to import that tablespace.
See here for information on working with individual .ibd files without restarting the server.
This page is also useful for seeing how to move InnoDB data from place to place.
What do you mean by 'quite slow'?
You could do a dump/load of the new db in a one named orginal_db_name_temp, rename the original DB, and then rename orginal_db_name_temp to orginal_db_name - then you will have your new DB in place.
However, I don't know which method is faster by your means - because a dump&load roundtrip will be probably slower than a file-copy. But renaming the DBs will probably be faster than restarting the server
Want to copy some big tables which are used very often from main server to local server in production mode ofc.
Is it safe?
Some suggestions, tools are welcome. :)
I'm guessing from asking about MYI tables that all of your tables are MyISAM tables and not InnoDb ones. Each MyISAM table is made up of three files: .frm, .MYD and .MYI they contain the structure, data and index respectively.
People advise against copying these raw files from running systems but I've found that as long as you're sure nothing's writing to the tables then copying them works fine (I've done this more times than I care to remember).
If you're doing this on a replica then just stop replication on the slave before copying. If it's just a single server or the master I'd recommend running FLUSH TABLES WITH READ LOCK before you start copying files, this will prevent any process from writing to the tables. When you're done release the lock with UNLOCK TABLES.
I would always recommend doing a CHECK TABLE on the tables you've copied in this manner. I think this is what I've used in the past mysqlcheck --all-tables --fast --auto-repair
If you're using LVM on the server then taking an LVM snapshot could be another way of getting hold of a clean snapshot.
If you're going to be doing this regularly I'd recommend either using replication to keep the local server up to date or to setup a slave which you can use for taking backups (as it's not the main database there's no problem with you stopping it, dumping tables, etc)
Yes it's alright if you
Shut the mysql server down cleanly before you copy the files, or at least take a global read lock
Take the .frm .MYI and .MYD files at the same time.
Have identical my.cnf and run the same MySQL version on each system
So it's basically ok, but not necessarily a good idea.
If you have different versions of mysql (You can only generally move to a more recent version, not an older one), or are running with a significantly different my.cnf (i.e. any of the fulltext indexing parameters differ, and you have fulltext indexes), you may need to rebuild the table. Rebuilding the table can be done on the destination server with ALTER TABLE blah ENGINE=MyISAM; this might still be a bit faster than a mysqldump / restore.
I want to purge the ibdata1, ib_logfile0 and ib_logfile1 files in MySQL. Because these files are taking too much space of my C:\ disk. And I don't want to move these files anywhere else in the Hard disk. I heard about purging which can shrink the data. I am using Windows Vista. What are the steps to be done to purge the data ?
The log files can be removed anytime. Only the most recent log is kept open/locked. However, deleting id_data will trash all of your InnoDB databases - that's the actual data store.
As pointed out by MarcB, you can delete the (old) logfiles without problems; MySQL does not need them to run.
The data file ibdata* must not be deleted, it contains the actual database data.
I will grow as the database grows; unfortunately there is not way to shrink it, even if you later delete data from the database. The only way is to dump and reimport the whole database.
Also see this question: MySQL data file won't shrink
It explains various options to better cope with growing data files.
Short answer: There's no way to reduce the size of the ibdata files once they grew to a certain size. MySQL recommends dumping all innodb type data, shutting down mysql, deleting the ibdata files and restarting, then loading the data again. A one-click "compact" solution like other systems have is still missing.
The short question:
Is it safe skip ib_logfile* files while creating custom-made backup of MySQL installation with InnoDB engine used?
Custom-made backup is just copy all (or subset of) /var/lib/mysql + /etc/my.cnf to safe place.
As I know ib_logfile* files are recreated by MySQL on start + the files are really huge, so that may not be wise to store them in backup. And yes, assume MySQL is (correctly) stopped before backup.
It's not safe to back up a database in the manner you're describing.
The reason is that you cannot know if some data pages are still in MySQL Server's memory, pending an I/O flush to disk. So copying the files has a good chance of copying garbage, whether or not you include the ib_log files.
Don't do what you're doing. Use mysqlbackup or InnoDB's Hot Backup product.
edit:
Read Farhan Mashraqi's blog article about InnoDB Performance Optimization, in which he says you can delete the ib_log files if you have shut down MySQL Server.
InnoDB log resizing: is not as simple
as changing option and restarting. You
need to shut down MySQL server and
make sure it shuts down normally
(check error log for errors to
confirm). Then move away InnoDB log
files ib_log*. Then start the MySQL
server and check error log files to
see if it successfully created new log
files.
So yes, you should be able to do a filesystem copy of the ibdata files only. You don't need to include the ib_log files, because they should be recreated as MySQL Server starts up. I reiterate, however, that I do not recommend backing up databases with filesystem copy.
Suppose you back up a database today in this manner, using MySQL 5.0. Someday later you need to restore the backup, but by that time you'll be using some future version like MySQL 6.5 for example. Do the ib_data files still use the same internal format in that future version? Will MySQL 6.5 read those files you backed up today? You can't be sure. The backup format is intended to be more portable.