How do I get hibernate to use InnoDB instead of MyISAM when creating my tables? The suggestions at Hibernate: Create Mysql InnoDB tables instead of MyISAM are not working for me.
I am using Glassfish 3.1.2 and MySql 5. Also I have MySQL installed through XAMPP on Mac OSX Lion.
After much research, I learned that setting the database default to InnoDB is not good practice. A great number of reasons is given, such as InnoDB is expensive. In light of all the reasonings, I concluded that clearly if making InnoDB default was best practice then it's likely the database would come configured as such. So I kept looking for a different solution.
Anyway, the solution was this:
Go to glassfish and add the following properties to the JDBC connection pool in question.
Name: SessionVariables
Value: storage_engine=InnoDB.
This works for me like a charm.
If someone has a better solution, I would really love to hear it.
Related
System Type: 64-bit
Windows Edition: Windows Server 2008 R2 Enterprise
Microsoft Windows Server: 6.1
MySQL Workbench Version: 6.3
I manage a multi-site WordPress and it has grown to 33,000 tables so it's getting really slow. So I'm trying to optimize our installation. I've been working on a DEV server and end up deleting the whole site. Assuming that copying the live server is not an option at this point (and please trust me that it isn't) can you please help me with the following:
I highlighted and copied tables from the live server to paste them into the DEV server folder. Workbench recognizes the table in the Schemas area but when I write a SELECT query, for an Innodb tables, it says that they don't exist. The MyISAM tables, however, run successfully.
I'm just confused because I know the tables are in the right folder but for some reason they don't query. I saw a solution that says to create the tables with a regular query and then overwrite them in the folder but this isn't realistic for me because there are 33,000 tables. Do any of you have some ideas as to how I can get these Innodb tables working again?
You cannot copy individual InnoDB tables via the file system.
You can use "transportable tablespaces" to do such. See the documentation for the MySQL version you are using. (This is not the same version as for Workbench.)
It is not wise to do the above, but it is possible. Instead, you should use some dump/load mechanism, such as mysqldump or xtrabackup.
WordPress has the design flaw of letting you get to 33,000 tables. This puts a performance strain on the OS because of all the files involved.
In moving to InnoDB, I recommend you carefully thing through the choices of innodb_file_per_table. The thoughts involve which MySQL you are using, how big the tables are, and whether you will be using "transportable tablespaces".
I do have one strong recommendation for changing indexes in WP: See slide 63 of http://mysql.rjweb.org/slides/cook.pdf . It will improve performance on many of the queries.
Hey, so I have recently become aware that in order to do foreign key relationships, I need to convert my tables over to innodb. I was wanting to do this in phpmyadmin and found the option for 'storage engine (type)' However my dropdown of options is limited to: MyISAM, MEMORY, and MRG_MYISAM
Would anyone be able to explain why this is?
apache 2.0
phpmyadmin 3.3.10
mysql 5.0.67
php 5.2.2
Thanks!
InnoDB support has to be enabled on the instance of MySQL you're using.
Try issuing a SHOW ENGINES SQL command to see what's available.
As most of you know, Sun acquired MySQL (and later Oracle acquired Sun), and during these acquisitions, there were a lot of FUD in MySQL community which resulted in creation of various forks.
Today we have MySQL from MySQL, Percona (XtraDB) MySQL, OurDelta MySQL, MariaDB, Drizzle to name a few. Which brings us to the source of the problem.
We are in the process of upgrading our databases (hardware/software) and I would like to know which one of the forks should I go with. Each has their own set of pros/cons. We are currently using MySQL 5.0.x from MySQL/Linux on an 8-core machine. Our new hardware is a monster with 32 cores and 32GB of memory connecting to a fast NetApp Storage via FC.
I would like to stick with MySQL from MySQL but I have heard horror stories on how badly MySQL 5.1 performs on many cores. I have also heard that MySQL 5.4 performs better on multi-core machines but that's still not production ready. In addition, I have also heard a lot of good things about Percona builds.
This is what I know so far:
MySQL 5.1 from MySQL: Reliable choice, but doesn't scale well on a big machine
Percona: Scales well, good backing company. I don't have much experience with it
MariaDB: Don't know much about it besides that it was founded by Original MySQL developers (including Monty)
OurDelta: Don't know much
Drizzle: Mostly optimized for cloud computing
I would like to know what's the general notion about this problem. Which build/version should I go with? How are you guys picking your builds/versions?
Thanks!
All of the 'forks' you mentioned (except Drizzle) re-base off newer official releases of MySQL. I think that the word fork can lead you down the wrong path - since the intention is just to provide after market modifications. I wrote about this here:
http://mtocker.livejournal.com/50931.html
Since they re-base of MySQL, and MySQL 5.0 is in "extended maintenance", only major vulnerabilities are to be fixed. This means you want to be moving to 5.1. If we work with this assumption, then it cuts OurDelta out from your decisions - since they are just the 5.1 MariaDB build/packaging partners.
I think you can also rule out Drizzle, since it is currently pre-beta. They're planning a beta by the end of the summer - but it's still much earlier than what you'll want. I really don't think you use a database not ready for production, so this rules out MySQL 5.5 as well.
So this leaves Percona Server, Official MySQL 5.1 and MariaDB. It's true that 5.1 has some poor scalability with many cores, but if you enable the InnoDB plugin it is better.
The rest of my response from here on in is biased - I work for Percona:
Percona XtraDB has additional CPU scalability fixes than MySQL 5.1+InnoDB plugin. The ones that are going to matter are covered here:
http://www.percona.com/docs/wiki/percona-xtradb:features:start
One I can comment on in particular that will matter is this one:
http://www.percona.com/docs/wiki/percona-xtradb:patch:innodb_split_buf_pool_mutex
Personally, I think that everyone who needs to set up a new MySQL installation today should be using MariaDB. MariaDB is based on the latest MySQL 5.1, actively maintained (including fixes for bugs reported against MySQL) and packages Percona XtraDB / InnoDB plugin.
I don't even know if "fork" accurately describes Maria, since they are committed to keeping up with current releases of MySQL.
In short: MariaDB 5.1 = MySQL 5.1 + Percona XtraDB + additional useful patches + active development and maintenance
Update late 2011- May 2012: I switched from MariaDB to Percona Server to get to MySQL 5.5 but I intend on switching back once the Maria team has a stable 5.5 based release. I think that everyone who needs to set up a new MySQL installation today should be running Percona Server. If you are using SSDs, you *must* run Percona Server.
2013-2018: Happily ran Percona server 5.6 this whole time.
2018: upgraded to Percona server 5.7 and then almost immediately to MySQL 8.0. [ At this point, I am not knowledgable enough to talk about the differences between MySQL 8, Percona Server 5.7 and MariaDB 10 and I can't say why you might want to choose one over the others ]
Use MariaDB. They've just released a version lately. Maria engine is also much better than MyISAM. With opensource project, you go where the founder go.
Just an update on this. We chose to go with Percona and we can't be happier. Percona guys definitely know their stuff and keep up with the new technologies. Just checkout http://www.mysqlperformanceblog.com/ Top notch software plus top notch people and great support, you can't go wrong.
I think it's still too early to write off MySQL entirely. I'm not enthusiastic about Sun/Oracle gaining the reins, but I don't have a clear idea what direction they'll take with it. Regardless, I'd wait another year before seriously thinking of switching to a fork. Time will tell which project has the resources and motivation to survive, or if a fork is even necessary.
Google has a memory library patch out that supposedly improves performance on multi-thread / core mysql installations. Supposedly, the performance bottleneck was in the memory allocation routines, and would manifest itself starting at 4 cores. I'm currently running a dual proc box with 4 cores each, and am having no problems with 5.1.x without the memory library patch.
My biggest suggestion to you would be to install 5.4 and run a benchmark suite against it. If it does the job, go with it. The fragmentation of the various forks does suck, but maybe it will be for the best. At least the founders have money now to fund their own direction... I wouldn't take the advice to follow them blindly though... It took a lot of time and efffort to set up the mysql infrastructure initially, and while it wouldn't hurt to support the team that did it the first time, there is no guarantee they will succeed the second time. So... support them, but don't rely on them until you know you can rely on them.
If you're upgrading your databases anyway, you should consider other FOSS DBMSes, or data management software systems as well, not just MySQL.
For example, if your DB workload is analytics more than transactions, and data is mostly added in batches, you should consider using MonetDB, a columnar DBMSes which is about 1.5-2 orders of magnitude faster than MySQL when doing analytics-only.
Another option is PostgreSQL. It's more transaction-oriented - like MySQL; in fact, they're similar enough to be proper competitors. There are arguments for preferring PostgreSQL and arguments for preferring a MySQL variant.
On DB-engines.com you can find other potentially-relevant DBMSes, FOSS and closed-source/commercial.
I just went to look over one my site's databases and noticed that all of the tables had been converted to MyISAM (they used to be InnoDB).
What's more is that InnoDB seems to missing, along with BerkeleyDB, Federated, and others.
A few months ago I upgraded from MySql 5.0 to 5.1.38. I can't imagine that I wouldn't have noticed if InnoDB was not installed after the upgrade, but maybe it's been that way since the upgrade. Having several 10 GB tables automatically convert themselves to MyISAM without hearing about any downtime seems very unlikely to me.
Regardless, the mysql system variable have_innodb is set to NO. Can I simply change that to YES or does that mean InnoDB is missing from the install?
Maybe InnoDB parameters were changed during upgrade? This advice from MySQL Forums helped me in a similar situation: http://forums.mysql.com/read.php?22,397052,408970
In short: Stop the MySQL daemon, delete ib_logfile* from datadir, restart MySQL.
If the field in SHOW ENGINES is "no" it means it's not compiled in. You would have to either compile the server again, compile the innodb plugin and load it or fetch server binaries which have it enabled.
You can't simply set the mysql system variable to YES to convert the table from MyISAM to InnoDB.
ALTER TABLE t1 ENGINE=InnoDB;
When InnoDB support is turned off even is you use ENGINE=InnoDB in your create table statements, the table will use the default storage engine for MySQL which is normally MyISAM.
It could also be the case that the innodb logfile[01] are corrupted. In which case the engine will show as disabled and the tables as ISAM. The log will mention it.
Is there any product that make mysql master/slave failover process easier? something that can happen automatically, rather than manually fix it.
[... a bit later ... ;)
What are you calling "easier" ?
There is pretty much solutions with MySQL :
MySQL Cluster, with NDB Engine (High availability solution but some limitations : no foreign keys)
MySQL Master / Slave with their own replication system
MySQL replicated via DRBD and heartbeat.
There is a lot of material on this subject :
Failover support for a DB and even more here : Scaling solutions for MySQL (Replication, Clustering)
MySQL cluster in an out of the box solution, but replication is not very difficult to set up.
Regards.
The actual failover bit can be managed with heartbeat (part of the Linux HA project; http://linux-ha.org/), and I'm told that there's some tools in the MySQL Enterprise grab bag that helps with managing replication, although I've never used it myself.