We believe both approaches have their benefits and drawbacks and mixing them right way allows you to get your problems solved most efficient way.

Onsite visits are great as they allow consultant to meet your team in person and great for relationship building. It is great for architecture design and review as you can sit down with the team and use drawing board. It also often allows the best focus both for consultant and for participating team - when consulting visit is arranged it is usually the top priority for some of the staff members which provide consultant with information and assistance he might need.

Onsite visits also often allow to get prompt attention from other team - looking for network engineer to understand network topology or for someone from marketing to get the growth plans - they typically can be brought in for question.

I believe Onsite visits also offer unmatched training experience for the team - one of the team members can work side by side with consultants observing what he does and asking the question about the progress.

The Single Day visits are often extremely valuable as a kick off to do application redesign, for performance review or for starting long term Remote DBA or support relationships. They can be done with little planning as basically for any system there is enough work to spend efficiently understanding the system and working on the pressing problems customer may have. Such visits are often result in a lot of “homework” as application changes or implementing changes on production which when can benefit from remote followups to validate changes and provide further advice.

Multi day onsite visits require a bit more planning to be efficient. Many times in my career I would come to the customer for a week only to find I have created the implementation plan within 1-2 days and it will take a while to implement it and pass it through development and testing stages. Before long onsite visit it is very good to have a call with consultant to understand what exactly needs to be done, how much time and what resources it requires.

Projects which can be efficient as multi day visits are whenever implementation is required (coding unlike giving advice takes a lot of time) - migration projects, any forms of scripting, implementation (writing queries), hands on setting up MySQL, Replication, Monitoring, High Availability with MMM or DRBD are good examples.

Another good example of efficient Multi-Day visit is when there are multiple groups or multiple applications using MySQL - in such case each of the problem areas/groups can gets its own day or few hours which keeps consultant busy.

To make a Multi-Day visit efficient it is important to plan on what will be done - what people will consultant need to work with and which problems do they have. Providing proper access and having staging/test systems available are also often required.

Remote work has a benefit of consultant being available in the short time intervals and being able to multi task.

Working with the customer there are two types of “waits” which are often encountered. First - waiting on the customer. It could be fixing access problems, completing application changes, QA, scheduling downtime to implement changes and millions of other things. Second - waiting on database (or other) operations to complete - backup, restore, ALTER TABLE, load testing - all of these things take time and make consultant to wait for them.

In case you’re working remotely consultant typically has other tasks to do while such long processes are running. If you’re spending time onsite you may have other tasks or you may not while if you’re working remotely there are always things to do.

Another benefit of remote work - it truly allows to engage the team. If you have consultant onsite getting another one with some specific knowledge is complicated while getting another person to login to the system remotely for a quick look is easy and efficient.

Time is another interesting factor - onsite visits usually happen during office hours while changes to production are often avoided. With remote work it is much easier to do work which needs to be done at night hours.

Remote work however also needs to be well organized. The benefit of onsite work is - it is always planned at very specific time. Given date and time consultant will be there so both consultant and customer prepare for the visit. If appointment is just a phone call or online meeting there is larger chance it can be forgotten by ether party. In many cases the remote work not planned to the specific time at all which can cause it to be delayed because of either party delays.

If you need something to be done fast and you’re doing it remotely make sure to plan it to exact time and make sure there is someone to assist consultant if he needs any help such as access issues, some questions about setup or what exactly given queries are doing. Prompt responses can keep the ball rolling much faster.

Another trick to make remote work successful is to be very clear in your instructions especially if you’re not going to be available to assist consultant when he is doing the work. As remote work is often done cross time zones this becomes a very important factor.

In case you have a lot of work done in such “disconnected” mode it is a good idea to have daily/weekly/or be-weekly (depending on project intensity) calls to get team to discuss the progress and generally get team on the same page.

In general surprisingly a lot of things can be done in completely remote mode - we’ve done not only basic optimizations but architecture redesigns, large scale deployment, migrations and high available architectures implementation such a way often surprising customers (in a good way) of how little customers the work took.

The Great Mix As I mentioned before mixing Onsite and Remote work can be indeed the best mix especially for the complex projects. Onsite visit is great to setup relationships, get initial understanding of the system and get initial project planning. After it is done a lot of work can be done remotely quite efficient while there may be the benefit in onsite status-checks and team interactions as well.

Entry posted by peter | One comment

Add to: | | | |

Entry posted by peter | One comment

