The following policies apply to the Percona Support for MySQL, MongoDB, MariaDB, PostgreSQL, and DBaaS service.
- How do I use Support?
- Does Percona provide login troubleshooting?
- What are the standard login methods?
- Which servers should I include in my Support subscription?
- What types of incidents are covered?
- What types of incidents are not covered?
- What are the different priority levels and response times?
- What platforms are supported?
- What kinds of bugs will Percona fix?
- What is the difference between a bug fix and a hot-fix?
- What is the timing of bug fixes?
- What is an Emergency Onsite?
How do I use Support?
Support is provided 24x7x365 worldwide. You can contact Percona engineers via telephone, instant messaging, email, and our Customer Portal depending on your support tier. See contacting support for ways to open a support incident.
As with other emergency service providers, Percona prioritizes work based on incident priority in order to ensure that customers experiencing severe production outages are restored to service as soon as possible. Real time contact methods such as telephone and instant messaging should be reserved for critical situations that demand and directly benefit from immediate feedback.
Does Percona provide login troubleshooting?
If your support tier offers login support, we will login to your systems on request to gather diagnostic information to help resolve issues more quickly. However, support engineers will only perform support-related tasks on supported software. Support engineers will not perform routine remote DBA tasks or help you with non-covered software, for example. During a login session, the engineer will not make any changes to your system; they will only review and advise you.
What are the standard login methods?
Our standard login method to connect directly to customers systems is via SSH or RDP. If customers need screen share, our preferred method is Zoom. All other technologies, including VPN, are customer specific. Click here for more information
Which servers should I include in my Support subscription?
For each application for which you intend to receive support, Percona requires that you include all production database servers that store the data related to this application (Percona XtraDB Clusters and MongoDB clusters that use an arbiter node and don't hold data, do not need to be included). This allows us to assist you with covered support requests before those issues cause production outages, and protects you by ensuring every server related to your business-critical applications receives timely responses to support requests.
If the application you wish to cover makes use of a complex configuration, such as multiple region DR or database clustering, we require that all servers that underpin that application be included in your support subscription. As an example, if you had a source-source cluster with a replica for performing backups and an identical environment in another region for DR, you would need to include all six servers in your support subscription to guarantee that Percona can provide support for any of the database issues that could arise. For customers with complex configurations or a large or dynamic overall server count, an enterprise-wide contract with unlimited servers may be a better option.
In addition to the above, Percona recommends that any servers that are used to provide testing, development or staging environments for your organization related to the covered applications also be included. Covering these non-production servers allows us to help you stage and test database software upgrades or hot fixes, replicate issues outside of your production environment and gather and analyze query metrics before potentially problematic changes go into your production environment.
Please be aware that Percona can only provide assistance with servers that are covered as part of your support agreement.
What types of incidents are covered?
In a nutshell, we will fix software that is not working correctly, and coach you in specific tasks with which you require help. More specifically, we provide:
- Problem resolution support for the covered software, to diagnose and fix discrete problems with specific symptoms, when it is reasonable to believe that the problem is caused by the software's misbehavior. Examples include server crashes and wrong results to queries
- Advisory support answer your questions about how to use the covered software. For example, we can advise you with installation, upgrades, and backups; help you to understand how to use particular software features, and explain the purpose and behavior of a configuration option.
- Customers with consultative support can seek assistance with topics specific to your deployment, including assistance with writing or tuning queries and stored routines, optimizing schema definitions, indexing strategies, and server configurations for performance, and other similar tasks unrelated to product usage, service restoration, or bug fixing. Note that consultative support is not a replacement for dedicated Consulting engagements and is intended to resolve incidents that are well-defined with narrow scope.
- Some common topics for which customers use us include:
- Advice on performance issues
- Advice on operational best-practices
- Advice on backup and recovery
- Advice on advanced data recovery
- Analysis of software bugs
- Analysis of software crashes and outages
- Analysis and advice on replication
- Advice on high availability
- Assistance with query tuning
What types of incidents are not covered?
The following types of incidents are excluded:
- Bug fixes for non-open-source versions of software (e.g. OEM-licensed MySQL, MongoDB Enterprise, etc.)
- Performing tasks for you, rather than advising you in your efforts to perform them. For example, we can coach you on how to configure replication, but we will not set up replication for you. If you need assistance in setting up replication, consulting would be happy to assist you
- Open-ended requests, such as reviewing a server to find whether anything is wrong with it. This type of open-ended performance review or system audit is covered under a Consulting Audit or a Percona Care Package. Each incident must be filed to resolve a pre-existing specific question or situation
- Architecture and design advice, such as choosing a good scaling strategy. This type of request requires a deep analysis and review of your requirements and setup and is handled by a consulting architecture and design review
What are the different priority levels and response times?
Priority 1 (urgent)
A problem that severely impacts your use of the software in a production environment (such as loss of production data or in which your production systems are not functioning). The situation halts your business operations and no procedural workaround exists.
Priority 2 (high)
A problem where the software is functioning, but your use in a production environment is severely reduced. The situation is causing a high impact to portions of your business operations and no procedural workaround exists.
Priority 3 (medium)
A problem that involves partial, non-critical loss of use of the software in a production environment or development environment. For production environments, there is a medium-to-low impact on your business, but your business continues to function, including by using a procedural workaround. For development environments, where the situation is causing your project to no longer continue or migrate into production.
Priority 4 (low)
A general usage question, reporting of a documentation error, or recommendation for a future product enhancement or modification. For production environments, there is low-to-no impact on your business or the performance or functionality of your system. For development environments, there is a medium-to-low impact on your business, but your business continues to function, including by using a procedural workaround.
Response time commitments for each priority differ based on your support level. Refer to the relevant Support Tier page for your supported product:
What platforms are supported?
Support itself is platform independent, your questions will be answered regardless of the OS you use. Bug fixes are provided according to this list of supported platforms.
What kinds of bugs will Percona fix?
Percona will fix bugs within Percona software subject to the Percona Software and Platform Lifecycle. Fixes for non-Percona software are available depending on your support level. Refer to the relevant Support Tier page for your supported product.
When requested, Percona will investigate possible bugs that cause crashing, freezing, incorrect results, data corruption, performance problems, or security breaches. Bugs must be verified via repeatable test cases.
Percona engineers can help you with creating test cases. Collaboration with you is key for us to be able to verify and fix any bug that we are working on. We will work with you to collect analytics data and test potential workarounds.
With any issue reported to us, our number one goal is to restore service. When it comes to handling bugs, the quickest way to restore service and prevent downtime is often to provide a workaround (for example changing settings, changing sql, starting with special flags, etc.).
Fixing a bug is a complex and often time-consuming process. Sometimes it is not possible or feasible to fix a particular bug, but we will apply our best effort in good faith. If no fix is possible, we will seek a workaround instead.
Percona can merge bug fixes from newer versions to older versions of the software, or undo fixes that were added in newer versions.
What is the difference between a bug fix and a hot-fix?
For Percona software, once we are able to repeat a bug and the development work is completed, a bug fix will be included in the next released version of the software and you will need to upgrade after the release to receive the fix.
Customers who have hot fixes as part of their offering are entitled to a custom build of the current version of Percona software with the fix applied as soon as development has completed the fix. This gives you access to critical bugs as soon as possible. Note, you will not need to upgrade server versions to receive the fix.
We are unable to guarantee that bug fixes will be incorporated into other flavors of the software, but bug fixes will always be available for Oracle® and MongoDB to adopt freely if they so choose.
Fixes created by Percona that are applied to non-Percona software (ex: MariaDB Server, or MySQL Community instead of Percona Server for MySQL, etc.) are hot fixes by default, as we do not issue regular maintenance releases of that software.
What is the timing of bug fixes?
Bug fixes in Percona software will be included in the next scheduled release that is open for code changes. This may not be the immediate next release because it may already be frozen or being built.
A hot fix is available more quickly because it is a special build of the software product incorporating the fix you need. This lets you keep using exactly the same version plus just the bug fix you need.
We report bugs upstream wherever possible and work to leverage our relationship with the open source community, partners, and other vendors to find solutions for our customers. All bug fixes created by Percona are made available at no charge to the open source community and upstream vendors such as Oracle, MariaDB, MongoDB, and PostgreSQL so that the fixes may be incorporated into their versions of the software. However, the decision when or whether to incorporate those fixes is beyond Percona’s control.
What is an Emergency Onsite?
An Emergency Onsite is a Percona Support subscription add on, providing one or more optional on site visits per year to assist with restoring service in the event of a Priority 1 total production outage. Customers with this add on may request an emergency onsite visit if the normal support process has been unable to restore service within 24 hours of reporting the incident and there are no signs of imminent restoration of service. Percona will dispatch someone to your location within 24 hours of the request.