Hi! I'm in the same position as Steve: Considering switching from MyISAM to InnoDB because of the row-level locking capabilities. My application has quite a lot of updates/inserts mixed with selects, and is starting to suffer from the table-locking policy... And like Steve, I'm also scared! :) I've been working quite a lot with MyISAM-tables and I have a good feeling for how it works (backups, data-files, index-files, size of these files, etc) But with InnoDB, I'm - hmmm - confused - that's probably the best word to describe it! The "auto-extendible"-feature on the todo-list is a great thing! That's one of the big concerns I've had with InnoDB. Another concern is the actual file size - I understand that InnoDB-tables will use a lot more space than the same table in MyISAM... Question is HOW much more (the largest table I currently have is ~2 Gb datafile, 360 Mb indexfile)
I'm also confused with how it all works with tablespaces, log-files etc. Is all this "common knowledge" with transactional databases? If I'm not interested in transactions, do I have to care about all that? And all these limits and parameters! To quote from the InnoDB-documentation: "Note that data files must be < 2G in some file systems! The combined size of data files must be >= 10 MB. The combined size of the log files must be < 4G. " Hmmm - does any of this put any limitation for my application? (it's a retorical question - I know it depends on my app, but you get the point: It's a lot of new things to learn and consider before switching) And what about backups? Now I'm using mysqldump every night to backup my database - will that be ok for InnoDB too? (I know that it _works_ but what about performance - will it take longer to make a dump with InnoDB-tables? I have to take the website offline while dumping so it's important) I have been looking forward to online-backups, and it is on the todo-list for MySQL 4.1 - will that feature work with InnoDB-tables as well? I noticed that hotbackups is also on the todo-list for InnoDB, but that it will not be free... So... As you can see I'm a bit confused, and I think a lot of people are! It seems to be a whole lot more to learn, more administration, tweaking, etc with InnoDB than with MyISAM. Maybe I'm wrong, but I get that feeling from reading the InnoDB-docs... Maybe some of this confusion and fear could be avoided with a section in the InnoDB documentation that describes InnoDB from a "MyISAM-point-of-view" :) Explaining how all common things, principles and routines with MyISAM works with InnoDB. I'm sure a lot of people have very good knowledge of MyISAM and comes from the same direction as I do... Thanks for your time! :) /Tobias Steve, I added an item to the TODO list at http://www.innodb.com/todo.html ...... May, 2002: Make a data file auto-extendible. You can specify the last data file in innodb_data_file_path like this: ibdata1:50Mautoextend It will create a data file whose initial size is 50 MB, and InnoDB will automatically extend it in units of 10 MB when the data file becomes full. ...... Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ Speed up adding of features to MySQL/InnoDB through support contracts See http://www.innodb.com for the online manual and latest news on InnoDB -----Original Message----- From: Steve Rapaport <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Date: Sunday, March 03, 2002 12:18 AM Subject: InnoDB frightens me... >I'm seriously considering switching to mysql-max so I can make my >session handling table an Innodb type. Currently the mysql locking policy >allows big traffic jams when several sessions are active simultaneously, >and it's the only table that has frequent updates. I need row-locks! > >BUT, and it's a big but, > >I just read through the InnoDB manual pages in the mysql site, and >it seems I can't have row-locking without a lot of programming >and worse, admin overhead. And scary a-priori decisions. > >At first glance (correct me) I need to >1. Check through all my programs handling this table to >add AUTOCOMMIT or Commit/Rollback as appropriate. > >2. Decide with zero experience on a lot of maximum sizes which will not be >adjustable in future, including dataspace. > >3. If I run up against one of those limits in future I am guaranteed >a nightmare of table copying, deleting, restoring, and woe if I >happen to get a "runaway rollback". I am also required to back >up my database table and all its update logs in case of this situation, >although my chances of restoring them successfully look dim. > >I am sufficiently frightened to just accept table-lock traffic jams instead. >Can anyone tell me how I can use row-locking without getting into >this frightening world? > >Best, >Steve > >--------------------------------------------------------------------- >Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > >To request this thread, e-mail <[EMAIL PROTECTED]> >To unsubscribe, e-mail <[EMAIL PROTECTED]> >Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