Add to: | | | |

With this new functionality, it becomes possible for mk-query-digest to stand on the sidelines and watch queries fly by over TCP. It is only an observer on the sidelines: it is NOT a man in the middle like mysql-proxy, so it has basically zero impact on the running server (tcpdump is very efficient) and zero impact on the query latency. There are some unique challenges to watching an entire server's traffic, but we've found ways to solve those. Some of them are harder than others, such as making sense of a conversation when you start listening in the middle. In general, it's working very well. We can gather just about every bit of information about queries that mysql-proxy can, making this a viable way to monitor servers without the disadvantages of a proxy. In theory, we can gather ALL the same information, but in practice we are going for the 95% case.

As always with Maatkit, this has minimal dependencies. It doesn't require any Net::Pcap or other modules from CPAN. It's written in pure Perl, and it parses the output of tcpdump, rather than watching the network traffic directly. This might sound useless, but it's not. It means you can go tcpdump some traffic on a machine without Perl installed, and copy it to another machine for analysis, or send it via email to your friendly consultant, or do any of a number of other things. Decoupling things is very helpful sometimes.

Let's see how to gather queries and do something useful with them. I'll just watch the queries on a sandbox server on my laptop, and print out the profile synopsis so you can see how it works.

I run a few queries, quit, and cancel tcpdump. Now I've got a file and I'm ready to analyze it. Let's see:

I'm kind of showing off the summary profile here to illustrate that you can get really compact results to see what's going on inside your server. What do you suppose that one query was that took a tenth of a second? We can find out.

Indeed, it's no surprise the query took a tenth of a second to execute, and now you see where "SELECT dual" comes from.

Notice that it is inspecting the protocol enough to see the flags set in the protocol, indicating the warning count, error count, rows affected, and whether no index or no good index was available. Look at the top of the report -- what is up with the 12% of queries that say No_index_used? If we increase --limit a bit, we can see

I did not know that SHOW DATABASES sets the "no index used" flag, did you? Now we both do!

This is just a brief introduction to what the protocol parser can do. Of course, in real life it's much more useful than just seeing a query or two -- it has all the power of mk-query-digest for filtering, aggregating, printing and so forth.

Entry posted by Baron Schwartz | 16 comments

Add to: | | | |

The release 0.8 of the opensource backup tool for InnoDB and XtraDB is available for download.

Key features:

• New mode of innobackupex --stream=tar4ibd; new command tar4ibd based on libtar-1.2.11
• Experimental option --export is added (see Vadim's post "Impossible - possible, moving InnoDB tables between servers"for details)

tar4ibd is made to be sure that read of InnoDB page is consistent. Before we had some complains what in stream mode some pages are getting corrupted, and we suspect tar can do read of pages in time when they changed. So we patches libtar to make read consistent.

Export is added to support moving .ibd tablespaces between servers.

The list of other features in the release includes:

• Support of ARCHIVE tables
• Addded incremental option to innobackupex-1.5.1 script
• Rollback XA PREPAREd transaction automatically at --prepare
• To extend tablespace size, if needed after --prepare
• Data page corruption check is added to local backup mode
• innobackupex can pass --export option
• Bug #389360: innobackupex-1.5.1 accepts scp options

Fixed bugs:

• Bug #388062: Update to innobackupex to include incremental
• fix error handling of tar stream

The binary packages for RHEL4,5, Debian, FreeBSD as well as source code of the XtraBackup is available on http://www.percona.com/mysql/xtrabackup/0.8/.

The project lives on Launchpad : https://launchpad.net/percona-xtrabackup and you can report bug to Launchpad bug system:
https://launchpad.net/percona-xtrabackup/+filebug. The documentation is available on our Wiki.

For general questions use our Pecona-discussions group, and for development question Percona-dev group.

For support, commercial and sponsorship inquiries contact Percona.

Entry posted by Aleksandr Kuzminsky | 6 comments

Add to: | | | |

Beside ideas I put before http://www.mysqlperformanceblog.com/2009/03/30/my-hot-list-for-next-innodb-features/ (and one of them - moving InnoDB tables between servers are currently under development), we have few mores:

- Stick some InnoDB tables / indexes in buffer pool, or set priority for InnoDB tables. That means tables with bigger priority will be have more chances to stay in buffer pool then tables with lower priority. Link to blueprint https://blueprints.launchpad.net/percona-patches/+spec/lru-priority-patch

- Separate LRU list into several lists, and in this way it will allow us to emulate several buffer pool, with features to keep different tables in different buffer pools and also to decrease contention on buffer pool. Link https://blueprints.launchpad.net/percona-patches/+spec/multiple-lru-patch

- We are looking to include Waffle Grid into XtraDB releases with some additional features like caching buffer pool on SSD.

If ideas are interesting for you and you want to support them, contact us

Entry posted by Vadim | 7 comments

Add to: | | | |

check-unused-keys can be invoked and used as follows:

%> check-unused-keys --help
Usage:
     check-unused-keys [OPTIONS]

     Options:
       -d, --databases=<dbname>  Comma-separated list of databases to check
       -h, --help                Display this message and exit
       -H, --hostname=<hostname> The target MySQL server host
       --ignore-databases        Comma-separated list of databases to ignore
       --ignore-indexes          Comma-separated list of indexes to ignore
                                     db_name.tbl_name.index_name
       --ignore-tables           Comma-separated list of tables to ignore
                                     db_name.tbl_name
       --options-file            The options file to use
       -p, --password=<password> The password of the MySQL user
       -i, --port=<portnum>      The port MySQL is listening on
       -s, --socket=<sockfile>   Use the specified mysql unix socket to connect
       -t, --tables=<tables>     Comma-separated list of tables to evaluate
                                     db_name.tbl_name
       --[no]summary             Display summary information
       -u, --username=<username> The MySQL user used to connect
       -v, --verbose             Increase verbosity level
       -V, --version             Display version information and exit

     Defaults are:

     ATTRIBUTE                  VALUE
     -------------------------- ------------------
     databases                  ALL databases
     help                       FALSE
     hostname                   localhost
     ignore-databases           No default value
     ignore-indexes             No default value
     ignore-tables              No default value
     options-file               ~/.my.cnf
     password                   No default value
     port                       3306
     socket                     No default value
     summary                    TRUE
     tables                     No Default Value
     username                   No default value
     verbose                    0 (out of 2)
     version                    FALSE

** FULLTEXT indexes are not taken into account by this patch, so be wary. And, as always, sanity check the suggestions and test thoroughly before making changes to production.

Entry posted by Ryan Lowe | 7 comments

Add to: | | | |

I also plan to attend the conference afternoon on Monday and mid day on Tuesday.

Entry posted by peter | One comment

Add to: | | | |

The Brian's portion of webinar will focus on the Schooner offering as example of flash based appliance - one of solutions I mention in my presentation.

It should be interesting whenever you're interested in Schooner appliance offerings, flash or scaling MySQL in General.

You can follow this url to register.

Entry posted by peter | 2 comments

Add to: | | | |

Entry posted by Ryan Lowe | 7 comments

Add to: | | | |

When you run DROP TABLE there are several things that need to happen – write lock on a table so it cannot be used by any other thread, the data file(s) removal by the storage engine and of course in the end MySQL has to destroy the definition file (.frm). That's not all that happens, there is one other thing:

The entire code which removes a table is surrounded by LOCK_open mutex. The mutex is used in various places inside MySQL, but primarily when tables are being opened or closed. It means that when LOCK_open is locked, no query can be executed because they are stopped from accessing any table.

Here is when the slow file removal on the ext3 file system starts to be a pain. Deleting a 10GB file can take a few seconds and if that is a MySQL table, the mutex remains locked for all that time stalling all queries:

I tried some alternative approaches to trick MySQL into removing smaller files with DROP TABLE to minimize the effect, such as:

• TRUNCATE TABLE large_table; ALTER TABLE large_table ENGINE=…; DROP TABLE large_table;
• TRUNCATE TABLE large_table; OPTIMIZE TABLE large_table; DROP TABLE large_table;

Unfortunately as it turned out each of the administrative commands like ALTER TABLE or OPTIMIZE TABLE one way or another uses LOCK_open mutex when the old table files are deleted:

The only alternative seems to be changing the file system. To XFS for example, which handles file removals much more efficiently:

EXT3

XFS

A better solution through MySQL internals could be to simulate the table drop by renaming the corresponding data file or files and physically removing them outside of the mutex lock. However it may not be that simple, because the actual removal is performed by the storage engine, so it's not something MySQL code can control.

This is certainly not a common situation, but may become a problem to anyone when it's the least expected (e.g. dropping old unused tables).

Entry posted by Maciej Dobrzanski | 19 comments

Add to: | | | |