Personal blog of Yzmir Ramirez

One of our customers recently reported that MongoDB’s diagnostic metrics—collected via FTDC (Full-Time Diagnostic Data Capture)—had stopped updating. As a result, no metrics were being collected, either through diagnostic data files or the getDiagnosticData command. Key metrics such as uptime were no longer progressing. While the cluster remained fully operational, the lack of observability introduced a […]

When I joined the Percona Support team in early 2013, MySQL 5.6 was being launched. I remember all the buzz and euphoria surrounding its release: it was a big step from the 5.5 series, carrying important changes in the MySQL architecture and internals that brought highly anticipated features such as the (still incipient) multi-threaded replication and online DDLs. What was not necessarily evident to the general public at the time was the focus it had on highly concurrent environments: MySQL 5.6 was targeting the future. What that meant in practice was, for many workloads that were still common at the time, 5.6 could perform worse than 5.5: it started pouring support tickets from unhappy customers that did the upgrade and were looking for assistance on this front.

It was a steep learning curve for me. Luckily – or as expected – I was surrounded by experts: Percona was already at the forefront of MySQL development and innovation, and my colleagues from the Percona Support team are some of the best in the industry. I was taught how to approach the analysis and troubleshooting of a MySQL server using a tried-and-tested method supported by tools crafted and honed by these same experts to make this task more effective. Fast forward eight years and we continue to operate with an improved version of this same method, which I’m going to present to you in this series of blog posts.

Where Do I Start?

One could argue that “it depends” but that is not the case when what you are aiming to do is analyze the performance of a MySQL server – or any server for that matter. You start by getting to know the server under which the service is running and how it behaves under load.

We can, then, break this approach into two distinct parts:

1. Getting to “know” the server
2. Understanding how the server behaves under load

The secret to starting on this road well is obtaining the right data. The first part can be considered more of a “static” analysis: we are looking for information about the underlying server’s (a) hardware specifications, (b) general OS settings, as well as (c) MySQL-specific configuration. It doesn’t matter much when this data is gathered as it should remain unchanged in the short term.

For the second part, however, the timing matters: data must be gathered either at a precise moment (such as while experiencing a problem) or covering a target time frame. In the case of a general MySQL server assessment, the time window must include peak time, when the load in the server is at its highest level. Usually, we want MySQL tuned in such a way that it is able to handle traffic during the busiest period of the day/week. If it can do that then it should be able to handle the more ordinary workload without breaking a sweat. On the other hand, when we are troubleshooting a specific scenario or circumstance, we need to capture the data at the moment the issue is manifesting itself. We will discuss this further later in this article.

Knowing the Server

The scenario is a common one, I believe all of you have been there before. A colleague or maybe a customer approaches you looking for some help with a server that is not performing well, one that you have never seen before. It might be a common web server running Apache and basic PHP, a more complex application server running Ruby on Rails or a full Java stack, or yet a dedicated database server running MySQL, PostgreSQL, or MongoDB.

To start with, this box where the service is running on, what kind of server is this? How much memory is available? How many cores? What about storage, is it fast, is there enough disk space? Is it running on CentOS, Ubuntu, or something else? Is it a VM?! Which kernel version? Is it swapping … is there any swap space configured at all?

You can find the answers to those questions by connecting to the server and looking around, running various specific commands to build the initial picture of the server, akin to building a puzzle from pieces you collect here and there. Do this a few times, though, and you will get bored and probably forget to collect a piece of information (or two). This is the kind of procedure that can be scripted and that has been done already by clever experts in this field, through different tools. The one we use and maintain is pt-summary, which is part of the Percona Toolkit. If you have one of the Percona repositories configured, you can install the toolkit with a simple:

sudo apt-get/yum install percona-toolkit

I will show you how to use it in a moment.

What MySQL?

What about the MySQL part? When it comes to inspecting a MySQL server, there is some key information that is helpful to obtain upfront: what distribution and version, if it is a replica, or maybe a PXC/Galera node, the size of the Buffer Pool, redo log space, table cache, temporary tables, …

There is another tool in the Percona Toolkit specific for this, pt-mysql-summary (and if you are wondering, yes, there is also a pt-pg-summary and pt-mongodb-summary, but those are subjects for another blog series).

First Impressions

With the information provided by pt-summary and pt-mysql-summary, we can now get a more clear picture of what that server is and start to get a sense of how MySQL is configured in view of the host server, of how the database settings fit in the available physical resources. It then becomes easier, for example, to contrast the Buffer Pool size with the available memory in the server and ponder about how much memory the mysqld process is using, or yet spot a clearly misconfigured/unbalanced setting. Spend a few years doing this and you may start relating a given server version associated with a couple of specific settings values to a “popular” bug you remember the ID by heart… let’s just hope you haven’t got that far already.

