I am happy to announce the availability of beta release of our new product Percona XtraDB Cluster. Percona XtraDB Cluster is High Availability and Scalability solution for MySQL Users and the beta release is based on Percona Server 5.5.20 and the recently released Galera 2.0 GA The main focus in this release: Incremental State Transfer, […]
Search Results for: auto inc scalability
I am happy to announce the availability of alpha release of our new product Percona XtraDB Cluster. Percona XtraDB Cluster is High Availability and Scalability solution for MySQL Users and based on Percona Server 5.5.17 Percona XtraDB Cluster provides: Synchronous replication. Transaction either commited on all nodes or none. Multi-master replication. You can write to […]
As we can see, MySQL 5.5.8 comes with great improvements and scalability fixes. Adding up allÂ the new features, you haveÂ a great release. However, there is one area I want to touch on in this post. At Percona, weÂ consider itÂ important not only to have the best peak performance, butÂ also stable and predictable performance. I refer you […]
Upgrading MySQL Server is a very interesting task as you can approach it with so much different “depth”. For some this is 15 minutes job for others it is many month projects. Why is that ? Performing MySQL upgrade two things should normally worry you. It is Regressions – functionality regressions when what you’ve been […]
First time I heard about Galera on Percona Performance Conference 2009, Seppo Jaakola was presenting “Galera: Multi-Master Synchronous MySQL Replication Clusters”. It was impressed as I personally always wanted it for InnoDB, but we had it in plans at the bottom of the list, as this is very hard to implement properly. The idea by […]
Note: This blog post is part 1 of 4 on building our training workshop.
The Percona training workshop will not cover sharding. If you follow our blog, you’ll notice we don’t talk much about the subject; in some cases it makes sense, but in many we’ve seen that it causes architectures to be prematurely complicated.
So let me state it: You don’t want to shard.
Optimize everything else first, and then if performance still isn’t good enough, it’s time to take a very bitter medicine. The reason you need to shard basically comes down to one of these two reasons
One of our customers gave me a chance to run some benchmarks on 24-core (intel cpu based) server, and I could not miss it and ran few CPU-bound tasks there. The goal of benchmarks was investigation of InnoDB-plugin and XtraDB scalability in CPU-bound load.
Our customers or prospective customers often ask us how we do a performance audit (it’s our most popular service). I thought I should write a blog post that will both answer their question, so I can just reply “read all about it at this URL” and share our methodology with readers a little bit. This […]
I now got answers to the second portions of the questions you asked Heikki. If you have not seen the first part it can be found here. Same as during last time I will provide my comments for some of the answers under PZ and will use HT for original Heikkis answer. Q26: You also […]
Suppose you want to remove auto_increment from 100G table. No matter if it’s InnoDB or MyISAM, you’d usually ALTER TABLE huge_table CHANGE id id int(6) NOT NULL and then wait hours for table rebuild to complete. If you’re unlucky i.e. you have a lot of indexes and not too much RAM – you could end […]