This checklist will help make the most of your time with Percona by ensuring that our access to your servers is correctly set up before we begin working with you.

Please make sure you've provided us with the items listed below, so that we can log in to your servers. If there's more than one server, please tell us each server’s function (e.g., “master” or “read-only slave”), and all other information that applies to each server. This helps ensure we are working on the intended servers. Be sure to point out critical things we should be careful not to disturb.

Engineer Keys

As of Q1 2016, engineer public SSH keys are available from the domain and can be easily downloaded in similar fashion to percona-toolkit.

For example:


Where firstname.lastname is the first and last name of the engineer assigned to work with you.

We provide two types of engineer key packages:

  1. Individual packages that create the username for the engineer should it not already exist on the system, as well as the Percona group if it does not already exist, and installs the public SSH keys into /home/username/.ssh/authorized_keys
  2. A shared package that does not perform any group or user setup, but instead installs all files into /usr/share/percona/engineer

The shared package is available from:

This package installs all engineer public SSH keys into /usr/share/percona/engineer/keys

No user management is performed. You need to perform this yourself. The files are used only for reference purposes.

As an example, to add all engineer keys to shared Percona users after installing the shared package:

mkdir -p /home/percona/.ssh/
chmod 700 /home/percona/.ssh/
cat /usr/share/percona/engineer/keys/*.pub > /home/percona/.ssh/authorized_keys
chmod 600 /home/percona/.ssh/authorized_keys

Please note that old keys are not removed or managed in any way by this method. You must remove them yourself.

RPM/DEB packages available via are not at this time GPG signed. We plan to add this in the future. At the time of this writing,’s SSL configuration gains an A+ grade on qualys SSL Labs, and we support Forward Secrecy.

Engineers connect from service bastions with public IPs ( and ( Please configure your firewall to allow access from these IP addresses to relevant services within your network.

MySQL Percona User

Create a MySQL user named percona, grant all privileges on *.* and give us the password (or leave it in a file in Percona’s engineer home directory, preferably named .my.cnf).

Extended information about the required MySQL account on your database server that can also be provided:

  • What is the username and password of the MySQL account we should use?
  • Have you granted SELECT, SUPER, PROCESS, RELOAD ON *.* to the user?
  • What is the IP address or hostname of the MySQL server?
  • On what IP address does MySQL listen, if bind_address is set in its configuration?
  • What is the port or socket, if they are non-standard?
  • If possible, create a “percona” database and give us all privileges to it (to create temporary tables while optimizing queries). This is completely optional, but it's helpful to us. You can do it by running: CREATE DATABASE percona; GRANT ALL ON percona.* TO 'user'@'host';

Security Policies

When you exchange information with us, or give us access to your servers, please make sure you do it securely. If you need to upload sensitive data to our servers securely for data recovery purposes, please request our GPG key. This lets you encrypt large files that only we can decrypt.

For security and accountability reasons, please do not do any of the following:

  • Don't permit Percona to log into a shared account. Create a dedicated Percona user.
  • Don't install our SSH keys in the root's home directory.
  • Don't permit Percona to use a common MySQL account such as root. Create a dedicated Percona user in MySQL.
  • Don't permit our SSH key to be forwarded to another host. If we must access your systems through an intermediary server (ex: jump-host), please create an SSH key on that server and install the matching public key on the systems we should be able to access.

Other Types of Access

We can work with nearly any type of access. Direct SSH access to the server is most efficient, however, any more elaborate types of access (such as proprietary VPN programs, platform-dependent technologies such as GoToMyPC, etc.,) can be less efficient – sometimes significantly less efficient.

Many of these applications cannot co-exist, so they require elaborate tricks with virtual machines, etc. Multiple hops are also less efficient, as keystroke latency becomes a problem. The use of a graphical desktop on a remote system is also difficult.

In general, Cisco VPN and OpenVPN are the most efficient VPNs for Percona to use. We can also support VPN termination via our bastion host. If you're using VPN, please tell us all the necessary information:

  • What type of VPN system are we connecting? Do we need to download a client?
  • Please send us the configuration file; e.g., the .PCF file (if you're using a Cisco VPN), OpenVPN, or other configuration information
  • Otherwise, please tell us all of the following that apply: the domain server's hostname and IP address, username, password, group name, group password
  • VPN might not work well with DNS, so please tell us the IP addresses for the servers

If you're using any other type of connectivity such as VNC, Remote Desktop, GoToMyPC, or similar, please provide the details.


The most common reason we can't log in is that the installed SSH key is for a different user than the one Percona was assigned. The next most common reason is that there are line breaks, incorrect permissions or other problems with the key file. After you've set the key up, please let us know so we can test it.

If you are using VPN, consultants will login from their own machines using your VPN client, so do not restrict access to any specific range of IP addresses. Also, be sure to use the engineer’s own public SSH key, provide password authentication or provide an SSH key of your choosing communicate securely.

Performance Audit Checklist

A performance audit is our most popular service. In order to expedite a performance audit, please ensure that the following tools are installed on each machine:

  • Perl DBI and DBD::mysql
  • MySQL client, vmstat, iostat, mpstat and optionally numactl, innotop, and dstat
  • If there is no outside network access, please install the Percona Toolkit

These tools are very helpful for observing what the machine is doing, so we highly recommend you install them. If you can't install any of the above for some reason, we can still perform a limited audit. It may result in less information being analyzed by the audit.

For our analysis, we need the slow query log. Please note the original values so that you can change them back:


Then, rotate your logs (you can move the current one and issue FLUSH LOGS;) and set these values:

SET GLOBAL log_output=FILE;
SET GLOBAL slow_query_log_use_global_control='log_slow_verbosity,long_query_time,log_slow_rate_limit​';
SET GLOBAL log_slow_verbosity='full';
SET GLOBAL slow_query_log=1;
SET GLOBAL long_query_time=0;
SET GLOBAL log_slow_slave_statements=1;
SET GLOBAL log_slow_rate_limit=100;

Some of these variables are only available in Percona Server, so it is fine if they don't get set.

Once you have one hour or 1GB (whichever is first) of data, set the values back to their defaults and save the file off. Please upload the log to our sftp or another secure location, after compression, and provide it to our consultants.

It may be good to do this on both a master and a read slave.

Note: When you set long query time to 0 it may have some io impact as all queries will be collected. In that case, you may want to use 0.1 or 1.

A short architectural overview can go a long way towards giving us a “head start” on the performance audit. Please provide brief documentation that includes:

  • Programming language(s) used
  • Deployment diagrams (if any)
  • Components used (load balancers, caching systems, etc...)
  • Database replication/sharding Information
  • Planned upgrades/changes – alerting us in advance of any new features or changes planned during the time of the audit can save significant time and rework
  • Anything else you feel is worth mentioning

You don't have to go to extremes with any of this. Too much information can cause extra work, too (lists of tables and columns are not necessary). Keep in mind that we have probably seen dozens of systems like yours, so just giving us “hints” about what's unique or noteworthy about your systems can be very effective. For example, “it's a social networking application using Ruby On Rails and we are not sharded yet, but we do a lot of caching” tells us a great deal.
We highly recommend that all of our customers have alerting and monitoring systems in place.

We have a comparison of a few recommended monitoring solutions on our blog here: If you need help installing or configuring them, please let us know. We are glad to assist.

Amazon RDS - Relational Database Service

Ideally you can provide Percona remote SSH access to a secured Linux server in your own controlled VPC subnet in AWS. You will securely (by way of GPG or other encryption medium) provide a MySQL account for Percona against your RDS instance so that all communication between MySQL client and RDS happens on Amazon's private internal network. Any auditing or compliance requirements are to be made known to Percona prior to engagement.