The combination of the information obtained from the “pt-summaries” provides what I call a “static” view of the server: it helps us draw our first impressions but it is akin to looking at a still picture of an engine. How does it perform in motion?

An Engine in Motion

The performance of a server is dependent on the physical resources available as well as the workload in play, with the workload in the case of a database server, in a simplified view, being a combination of queries and concurrency. Some workloads are CPU-bound while others are more IO-intensive. Some workloads don’t change much over time, some follow a distinct pattern over the day/week/month/season. It’s very rare to come across a workload that is completely unpredictable, and when that happens it is usually a temporary scenario.

This discourse about workloads occupies a central point here for a reason: we tune a server for the workload it runs and not merely for the specs it has. But how do we do this? We start by observing the server operating.

This observation can be divided into two large categories:

• at the operating system level, we can observe how the physical resources (CPU, memory, storage, network) are being used with tools such as mpstat, iostat, vmstat, and netstat;
• at the database level, we can observe how MySQL is performing through a collection of queries such as the popular SHOW ENGINE INNODB STATUS and SHOW PROCESSLIST but also others that will cover, for instance, status variables and transaction and mutex-specific information.

Gathering all this data manually would be impractical and very difficult to coordinate, a chance there is pt-stalk, another tool from the Percona Toolkit, that automates this whole process.

Percona Support Favorite Triad

There you have it: a combination of data collected from pt-summary, pt-mysql-summary, and pt-stalk provides a good insight into a MySQL server. In the following articles, I will walk you through how we interpret the data provided by each of these tools as well as how to correlate them to understand how MySQL is performing. Once you understand how this works, the last post in this series will show you how you can obtain much of the same information (and sometimes more) from PMM. For now, I’ll leave you with a simple procedure to run them, which should be a handy reference for you to have:

PTDEST=${HOME}/$(hostname)/
mkdir ${PTDEST}
sudo pt-summary > "${PTDEST}/pt-summary.out"
sudo pt-mysql-summary -- --user=root --password=<mysql-root-password>  > "${PTDEST}/pt-mysql-summary.out"
sudo pt-stalk --no-stalk --iterations=2 --sleep=30 --dest="${PTDEST}" -- --user=root --password=<mysql-root-pass>

NOTES:

1) By default, pt-stalk will save the captured data under /var/lib/pt-stalk. We prefer to collect everything in a directory named after the server’s hostname so we employ the variable PTDEST to define one above, which you may adjust to your liking.

2) If your system is configured in such a way that you don’t need to provide credentials to access MySQL then you can remove the

-- --user=root --password=<mysql-root-pass>

section from the pt-mysql-summary and pt-stalk commands above.

3) You can compress the target directory PTDEST and keep a copy of the data archived somewhere or share with a colleague or yet your favorite Support team

tar czvf "${HOME}/$(hostname).tar.gz" "${PTDEST}

Capturing Data on a Server Without the Percona Toolkit

We still need the triad of tools for this to work, the difference here is that if the Percona Toolkit is not installed on the target database server we can still download the tools in separate and execute a modified version of the above procedure as follows:

PTDEST=${HOME}/$(hostname)/
mkdir ${PTDEST}
cd ~
wget percona.com/get/pt-{summary,mysql-summary,stalk}
chmod +x pt*
sudo ./pt-summary > "${PTDEST}/pt-summary.out"
sudo ./pt-mysql-summary -- --user=root --password=<mysql-root-password>  > "${PTDEST}/pt-mysql-summary.out"
sudo ./pt-stalk --no-stalk --iterations=2 --sleep=30 --dest="${PTDEST}" -- --user=root --password=<mysql-root-pass>

In the Next Post …

What is the most relevant information about your server you can find in a pt-summary report and how does it relate to database performance. Stay tuned!

Clear and structured bug, improvement, and new feature request reports are always helpful for validating and fixing issues. In a few cases, we have received these reports with incomplete information which can cause a delay in the verification of issues. The most effective method to avoid this situation is to ensure complete information about the issue when filing a report.

In this post we will discuss:

• The best ways to report an issue for Percona products
• Including a “how to reproduce” test case to verify the issue
• The purpose of bug/improvement/new feature verification

https://jira.percona.com is the central place to report a bug/improvement/new feature request for all Percona products.

Let’s first discuss a few important entries which you should update when reporting an issue.

Project: The product name for which you wish to report an issue.

Issue Type: Provides options for the type of request. Example: Bug/Improvement/New Feature Request.

Summary: Summary of the issue which will serve as the title. It should be a one-line summary.

Affects Version/s: The version number of the Percona software for which you are reporting an issue.

Description: This field is to describe your issue in detail. Issue description should be clear and concise.

Bug report:

• Describe the actual issue.
• Add test case/steps to reproduce the issue if possible.
• If a crash bug, provide my.cnf and error log as additional information along with the details mentioned in this blog_post.
• In some cases, the supporting file for bug reports such as a coredump, sqldump, or error log is prohibitively large. For these cases, we have an SFTP server where these files can be uploaded.

      Documentation bug:

