Comments on: MySQL Schema Synchronization and GUI Tools

By: Diamond Notes » MySQL Schema Synchronization and GUI Tools

Diamond Notes » MySQL Schema Synchronization and GUI Tools — Fri, 31 Oct 2008 17:53:21 +0000

[...] SELECT CONCAT(“mysql -u root -pPASS “, TABLE_SCHEMA, ” -e ‘ALTER TABLE “, TABLE_NAME, ” ENGINE=MYISAM;’ & “) FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE=’INNODB’; Again, the output can be put in a batch file, modified a little, and run in parallel. Once everything was converted to MyISAM, I shut down the database and removed the InnoDB log and data files and modified the my.cnf to so I had file_per_table and a much smaller InnoDB data file. That was the fairly straightforward part. Now the fun began. (moreâ€¦) [...]

By: Keith Murphy

Keith Murphy — Mon, 27 Oct 2008 21:49:51 +0000

Tom,

The OSS version does the reverse engineering also.

By: Sheeri Cabral

Sheeri Cabral — Thu, 23 Oct 2008 13:30:41 +0000

Arjen — that’s what we tried first, but unfortunately if the table is referenced as a foreign key in another table, you can’t convert it to MyISAM:

http://bugs.mysql.com/bug.php?id=12555

That is, if tbl1 references tbl2, you can’t convert tbl2 to MyISAM. You can alter tbl1 first, and then tbl2.

Andrii — it works just fine, however the problems is that you then still have the large ibdata files — which are now wasted, because most of the 352G in the ibdata files are now fragmented space, which cannot be recovered.

By: andrii

andrii — Wed, 22 Oct 2008 11:26:56 +0000

Hey, why convert to MyISAM? Just ALTER … ENGINE=InnoDB works fine when innodb_file_per_table changed.

By: Tom Krouper

Tom Krouper — Wed, 22 Oct 2008 02:11:34 +0000

Very cool information. I’ll have to check out SQLyog and give workbench another look-see. Do you know if it works on the OSS version or just on SE?

Interesting side note that I had not heard before today. (We had a MySQL consultant on hand today.) He said that once you get over 200 tables, innodb_file_per_table is a bad plan due to all of the files that need to be opened. I hadn’t heard that before. I haven’t done any benchmarks but since we are using innodb_file_per_table I probably will be. If it is true, you might want to switch back to the old way. At least you’ll have the tools to help you.

Cheers,
Tom

By: Arjen Lentz

Arjen Lentz — Wed, 22 Oct 2008 01:58:26 +0000

For alter tables in/to MyISAM, you want a very big myisam_sort_buffer_size
Dropping all the foreign keys beforehand shouldn’t be necessary, the’d be dropped in the ALTER TABLE. Saves one whole table copy operation per table ;-)

I’ve got some customers with a bigger ibdata1…. it’s not a problem often, but it can become unmanagable, obviously. So you can add one more separate data file for future growth of existing tables, and enable innodb-file-per-table for any new tables.
A complete dump/reload is not always an option… requires downtime and people don’t always have a neat master/slave setup that can be flipped – which would be ideal for this.

By: Rob Wultsch

Rob Wultsch — Tue, 21 Oct 2008 22:32:18 +0000

“The FOREIGN KEY and REFERENCES clauses are supported by the InnoDB storage engine, which implements ADD [CONSTRAINT [symbol]] FOREIGN KEY (…) REFERENCES … (…). See Section 13.2.6.4, â€œFOREIGN KEY Constraintsâ€. For other storage engines, the clauses are parsed but ignored. The CHECK clause is parsed but ignored by all storage engines. See Section 12.1.9, â€œCREATE TABLE Syntaxâ€. The reason for accepting but ignoring syntax clauses is for compatibility, to make it easier to port code from other SQL servers, and to run applications that create tables with references.”
http://dev.mysql.com/doc/refman/5.0/en/alter-table.html