We use Amazon RDS for database servers and historically have had a practice of having smaller database server in QA and DEV to save cost. I would consider this a pretty common practice - but what I have also discovered is that it can lead to fixing non-bugs, or issues that will not arrise in production.

Let me try and describe a (~) worst case and some simple math to illustrate:

Production

• 10G of RAM
• 100 IOPS Storage Device (single hard disk)
• Workload is 100% reads
• 10K queries/second

QA

• 9G of RAM
• 100 IOPS Storage Device (single hard disk)
• Same workload (100% reads)
• Can only do 1K queries/second!

Production is serving its 10K queries/second with a 100% cache hit rate, but with the 1G less RAM, QA is only able to serve with a 99% cache hit rate. Each query touches on average 10 distinct …

Hi Karthik,

Thanks for your feedback. I've made a note of your request. Either me or someone from our team will explain about the redo log format.

Rgds,
anna

This is the start of the heavy travel season for the MySQL Community Team. So if you are attending PHPTek, Drupalcon, Texas LinuxFest, SELF, Redhat Summit, or Lonestar PHP please make sure to say ‘hi’ while you are in Chicago, Portland, Austin, Charlotte, Boston, or Addison. This group of trips is starting with a swag bag full of MySQL stickers, thumb drives, and ‘boogie bots’

MySQL Boogie Bots

Talks PHPTek – Ten Things to Make Your MySQL Servers Faster and Happier — May 16th, 2:45p – 3:45p Texas Linuxfest – The Proper Care and Feeding of a MySQL Database for Linux Administrators — May 31st, 11:25a – 12:20p SELF – Two full days of MySQL talks but I am talking on Ten Things to Make Your MySQL Servers Faster and Happier. MySQL 101, MySQL User Administration — June 8th – 9th Redhat Summit – Big & Traditional Databases — June 12th, 4:40p – 5:50p</li?

• 
  …

So let’s clone our current Drupal 7.22 site from MySQL 5.1 that came with CentOS 6.4 and get it running on MySQL 5.6.

Upgrading MySQL 5.1 -> 5.6 has an official recommendation of making sure the intermediate 5.5 update is performed too. Please review Section 2.11.1 while you make a backup of all your data. Yes, you do have to make a backup. When you run the upgrade, there are tables in the mysql scehma that will be tweaked and skipping a step can make for a very messy late night in an attempt to recover.

An other thing to look for is that on occasion new reserved words are introduced that may conflict with column names in use in your schemas. So it pays to read through the release notes for new reserved words and then run a quick grep on your tables to be safe. If you find that there is a new reserved word …

SkySQL & Monty Program’s MariaDB Team coming to a city near you!

read more

During the last months we’ve worked hard on a new and exiting project!

“We’re making it easier to show your databases in a glance”

I’m very proud to reveal the project for the first time because I am convinced that Glimpsee will change the way you “watch” the status of your databases…

Glimpsee is not another monitoring tool, it is the easiest way we’ve found to make DBA’s life easier.

I can’t say more about Glimpsee at this point but keep in mind these few words: simple, simple and… simple!

An alpha release of Glimpsee is already running for a lucky few. Register now to be the firsts to discover Glimpsee!
 

www.glimpsee.net

…

Continuent Tungsten 2.0 is a major step forward that includes key feature improvements to help you manage very large datasets on MySQL. It also sets the stage for operation in cloud environments like Amazon.

We cover the following details to help you plan for using the new release:

Major improvements in Continuent Tungsten 2.0, including replication and connectivity upgrades Major improvements

It was a very good blog about the internals. If possible please share the internals InnoDB Log file (Redo Log ).

Thanks,
Karthik.P.R

Percona XtraBackup 2.0.7 has been published with support for GTID based replication. As promised, here is the step-by-step guide on how to create a new GTID based slave (or repair a broken one) using XtraBackup. The process is pretty straightforward.

1- Take a backup from any server on the replication environment, master or slave:

# innobackupex /destination/

In the destination folder there will be a file with the name xtrabackup_binlog_info:

# cat xtrabackup_binlog_info
mysql-bin.000002        1232            c777888a-b6df-11e2-a604-080027635ef5:1-4

Now it contains both, binary log coordinates and GTID information.

…

Anybody else noticed that Percona appears to not be a US entity any more?

I observed it today.

$ sudo /usr/bin/innobackupex ...
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
and Percona Ireland Ltd 2009-2012.  All Rights Reserved.

This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.

In previous versions this did say Percona Inc, 2009-2012.

The footer of the Documentation also states © Copyright Percona Ireland Ltd. 2009-2013.