• Provide the documentation link, describe what is wrong, and suggest how the documentation could be improved.

Improvement/New Feature  Request:

• For new features, describe the need and use case. Include answers to such questions as “What problem it will solve?” and “How will it benefit the users?”
• In the case of improvements, mention what is problematic with the current behavior. What is your expectation as an improvement in a particular product feature?

Note: When reporting an issue, be sure to remove/replace sensitive information such as IP addresses, usernames, passwords, etc. from the report description and attached files.

Upstream Bugs:

Percona Server for MySQL and Percona Server for MongoDB are patched versions of their upstream codebases. It is possible that the particular issue originated from the upstream version. For these products, it would be helpful if the reporter also checks upstream for the same issue. If issues exist upstream, use the following URLs to report an issue for these respective products.

MySQL: https://bugs.mysql.com
MongoDB: https://jira.mongodb.org

If you are a Percona customer, please file a support request to let us know how the bug affects you.

Purpose of Bug/Improvement/New Feature Request verification

• Gather the required information from the reporter and identify whether the reported issue is a valid bug/improvement/new feature.
• For bugs, create a reproducible test case. To effectively address, the bug must be repeatable on demand.

Any incorrect assumptions can break other parts of the code while fixing a particular bug; this is why the verification process is important to identify the exact problem. Another benefit of having a reproducible test case is that it can then be used to verify the fix.

While feature requests and improvements are about ideas on how to improve Percona products, they still need to be verified. We need to ensure that behavior reported as a new feature or improvement:

• Is not a bug
• Is not implemented yet
• For new feature verification, we also check whether there is an existing, different way to achieve the same.

Once bugs, improvement, and new features are validated, the issue status will be “Open” and it will move forward for implementation.

When users experience memory usage issues with any software, including MySQL®, their first response is to think that it’s a symptom of a memory leak. As this story will show, this is not always the case.

This story is about a bug.

All Percona Support customers are eligible for bug fixes, but their options vary. For example, Advanced+ customers are offered a HotFix build prior to the public release of software with the patch. Premium customers do not even have to use Percona software: we may port our patches to upstream for them. But for Percona products all Support levels have the right to have a fix.

Even so, this does not mean we will fix every unexpected behavior, even if we accept that behavior to be a valid bug. One of the reasons for such a decision might be that while the behavior is clearly wrong for Percona products, this is still a feature request.

A bug as a case study

A good recent example of such a case is PS-5312 – the bug is repeatable with upstream and reported at bugs.mysql.com/95065

This reports a situation whereby access to InnoDB fulltext indexes leads to growth in memory usage. It starts when someone queries a fulltext index, grows until a maximum, and is not freed for quite a long time.

Yura Sorokin from the Percona Engineering Team investigated if this is a memory leak and found that it is not.

When InnoDB resolves a fulltext query, it creates a memory heap in the function

fts_query_phrase_search

This heap may grow up to 80MB. Additionally, it has a big number of blocks (

mem_block_t

) which are not always used continuously and this, in turn, leads to memory fragmentation.

In the function

exit

, the memory heap is freed. InnoDB does this for each of the allocated blocks. At the end of the function, it calls

free()

which belongs to one of the memory allocator libraries, such as

malloc

or

jemalloc

. From the

mysqld

point of view, everything is done correctly: there is no memory leak.

However while

free()

should release memory when called, it is not required to return it back to the operating system. If the memory allocator decides that the same memory blocks will be required soon, it may still keep them for the

mysqld

process. This explains why you might see that

mysqld

  still uses a lot of memory after the job is finished and all de-allocations are done.

This in practice is not a big issue and should not cause any harm. But if you need the memory to be returned to the operating system quicker, you could try alternative memory allocators, such as jemalloc. The latter was proven to solve the issue with PS-5312.

Another factor which improves memory management is the number of CPU cores: the more we used for the test, the faster the memory was returned to the operating system. This, probably, can be explained by the fact that if you have multiple CPUs, then the memory allocator can dedicate one of them just for releasing memory to the operating system.

The very first implementation of InnoDB full text indexes introduced this flaw. As our engineer Yura Sorokin found:

Options to fix

We have a few options to fix this:

1. Change implementation of InnoDB fulltext index
2. Use custom memory library like jemalloc

Both have their advantages and disadvantages.

Option 1 means we are introducing an incompatibility with upstream, which may lead to strange bugs in future versions. This also means a full rewrite of the InnoDB fulltext code which is always risky in GA versions, used by our customers.

Option 2 means we may hit flaws in the jemalloc library which is designed for performance and not for the safest memory allocation.

So we have to choose between these two not ideal solutions.

Since option 1 may lead to a situation when Percona Server will be incompatible with upstream, we prefer option 2 and look forward for the upstream fix of this bug.

