The open-source xtrabackup tool from Percona brings much needed hot backup functionality to MySQL deployments.  In this database journal article we discuss logical, cold, and hot backups, then explain how to use xtrabackup on your MyISAM, InnoDB, and XtraDB tables to create at-the-ready backups.  We then take you through the step-by-step process to restore them, and even the process of point-in-time recovery too.

Database Journal – Hotbackups with Percona’s Xtrabackup

Percona Community,

Percona Server version 5.1.51-rel11.5 is now available for download.

The main purpose of this release is to update the current Percona stable release to the latest version of MySQL 5.1.

Functionality Added or Changed

•  Percona Server 5.1.51-rel11.5 is now based on MySQL 5.1.51.
•  New Features Added: None
•  Other Changes: None

Bugs Fixed

•  Bug #661354 - Fixed a problem compiling query_cache_with comments for 5.1.51-rel11.5. (Oleg Tsarev)
•  Bug #661844 - Fixed a problem with server variables failing test for 5.1.51-rel11.5. (Oleg Tsarev)

The Release Notes for this and previous releases can be found in our …

We've published our first case study. The customer, ideeli, had a database that was struggling on standard MySQL and InnoDB. The big win was the upgrade to XtraDB. The business continued to grow quickly, and months later under much more traffic, the database is still outperforming their previous version.

I thought I'd write a few notes that didn't seem appropriate to include in the case study, because this was a fun project that might be interesting to readers.

As usual, it was all about diagnosing the problem correctly. I used a variety of tools to help with this, foremost among them "stalk" and "collect" from Aspersa. There were several problems, not just one, and they required different techniques to diagnose. This can be hard when the …

Dear Community,

Percona Server version 5.1.50-rel12.1 RC is now available for download.

Functionality Added or Changed

• Percona Server 5.1.50-rel12.1 is now based on MySQL 5.1.50.
• New Features Added:
  • innodb_lru_dump_restore - Implemented automatic dumping of the buffer pool at specified intervals.
  • innodb_buffer_pool_shm - Implemented option ''innodb_buffer_pool_shm_checksum''; when enabled, shared memory buffer pool is checksum validated. This change also fixed these bugs: #643724, #649408, and #649393. (Yasufumi Kinoshita)
  • …

Vadim and I have just published a new technical white paper. It shows how Percona Server with XtraDB can make large-scale multi-tenant databases easier to build with MySQL. Our experiences working with SaaS and shared-hosting companies influenced the features we included in Percona Server and XtraDB, and I think this is the best explanation of what levers are available and how to use them.

Percona Server with XtraDB for Software-as-a-Service Application Databases is posted on the white-paper section of our website. No registration is required; it is just a PDF, freely downloadable with no marketing follow-up. Many thanks to Mark Callaghan and Dimitri Kravtchuk, who reviewed and gave valuable suggestions that made the white paper better.

…

Dear Community,

Percona Server version 5.1.50-rel11.4 is now available for download.

The changes in this release include:

New features

The primary purpose of this release is to update to the latest version of MySQL 5.1.

• Percona Server 5.1.50-rel11.4 is now based on MySQL 5.1.50.

Fixed bugs

• innodb_use_sys_stats_table – The SYS_STATS table is now used only for non-temporary tables.

The binary packages are available on our website.

Percona Server can be installed from either our  …

Dear Community,

Percona Server version 5.1.47-rel11.0 is available for download now.

The changes in this release include:

New features

• Percona Server is now based on MySQL 5.1.47, and XtraDB is now based on InnoDB plugin 1.0.8.
• XtraDB now uses the fast recovery code released in InnoDB Plugin version 1.0.8, instead of Percona's earlier fast-recovery code.
• Added the --percona_innodb_doublewrite_path option to place the double-write-buffer into its own file (issue #584299). The feature is sponsored by Large Social Network website.
• Added the --suppress_log_warning_1592 option to disable …

I just wrote a large post on reasons for innodb main tablespace excessive growth and I thought it would make sense to explain briefly of why it is so frequently you have purge not being the problem at all and when out of no where you can see purge thread being unable to keep up and undo table space explodes and performance drops down. Here is what happens.

When you have typical OLTP system with small transactions your UNDO space is small and it fits in buffer pool. In fact most of the changes do not need to go to the disk at all - the space for undo space is allocated, used and freed without ever needing to go to the disk.

Now when you have spike in writes or long running transactions which increases your undo space size it may be evicted from buffer pool and stored on disk. This is when problems often starts …

This is my last post in series on FlashCache testing when the cache is placed on Intel SSD card.

This time I am using tpcc-like workload with 1000 Warehouses ( that gives 100GB of data) on Dell PowerEdge R900 with 32GB of RAM, 22GB allocated for buffer pool and I put 70GB on FlashCache partition ( just to simply test the case when data does not fit into cache partition).

Please note in this configuration the benchmark is very write intensive, and it is not going be easy for FlashCache, as in background it has to write blocks to RAID anyway, and write rate in final place is limited by RAID. So all performance benefits will come from read hits

The full report and results are available on benchmark Wiki
http://www.percona.com/docs/wiki/benchmark:flashcache:tpcc:start.

Short version of …

In The Doom of Multiple Storage Engines, Peter talks about how the storage engine concept of MySQL is usually spoken of in positive terms, but there are many negatives.

I have a hard time trying to figure out the deeper meaning behind Peter’s post, given that Percona writes a storage engine for MySQL, XtraDB. Does this mean that Percona will stop developing XtraDB? Does this mean that the Percona Server will diverge farther and farther away from MySQL so that they’re not compatible any more and migrating from MySQL to Percona Server is very difficult?

Or maybe it’s just that Peter is saying one thing and doing the opposite; which just seems wrong because that would be blatant hypocrisy on Percona’s part.

(This idea was a comment on the blog post but seems to be trapped in the spam filter, so I’m …