This is an General Availability release. We did our best to eliminate bugs and problems during alpha and beta testing release, but this is a software, so bugs are expected. If you encounter them, please report to our bug tracking system.

Related

Author

Vadim Tkachenko co-founded Percona in 2006 and serves as its Chief Technology Officer. Vadim leads Percona Labs, which focuses on technology research and performance evaluations of Percona’s and third-party products. Percona Labs designs no-gimmick tests of hardware, filesystems, storage engines, and databases that surpass the standard performance and functionality scenario benchmarks.Vadim’s expertise in LAMP performance and multi-threaded programming help optimize MySQL and InnoDB internals to take full advantage of modern hardware. Oracle Corporation and its predecessors have incorporated Vadim’s source code patches into the mainstream MySQL and InnoDB products.He also co-authored the book High Performance MySQL: Optimization, Backups, and Replication 3rd Edition.

Per the release notes, there are some LOAD DATA related limitations. It says “huge” LOAD DATA will be rejected. What is considered “huge”? We do quite a lot with LOAD DATA in our system, and sometimes the files can be a couple GB in size.

XtraDB Cluster is integration of Percona Server and Galera library. Both Percona Server and Galera are in GA state, so the main focus of testing was on proper integration and packaging. Galera was in in my focus since 2009, so this is really 3 years of testing and evaluations for me. At this point I believe it has good quality.

We used following tools for evaluations: randgen (lp:randgen), kewpie (lp:kewpie) and for stressing and performance: sysbench and tpcc-mysql.

I was told that LOAD DATA works differently now. Quote from Seppo: “LOAD DATA INFILE processing will commit every 10K rows. So large transactions due to LOAD DATA will be split to series of small transactions”.

Nice work! I’m excited about the future of Percona Xtradb Cluster as it becomes more mature. I’m curious about Percona Xtradb Cluster from the perspective of running across multiple AWS regions, for example having 2 masters in the US Eastern region and 1 in the US Western region. As I understand it, due to the synchronous replication all writes would be affected by the network latency between these regions. Is Percona Xtradb Cluster not designed or not ideal for this type of setup?

Vadim, I second Luke’s request. It would be extremely helpful for many of us to get your recommendations on how to best deploy Xtradb Cluster in AWS environment. It would also be great to get some idea on what throughput increase we can expect considering EC2 and EBS constraints. Our company is working on adding NoSQL (AWS DynamoDB) and AWS EMR components to the setup which is now exclusively based on Percona’s MySQL server. The more we can extract from MySQL without relegating to the extremely limiting NoSQL setup, the simpler our applications will be.

I use percona server 5.5.20, I would be testing xtradb cluster with three nodes. I went through your documentation provided with the release, and noticed the configuration, but i did not understand where did all of the configuration go for example default_storage_engine, query_cache_size, e.t.c…. Is it something built in or we just don’t need to define it for the cluster. I am new in this field and being a startup company cannot afford to get paid support from percona, but at-least you can answer this one or provide a link to sample configuration. Your tool do not provide config for xtradb cluster.

Can you clarify DDL handling issues? The documentation only says “DDL statements are problematic and may stall cluster. Later, the support of DDL will be improved, but will always require special treatment.” Our current implementation has 1,500 databases with 53,000 tables, so table add, drop, and modify actions happen rather frequently.