Conclusion

If you are seeing a high memory usage by the

mysqld

process, it is not always a symptom of a memory leak. You can use memory instrumentation in Performance Schema to find out how allocated memory is used. Try alternative memory libraries for better processing of allocations and freeing of memory. Search the user manual for

LD_PRELOAD

to find out how to set it up at these pages here and here.

The requirements for managing and running a database in a modern enterprise have evolved over the past ten years. Those in charge of running enterprise databases have seen their focus shift from ensuring access and availability, to architecture, design and scalability responsibilities. Web-first companies pioneered the change by charging site reliability engineers (SRE’s) or multi-faceted DBAs with the task of ensuring that the company’s main revenue engine not only stayed up, but could scale to wherever the business needed to go. This is a far cry from the classic enterprise DBA’s top responsibilities: keep it up, keep it backed up, and react to issues as they present themselves.

Today, enterprises look for new revenue models to keep up with a shifting technology paradigm driven by the cloud. The requirements and needs for managing their database environments are changing along with this shift. In the SaaS world, application outages mean lost revenue. Worse, it leads to customer churn and gives your competitors an opening. To keep revenue flowing, every part of a SaaS company’s critical infrastructure needs to be planned out: redundancy should be built-in, and a future-proof architecture should be built to accommodate scale.

The more issues you can design out before launch, the less chance of a catastrophic outage later on. This means as a SaaS provider you want your DBAs and database engineers architecting a database that avoids problems at scale, and you want them working with your developers to write better, more efficient database calls. The database infrastructure is designed and automated to work at scale, while taking into account efficient use of resources for meeting today’s requirements.

When companies move to the cloud, the cloud provider takes care of much of the operational automation and many of the mundane day-to-day tasks (for example, using database as a service (DBaaS) options such as Amazon RDS and Aurora). But this does not eliminate the need for database expertise: it moves the function closer to the design and development side of the application. Someone needs to not only design and tune the database to support the application, but also has to understand how to build the modular pieces available in the cloud into a cohesive scalable unit that meets the needs of the application and the company. This means there are much higher impacts and clearer ROIs realized from efficient database expertise.

Over the years at Percona, we have seen this shift as well. Currently, more than 50% of the support tickets our customers open are related to application design issues, query performance or database infrastructure design. This is a far cry from five years ago when these represented less than 20% of our overall caseload. This makes sense, however, when you think about the maturity of our database products and the technological advances that impact the database. A more stable MySQL and MongoDB, coupled with advances in either homegrown automation or cloud-based infrastructure, reduce the likelihood of common crashing bugs and “Core Database Software” related bugs. Instead, outages and issues are increasingly caused by design decisions, bad code or unplanned-for edge cases. In order to keep up, DBAs need to evolve to move upstream to have the greatest impact.

At Percona, we recognize the changing requirements of modern database deployments. In fact, we have been providing database expertise since the beginning of the SaaS and cloud era. We recognize the needs of clients that choose to run on a DBaaS platform are slightly different than those managing their own full-stack database deployments.

That’s why we created a brand new tier of support focused on DBaaS platforms. These services allow you to rely on your cloud provider for operational break-fix support, while augmenting that with proven world-class expertise focused on the design, development, and tuning of the database itself (which cloud providers typically don’t address).

We also launched a DBaaS-focused version of our Percona DBA service. The Percona DBA service focuses on designing, setting up, and proactively improving your DBaaS cloud environment to ensure you get the most out of your investment. 

Contact us for more details on our new support and managed service options that can help optimize your cloud database environments, and make them run as efficiently as possible with the applications that drive your business.

The post The Evolution of the DBA in an “As-A-Service” World appeared first on Percona Database Performance Blog.

Upstream platform vendors have announced the general end of life (EOL) for Red Hat Enterprise Linux 5 (RHEL 5) and its derivatives, as well as Ubuntu 12.04 LTS. With this announcement comes some implications to support for Percona software running on these operating systems.

RHEL 5 was EOL as of March 31st, 2017 and Ubuntu 12.04 LTS was end of life as of April 28th, 2017. Pursuant to our end of life policies, we are announcing that these EOLs will go into effect for Percona software on August 1st, 2017. As of this date, we will no longer be producing new packages, binary builds, hotfixes, or bug fixes for Percona software on these platforms.

We generally align our platform end of life dates with those of the upstream platform vendor. The platform end of life dates are published in advance on our website under the page Supported Linux Platforms and Versions.

Per our policies, Percona will continue to provide operational support for your databases on EOLed platforms. However, we will be unable to provide any bug fixes, builds or OS-level assistance if you encounter an issue outside the database itself.

Each platform vendor has a supported migration or upgrade path to their next major release.  Please reach out to us if you need assistance in migrating your database to your vendor’s supported platform – Percona will be happy to assist you.

In this blog post, I’ll discuss my experience as a Solutions Engineer in explaining the value of Percona software and services to customers.

