For Percona Server,

• We worked on Solaris builds for the server.
• Peter proposed a feature for the server to enable more efficient incremental backups with XtraBackup.
• Peter, Vadim, and Nickolay continued investigating alternative methods of implementing flush in Percona Server. (I am involved, but not as deeply.) The task is complex and there are a great many scenarios to consider. For example, there is fast storage and slow storage, there is the case when the data is larger than the buffer pool and when the data is smaller than the buffer pool (which is actually worse in some ways), there is flush list flushing and LRU flushing, and on and on. We have been benchmarking various types of scenarios for modified neighbor flushing, for example, to investigate how the oldest LSN is advanced in different cases. We still have nothing conclusive, but we have learned some things that gave us ideas about how we could make the flushing algorithm self-tuning in more cases. We will keep you posted.

In XtraBackup news,

• Stewart Smith of the Drizzle project contributed a number of improvements to XtraBackup so that it can be a first-class backup tool for Drizzle. Thanks, Stewart!
• Continuing with the theme of community contributions, are also delighted that Lachlan Mulcahy is working on software to manage backups with XtraBackup. It is called XtraBackup Manager and is hosted on Google Code.
• We finished preparing XtraBackup to be used with Percona Server 5.5.
• We worked on Solaris builds for XtraBackup.
• We started from scratch and wrote documentation for innobackupex, removing mention of obsolete features and documenting command-line options that were not mentioned in the –help output previously. The docs will be available now with –help, via perldoc, as a man page, and on our documentation wiki.

In an unrelated note, we have a new home for the documentation of our InnoDB data recovery tools. The tools moved from Google Code to Launchpad a couple of years ago, but the documentation never got updated, and became stale and inaccurate. It is now hosted on our documentation wiki along with all of our other software documentation.

View full post on Planet Drizzle

For Percona Server,

• We worked on Solaris builds for the server.
• Peter proposed a feature for the server to enable more efficient incremental backups with XtraBackup.
• Peter, Vadim, and Nickolay continued investigating alternative methods of implementing flush in Percona Server. (I am involved, but not as deeply.) The task is complex and there are a great many scenarios to consider. For example, there is fast storage and slow storage, there is the case when the data is larger than the buffer pool and when the data is smaller than the buffer pool (which is actually worse in some ways), there is flush list flushing and LRU flushing, and on and on. We have been benchmarking various types of scenarios for modified neighbor flushing, for example, to investigate how the oldest LSN is advanced in different cases. We still have nothing conclusive, but we have learned some things that gave us ideas about how we could make the flushing algorithm self-tuning in more cases. We will keep you posted.

In XtraBackup news,

• Stewart Smith of the Drizzle project contributed a number of improvements to XtraBackup so that it can be a first-class backup tool for Drizzle. Thanks, Stewart!
• Continuing with the theme of community contributions, are also delighted that Lachlan Mulcahy is working on software to manage backups with XtraBackup. It is called XtraBackup Manager and is hosted on Google Code.
• We finished preparing XtraBackup to be used with Percona Server 5.5.
• We worked on Solaris builds for XtraBackup.
• We started from scratch and wrote documentation for innobackupex, removing mention of obsolete features and documenting command-line options that were not mentioned in the –help output previously. The docs will be available now with –help, via perldoc, as a man page, and on our documentation wiki.

In an unrelated note, we have a new home for the documentation of our InnoDB data recovery tools. The tools moved from Google Code to Launchpad a couple of years ago, but the documentation never got updated, and became stale and inaccurate. It is now hosted on our documentation wiki along with all of our other software documentation.

View full post on MySQL Performance Blog

• Laurynas Biveinis joined the Percona Server project as a developer.
• We continued working on our upcoming Percona Server 5.5 stable release. Vadim has also spent a lot of time benchmarking against MySQL 5.5. Sorry, I can’t reveal how good the numbers are until the benchmarks are fully validated. Watch this blog for Vadim’s announcement.
• We began investigating the effort required to port Percona Server to Windows. We are interested in knowing how many people using MySQL on Windows would be ready to pay for us to support Percona Server on Windows. If you are, you can contact our Sales team to discuss.
• We have changed our Debian/Ubuntu packages to build with readline, not editline. This has been a problem with a lot of Debian/Ubuntu software. This fix will be released in the next version of Percona Server.
• We improved the performance and reliability of using shared memory for the InnoDB buffer pool.
• We updated Percona.TV, our companion site for MySQL videos, screencasts, and webinars. A lot of new Percona-Server-related material is available there now, and very shortly our webinars will also be there, so you won’t have to hassle with Webex or GoToMeeting’s obnoxious system requirements just to watch a recorded webinar.

In XtraBackup news,

• XtraBackup has a new logo, shown below. We stayed with the cat theme to match Percona Server’s logo.
• We’re continuing to work on support for 5.5, and testing and finishing the new features parallel backups, streaming, and compression inside the xtrabackup binary instead of the innobackupex script.
• We moved the target milestone from version 1.6 to 1.7 for supporting XtraBackup on Windows. If you would like it sooner, again we can make it happen with your financial support. Please contact Sales to discuss.

Percona XtraBackup Logo

View full post on MySQL Performance Blog

• As you might have seen, we released Percona Server 5.1.55-12.6. This release also updated our repositories for Debian Squeeze.
• We’re enhancing the PROCESSLIST to include columns for rows examined, sent, and read. This can be useful for understanding how much progress a query has made, and potentially how long until it completes.
• Our 5.5 release is a release candidate at the moment. When it goes to stable status, several command-line options and configuration variables will be renamed. We did not always choose good names for variables and options, and this is the best time to fix that.
• We are working on a new adaptive flushing algorithm that should further improve the quality and consistency of query response time and throughput when the disks can’t keep up. It’s too early to provide details, but we’ll keep you informed as we organize our thoughts more and have some real results to show.

News this week for Percona XtraBackup:

• It’s now possible to do incremental backups on compressed tables.
• We’re improving incremental backups with streaming, so that incrementals can be taken without a base backup needing to be present on the local host. This can save even more disk space.
• Fred is working on improving the innobackupex documentation.

View full post on MySQL Performance Blog

• For users who upgraded to Squeeze, the new version of Debian, we’re expecting to support Squeeze in our repositories on the next release based on MySQL 5.1.55, which we estimate will be released on March 9th. This should also update the Maverick repository for Ubuntu users.
• If you’re waiting for the innodb_lazy_drop_table feature in Percona Server, unfortunately it doesn’t look like we can get it into the next release. It was just too late in the release process to have time to do proper QA, and we take quality very seriously.
• Yasufumi clarified his idea for XtraDB to store statistics for the ::records_in_range() handler function, instead of accessing the data. This would prevent queries from needing to enter the InnoDB kernel during the planning phase, which can be a severe bottleneck especially for complex queries, which need to check the number of records in ranges many times. If you have ever seen a server with dozens of queries in “statistics” state, that’s the bottleneck this feature could help alleviate.
• We merged a change developed by Facebook that reduces excess fcntl() calls. This has been shown to double throughput on sysbench benchmarks.

News for XtraBackup:

• We are working on XtraBackup 1.5, but we don’t have a firm release date.
• We are also working towards XtraBackup 1.6, which contains lots of new features, and of course fixes bugs.
• We have decided to make innobackupex always back up the MySQL system database, even for partial backups; it contains data that is necessary to restore other data correctly.

View full post on MySQL Performance Blog

Read more on PRWeb

Read more on Joystiq

Read more on PRWeb via Yahoo! News

Read more on PRWeb via Yahoo! News