The inspiration for this blog post was a recent conversation with a prospective client. They were exploring open source software solutions and professional services for the first time. This is a fairly common and recurring conversation with individuals and enterprises exploring open source for the first time. They generally find Percona through recommendations from colleagues, or organic Google searches. One of the most common questions Percona gets when engaging at this level is, “How does Percona’s software compare with << Insert Closed-source Enterprise DB Here >>?”

We’re glad you asked. Percona’s position on this question is to explain the value of Percona in the open source space. Percona does not push a particular flavor of open source software. We recommend an appropriate solution given each of our client’s unique business and application requirements. A client coming from this space is likely to have a lengthy list of compliance, performance and scalability requirements. We love these conversations. Our focus is always on providing our customers with the best services, support, and open-source technology solutions possible.

If there were a silver bullet for every database, Percona would not have been as successful over the past 10 (almost 11!) years. We know that MongoDB, MariaDB, MySQL Enterprise, MySQL Community, Percona Server for MySQL, etc., is never the right answer 100% of the time. Our competitors in this space will most likely disagree with this assessment – because they have an incentive to sell their own software. The quality of all of these offerings is extremely high, and our customers use each of them to great success. Using the wrong database software for a particular use-case is like using a butter knife to cut a steak. You can probably make it work, but it will be a frustrating and unrewarding experience.

Usually, there are more efficient alternatives.

There is a better question to ask instead of software vs. software, which basically turns into an apples vs. oranges conversation. It’s: “Why should we partner with Percona as our business adopts more open-source software?” This is where Percona’s experience and expertise in the open-source database space shine.

Percona is invested in ensuring you are making the right decisions based on your needs. Choosing the wrong database solution or architecture can be catastrophic. A recent Ponemon study (https://planetaklimata.com.ua/instr/Liebert_Hiross/Cost_of_Data_Center_Outages_2016_Eng.pdf) estimates the average cost of downtime can be up to $8,800 per minute. Not only is downtime costly, but re-architecting your environment due to an errant choice in database solutions can be costly as well. Uber experienced these pains when using Postgres as their database solution and wrote an interesting blog post about their decision to switch back to MySQL (https://eng.uber.com/mysql-migration/). Postgres has, in turn, responded to Uber recently (http://thebuild.com/presentations/uber-perconalive-2017.pdf). The point of bringing up this high-profile switch is not to take sides, but to highlight the breadth of knowledge necessary to navigate the open source database environment. Given its complexity, the necessity of a trusted business partner with unbiased recommendations should be apparent.

This is where Percona’s experience and expertise in the open source database space shines. Percona’s only investors are its customers, and our only customers are those using our services. Because of this, our core values are intertwined with customer success and satisfaction. This strategy trickles down through support, to professional services and all the way to the engineering team, where efforts are focused on developing software and features that provide the most value to customers as a whole.

Focusing on a business partner in the open source space is a much more important and worthwhile effort than focusing on a software provider. Percona has hands-on, practical experience with a varying array of open-source technologies in the MySQL, MariaDB, and MongoDB ecosystems. We’ve tracked our ability to assist our customer’s efficiencies in their databases and see a 30% efficiency improvement on average with some cases seeing a 10x boost in performance of their database. (https://www.percona.com/blog/2016/07/20/value-database-support/). The open source software itself has proven itself time and again to be the choice of billion dollar industries. Again, there is not one universal choice among companies. There are success stories that run the gamut of open source software solutions.

To summarize, there’s a reason we redirect the software vs. software question. It’s not because we don’t like talking about how great our software is (it is great, and holds it own with other open source offerings). It’s because the question does not highlight Percona’s value. Percona doesn’t profit from its software. Supporting the open-source ecosystem is our goal. We are heavily invested in providing our customers with the right open source software solution for their situation regardless of whether it is ours or not. Our experience and expertise in this space make us the ideal partner for businesses adopting more open source technology in place of enterprise-licensed models.

This blog post is a summary of the webinar Percona Software News and Roadmap Update – Q1 2017 given by Peter Zaitsev on January 12, 2017.

Over the last few months, I’ve had the opportunity to meet and talk with many of Percona’s customers. I love these meetings, and I always get a bunch of questions about what we’re doing, what our plans are and what releases are coming.

I’m pleased to say there is a great deal going on at Percona, and I thought giving a quick talk about our current software and services, along with our plans, would provide a simple reference for many of these questions.

A full recording of this webinar, along with the presentation slide deck, can be found here.

Percona Solutions and Services

Let me start by laying out Percona’s company purpose:

To champion unbiased open source database solutions.

What does this mean? It means that we write software to offer you better solutions, and we use the best of what software and technology exist in the open source community.

Percona stands by a set of principles that we feel define us as a company, and are a promise to our customers:

• 100% free and open source software
• Focused on finding solution to maximize your success
• Open source database strategy consulting and implementation
• No vendor lock-in required

We offer trusted and unbiased expert solutions, support and resource in a broad software ecosystem, including:

• MySQL
• Percona Server
• MariaDB
• Percona XtraDB Cluster
• Galera Cluster for MySQL
• MariaDB Galera Cluster
• MongoDB
• Percona Server for MongoDB
• Amazon RDS for MySQL/MariaDB/Aurora
• Google CloudSQL

We also have specialization options for PaaS, IaaS, and SaaS solutions like Amazon Web Services, OpenStack, Google Cloud Platform, OpenShift, Ceph, Docker and Kubernetes.

Percona’s immediate business focus includes building long-term partnership relationships through support and managed services.

The next few sections detail our current service offerings, with some outlook on our plans.

98% Customer Satisfaction Rating

Over the last six months, Percona has consistently maintained a 98% Customer Satisfaction Rating!

Customer Success Team

Our expanded Customer Success Team is here to ensure you’re getting most out of your Percona Services Subscription.

Managed Services Best Practices

• Unification based on best practices
• Organization changes to offer more personal service
• Increased automation

Ongoing Services

Consulting and Training. Our consulting and training services are available to assist you with whatever project or staff needs you have.

• Onsite and remote
• 4 hours to full time (weeks or months)
• Project and staff augmentation

Advanced HA Included with Enterprise and Premier Support. Starting this past Spring, we included advance high availability (HA) support as part of our Enterprise and Premier support tiers. This advanced support includes coverage for:

• Percona XtraDB Cluster
• MariaDB Galera Cluster
• Galera Cluster for MySQL
• Upcoming MySQL group replication
• Upcoming MySQL Innodb Cluster

Enterprise Wide Support Agreements. Our new Enterprise Wide Support option allows you to buy per-environment support coverage that covers all of the servers in your environment, rather than on a per-server basis. This method of support can save you money, because it:

• Covers both “MySQL” and “MongoDB”
• Means you don’t have to count servers
• Provides highly customized coverage

Simplified Support Pricing. Get easy to understand support pricing quickly.

To discuss how Percona Support can help your business, please call us at +1-888-316-9775 (USA),
+44 203 608 6727 (Europe), or have us contact you.

New Percona Online Store – Easy to Buy, Pay Monthly

• Purchase some of Percona’s services online
• Fast and easy credit card payments
• Recurring monthly payments
• https://www.percona.com/store

Percona Software

Below are the latest and upcoming features in Percona’s software. All of Percona’s software adheres to the following principles:

• 100% free and open source
• No restricted “Enterprise” version
• No “open core”
• No BS-licensing (BSL)

Percona Server for MySQL 5.7

Overview

• 100% Compatible with MySQL 5.7 Community Edition
• 100% Free and Open Source
• Includes Alternatives to Many MySQL Enterprise Features
• Includes TokuDB Storage Engine
• Focus on Performance and Operational Visibility

Latest Improvements

• Improved space allocation for TokuDB:
• Directory per database layout for TokuDB:
• Column compression (5.6 only)
• Security updates

Features about to be Released 

• Integration of TokuDB and Performance Schema
• MyRocks integration in Percona Server
• MySQL Group Replication
• Starting to look towards MySQL 8

Percona XtraBackup 2.4

Overview

• #1 open source binary hot backup solution for MySQL
• Alternative to MySQL Enterprise backup
• Parallel backups, incremental backups, streaming, encryption
• Supports MySQL, MariaDB, Percona Server

New Features

• Support SHA256 passwords and secure connection to server
• Improved Security (CVE-2016-6225)
• Wrong passphrase detection

Percona Toolkit

Overview

• “Swiss Army Knife” of tools
• Helps DBAs be more efficient
• Helps DBAs make fewer mistakes
• Supports MySQL, MariaDB, Percona Server, Amazon RDS MySQL

New Features

• Improved fingerprinting in pt-query-digest
• Pause file for pt-online-schema-change
• Provide information about transparent huge pages

Coming Soon

• Working towards Percona Toolkit 3.0 release
• Comprehensive support for MongoDB
• New tools are now implemented in Go

Percona Server for MongoDB 3.2

Overview

• 100% compatible with MongoDB 3.2 Community Edition
• 100% open source
• Alternatives for many MongoDB Enterprise features
• MongoRocks (RocksDB) storage engine
• Percona Memory Engine

New

• Percona Server for MongoDB 3.2 – GA
• Support for MongoRocks storage engine
• PerconaFT storage engine depreciated
• Implemented Percona Memory Engine

Coming Soon

• Percona Server for MongoDB 3.4
• Fully compatible with MongoDB 3.4 Community Edition
• Updated RocksDB storage engine
• Universal hot backup for WiredTiger and MongoRocks
• Profiling rate limiting (query sampling)

Percona Memory Engine for MongoDB

Benchmarks

Percona Memory Engine for MongoDB® is a 100 percent open source in-memory storage engine for Percona Server for MongoDB.

Based on the in-memory storage engine used in MongoDB Enterprise Edition, WiredTiger, Percona Memory Engine for MongoDB delivers extremely high performance and reduced costs for a variety of use cases, including application cache, sophisticated data manipulation, session management and more.

Below are some benchmarks that we ran to demonstrate Percona Memory Engine’s performance.

Percona XtraDB Cluster 5.7

Overview

• Based on Percona Server 5.7
• Easiest way to bring HA in your MySQL environment
• Designed to work well in the cloud
• Multi-master replication with no conflicts
• Automatic node provisioning for auto-scaling and self-healing

Goals

• Brought PXC development in-house to server our customers better
• Provide complete clustering solution, not set of LEGO pieces
• Improve usability and ease of use
• Focus on quality

Highlights

• Integrated cluster-aware load balancer with ProxySQL
• Instrumentation with Performance Schema
• Support for data at rest encryption (InnoDB tablespace encryption)
• Your data is safe by default with “strict mode” – prevents using features that do not work correctly
• Integration with Percona Monitoring and Management (PMM)

New in Percona XtraDB Cluster 5.7

• One option to secure all network communication: pxc-encrypt-cluster-traffic
• Zero downtime maintenance with ProxySQL and Maintenance Mode

Percona Monitoring and Management

Overview

• Comprehensive database-focused monitoring
• 100% open source, roll-your-own solution
• Easy to install and use
• Supports MySQL and MongoDB
• Version 1.0 focuses on trending and query analyses
• Management features to come

Examples of PMM Screens

What queries are causing the load?

Why are they causing this load?

How to fix them:

System information:

What happens on OS and hardware level:

As well as the database level:

New in Percona Monitoring and Management

• Continuing to improve and expand dashboards with every release
• Includes Grafana 4.0 (with basic Alerting)
• SSL support for server-agent communications
• Supports authentication for server-agent communication
• Added support for Amazon RDS
• Reduced space consumption by using advanced compression

Coming Soon 

• PMM server available as AMI and Virtual Appliance image
• Better MongoDB dashboards
• Continuing work on dashboards Improvement
• Query analytics application refinements
• Short term continuing focus on monitoring functionality

Check out the Demo

• http://pmmdemo.percona.com

Percona Live Open Source Database Conference 2017 is right around the corner!

The Percona Live Open Source Database Conference is the premier event for the diverse and active open source database community, as well as businesses that develop and use open source database software. The conferences have a technical focus with an emphasis on the core topics of MySQL, MongoDB, PostgreSQL and other open source databases. Tackling subjects such as analytics, architecture and design, security, operations, scalability and performance, Percona Live provides in-depth discussions for your high-availability, IoT, cloud, big data and other changing business needs. This conference is an opportunity to network with peers and technology professionals by bringing together accomplished DBA’s, system architects and developers from around the world to share their knowledge and experience – all to help you learn how to tackle your open source database challenges in a whole new way

This conference has something for everyone!

• April 24-27, 2017
• Santa Clara, CA, USA
• MySQL, MongoDB, PostgreSQL, other open source databases
• https://www.percona.com/live/17/

Register now and get the early bird rate, but hurry prices go up Jan 31st.

Sponsorship opportunities are available as well. Become a Percona Live Sponsor, download the prospectus here.

We are proud to announce the new Percona online store!

Keeping your database environment tuned, optimized and high-performance is key to achieving business goals. If your database goes down, so does your business. Percona experts have a long history of helping enterprises ensure their databases are running smoothly. With Percona, you can meet today’s workloads, and prepare for future workloads before they impact performance.

Now we’ve made it even easier to get Percona database services: visit Percona’s new online store! The webstore is perfect for ordering a health audit and immediate, smaller-scale database support. Simply select your service type, answer a few questions about your environment, and then submit. A Percona expert will be in touch.

The webstore makes it fast and easy to purchase Percona Services, with recurring monthly credit card payments. Shop now for Percona’s highly responsive, effective and affordable support and service options, including MySQL Standard Support, MongoDB Standard Support and a MySQL Health Audit.

Percona has some of the best reviews and one of the highest renewal rates in the industry. We can help you increase your uptime, be more productive, reduce your support budget and implement fixes for performance issues faster.

Check out the new Percona online store here!

In this post, I’ll discuss how database support is good for your enterprise.

Years ago when I worked for the MySQL Support organization at the original MySQL AB, we spoke about MySQL Support as insurance and focused on a value proposition similar to that of car insurance. You must purchase car insurance before the incident happens, or insurance won’t cover the damage. In fact, most places around the world require automobile insurance. Similarly, many organizations that leverage production-use technology have their own “insurance” by means of 24/7 support.

In my opinion, this is a very one-sided view that does not capture the full value (and ROI) that a database support contract with Percona provides. With a Percona support contract, you are assured that your database environment (virtual, physical, or in the cloud) is fully covered – whether it’s one server or many.

Increasingly – especially with the introduction of cloud-based database environments – database servers are being spun up and torn down on a day-to-day basis. However briefly these databases exist, they need support. One of the challenges modern businesses face is providing support for a changing database infrastructure, while still maintaining a viable cost structure.

Let’s look at the different dimensions of value offered by Percona Support based on the different support cases we have received throughout the years.

Reduce and Prevent Downtime

If your database goes down, the time to recover will be significantly shorter with a support agreement than without it. The cost of downtime varies widely between organizations. A recent IBM-sponsored Ponemon Institute research study found that the average data security breach could cost upwards of $7.01M (in the United States).

With our clients, we’ve found preventing even one significant downtime event a year justifies support costs. Even when the client’s in-house team is very experienced, our help is often invaluable as we are exposed to a great variety of incidents from hundreds of companies. It is much more likely we have encountered the same incident before and have a solution ready. Helping to recover from downtime quickly is a reactive part of support – you can realize even more value by proactively working with support to get advice on your HA options as well as ensure that you’re following the best database backup and security practices.

Better Security

Having a database support contract by itself is not enough to prevent all security incidents. Databases are only one of the attack vectors, and it takes a lot of everyday work to stay secure. There is nothing that can guarantee complete security. Database support, however, can be a priceless resource for your security team. It can apply security and compliance practices to your database environment and demonstrate how to avoid typical mistakes.

The cost of data breaches can be phenomenal, as well as impact business reputations much more than downtime or performance issues. Depending on the company size and market, costs vary. Different studies estimate costs ranging in average from $1.6M to 7.01M in direct costs. Everyone agrees leaving rising security risks and costs unchecked is a recipe for disaster.

Fix Database Software Bugs

While you might have great DBAs on your team who are comfortable with best practices and downtime recovery, most likely you do not have a development team comfortable with fixing bugs in the database kernel or supporting tools. Getting up-to-date software fixes reduces downtime. It also helps ensure efficient development and operations teams, avoid using complex workarounds and other commonly faced issues.

Reduce Resources

We deal with a large number of performance-related questions. When we address such problems, we provide a better user experience, save costs, and minimize environmental impact by reducing resource use.

Savings vary depending on your application scale and how optimized the environment is already. In the best cases, our support team helped customers make applications more than 10x more efficient. In most cases, we can help make things at least 30% more efficient. If you’re spending $100K or more on your database environment, this benefit alone makes a support agreement well worth it.

Efficient Developers

You cannot minimize the importance of development efficiency. Too often customers don’t give their developers support access, even though they critically help realize application’s full value. Developers make database decisions about schema design all the time. These include query writing, stored procedures, triggers, sharding, document storage, or foreign keys. Without a database support contract, developers often have resort to “Google University” to find an answer – and often end up with inapplicable, outdated or simply wrong information. Combined with this, they often apply or resort to time-consuming trial and error.

With the help of a Percona Support team, developers can learn proven practices that apply to their specific situation. This saves a lot of time and gets better applications to market faster. Even with a single US-based developer intensively working within the database environment, a support agreement might justify the cost based on increased developer efficiency alone. Larger development teams simply cannot afford to not have support.

Efficient Operations

Your operations staff (DBAs, DevOps, Sysadmins) are in the same boat – if your database environment is significant, chances are you are always looking for ways to save time, make operations more efficient and reduce mistakes. Our support team can provide you with specific actionable advice for your challenges.

Chances are we have seen environments similar to yours and know which software, approaches and practices work well (and which do not). This knowledge helps prevent and reduce downtime. It also helps with team efficiency. Percona Support’s help allows you to handle operations with a smaller team, or address issues with a less experienced staff.

Better Applications

Percona Support access helps developers not only be more productive, but results in better application quality because application database interface design, schema, queries, etc. best practices are followed. The Percona team supports many applications, for many years. We often  think about problems before you might think about them, such as:

• “How will this design play with replication or sharding?”
• “Will it scale with large amounts of users or data?”
• “How flexible is such a design when the  application will inevitably be evolving over years?”

While a better application is hard to quantify, it really is quite important.

Faster Time to Market

Yet another benefit that comes from developers having access to a database support team is faster time-to-market. For many agile applications, being able to launch new features faster is even more important than cost savings – this is how businesses succeed against the competition. At Percona, we love helping businesses succeed.

Conclusion

As you see, there are a lot of ways Percona Support can contribute to the success of your business. Support is much more than “insurance” that you should consider purchasing for compliance reasons. Percona Support provides a great return on investment. It allows you to minimize risks and costs while delivering the highest quality applications or services. Our flexible plans can cover your database environment, even if it is an ever-changing one, while still allowing you to plan your operations costs.