Nov
27
2019
--

Running PMM1 and PMM2 Clients on the Same Host

Running PMM1 and PMM2 Clients

Running PMM1 and PMM2 ClientsWant to try out Percona Monitoring and Management 2 (PMM 2) but you’re not ready to turn off your PMM 1 environment?  This blog is for you! Keep in mind that the methods described are not intended to be a long-term migration strategy, but rather, simply a way to deploy a few clients in order to sample PMM 2 before you commit to the upgrade. ?

Here are step-by-step instructions for deploying PMM 1 & 2 client functionality i.e. pmm-client and pmm2-client, on the same host.

  1. Deploy PMM 1 on Server1 (you’ve probably already done this)
  2. Install and setup pmm-client for connectivity to Server1
  3. Deploy PMM 2 on Server2
  4. Install and setup pmm2-client for connectivity to Server2
  5. Remove pmm-client and switched completely to pmm2-client

The first few steps are already described in our PMM1 documentation so we are simply providing links to those documents.  Here we’ll focus on steps 4 and 5.

Install and Setup pmm2-client Connectivity to Server2

It’s not possible to install both clients from a repository at the same time. So you’ll need to download a tarball of pmm2-client. Here’s a link to the latest version directly from our site.

Download pmm2-client Tarball

* Note that depending on when you’re seeing this, the commands below may not be for the latest version, so the commands may need to be updated for the version you downloaded.

$ wget https://www.percona.com/downloads/pmm2/2.1.0/binary/tarball/pmm2-client-2.1.0.tar.gz

Extract Files From pmm2-client Tarball

$ tar -zxvf pmm2-client-2.1.0.tar.gz 
$ cd pmm2-client-2.1.0

Register and Generate Configuration File

Now it’s time to set up a PMM 2 client. In our example, the PMM2 server IP is 172.17.0.2 and the monitored host IP is 172.17.0.1.

$ ./bin/pmm-agent setup --config-file=config/pmm-agent.yaml \
--paths-node_exporter="$PWD/pmm2-client-2.1.0/bin/node_exporter" \
--paths-mysqld_exporter="$PWD/pmm2-client-2.1.0/bin/mysqld_exporter" \
--paths-mongodb_exporter="$PWD/pmm2-client-2.1.0/bin/mongodb_exporter" \
--paths-postgres_exporter="$PWD/pmm2-client-2.1.0/bin/postgres_exporter" \
--paths-proxysql_exporter="$PWD/pmm2-client-2.1.0/bin/proxysql_exporter" \
--server-insecure-tls --server-address=172.17.0.2:443 \
--server-username=admin  --server-password="admin" 172.17.0.1 generic node8.ca

Start pmm-agent

Let’s run the pmm-agent using a screen.  There’s no service manager integration when deploying alongside pmm-client, so if your server restarts, pmm-agent won’t automatically resume.

# screen -S pmm-agent

$ ./bin/pmm-agent --config-file="$PWD/config/pmm-agent.yaml"

Check the Current State of the Agent

$ ./bin/pmm-admin list
Service type  Service name         Address and port  Service ID

Agent type                  Status     Agent ID                                        Service ID
pmm-agent                   connected  /agent_id/805db700-3607-40a9-a1fa-be61c76fe755  
node_exporter               running    /agent_id/805eb8f6-3514-4c9b-a05e-c5705755a4be

Add MySQL Service

Detach the screen, then add the mysql service:

$ ./bin/pmm-admin add mysql --use-perfschema --username=root mysqltest
MySQL Service added.
Service ID  : /service_id/28c4a4cd-7f4a-4abd-a999-86528e38992b
Service name: mysqltest

Here is the state of pmm-agent:

$ ./bin/pmm-admin list
Service type  Service name         Address and port  Service ID
MySQL         mysqltest            127.0.0.1:3306    /service_id/28c4a4cd-7f4a-4abd-a999-86528e38992b

Agent type                  Status     Agent ID                                        Service ID
pmm-agent                   connected  /agent_id/805db700-3607-40a9-a1fa-be61c76fe755   
node_exporter               running    /agent_id/805eb8f6-3514-4c9b-a05e-c5705755a4be   
mysqld_exporter             running    /agent_id/efb01d86-58a3-401e-ae65-fa8417f9feb2  /service_id/28c4a4cd-7f4a-4abd-a999-86528e38992b
qan-mysql-perfschema-agent  running    /agent_id/26836ca9-0fc7-4991-af23-730e6d282d8d  /service_id/28c4a4cd-7f4a-4abd-a999-86528e38992b

Confirm you can see activity in each of the two PMM Servers:

PMM 1 PMM 2

Remove pmm-client and Switch Completely to pmm2-client

Once you’ve decided to move over completely to PMM2, it’s better to make a switch from the tarball version to installation from the repository. It will allow you to perform client updates much easier as well as register the new agent as a service for automatically starting with the server. Also, we will show you how to make a switch without re-adding monitored instances.

Configure Percona Repositories

$ sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm 
$ sudo percona-release disable all 
$ sudo percona-release enable original release 
$ yum list | grep pmm 
pmm-client.x86_64                    1.17.2-1.el6                  percona-release-x86_64
pmm2-client.x86_64                   2.1.0-1.el6                   percona-release-x86_64

Here is a link to the apt variant.

Remove pmm-client

yum remove pmm-client

Install pmm2-client

$ yum install pmm2-client
Loaded plugins: priorities, update-motd, upgrade-helper
4 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package pmm2-client.x86_64 0:2.1.0-5.el6 will be installed
...
Installed:
  pmm2-client.x86_64 0:2.1.0-5.el6                                                                                                                                                           

Complete!

Configure pmm2-client

Let’s copy the currently used pmm2-client configuration file in order to omit re-adding monitored instances.

$ cp pmm2-client-2.1.0/config/pmm-agent.yaml /tmp

It’s required to set the new location of exporters (/usr/local/percona/pmm2/exporters/) in the file.

$ sed -i 's|node_exporter:.*|node_exporter: /usr/local/percona/pmm2/exporters/node_exporter|g' /tmp/pmm-agent.yaml
$ sed -i 's|mysqld_exporter:.*|mysqld_exporter: /usr/local/percona/pmm2/exporters/mysqld_exporter|g' /tmp/pmm-agent.yaml
$ sed -i 's|mongodb_exporter:.*|mongodb_exporter: /usr/local/percona/pmm2/exporters/mongodb_exporter|g' /tmp/pmm-agent.yaml 
$ sed -i 's|postgres_exporter:.*|postgres_exporter: /usr/local/percona/pmm2/exporters/postgres_exporter|g' /tmp/pmm-agent.yaml
$ sed -i 's|proxysql_exporter:.*|proxysql_exporter: /usr/local/percona/pmm2/exporters/proxysql_exporter|g' /tmp/pmm-agent.yaml

The default configuration file has to be replaced by our file and the service pmm-agent has to be restarted.

$ cp /tmp/pmm-agent.yaml /usr/local/percona/pmm2/config/
$ systemctl restart pmm-agent

Check Monitored Services

So now we can verify the current state of monitored instances.

$ pmm-admin list

Also, it can be checked on PMM server-side.

Nov
18
2019
--

PMM 2.1, MongoDB Hot Backups, Percona Server Updates: Release Roundup 11/18/2019

Percona Software Release Nov 18

Percona Software Release Nov 18It’s release roundup time here at Percona!

As mentioned a few weeks ago, we are now publishing release roundups comprising all the details and information you need on the previous week (or two)’s releases from Percona. This post will encompass releases from November 4, 2019 – November 18, 2019.

Each roundup will showcase the latest in software updates, tools, and features to help you manage and deploy our software, with highlights and critical information, as well as links to the full release notes and direct links to the software or service itself.

In this edition, we highlight two recent version updates to Percona Server for MySQL, improvements and new features in Percona Monitoring and Management 2.1.0, and some very cool new functions in Percona Server for MongoDB 4.2.1-1, including streaming hot backups in all our active MongoDB releases.

 

Percona Server for MySQL 5.6.46-86.2

On November 6, 2019, we released Percona Server for MySQL version 5.6.46-86.2, the current GA release in the 5.6 series. It includes several bug fixes, including a fix of the Audit log filtering by a user not working and the addition of a package version for the Red Hat Package Manager (rpm). Percona Server for MySQL is an enhanced drop-in replacement for MySQL.

Download Percona Server for MySQL 5.6.46-86.2

 

Percona Monitoring and Management 2.1.0

PMM 2.1.0, a free and open-source platform for managing and monitoring MySQL, MongoDB, and PostgreSQL performance, was released on November 11, 2019. This version has bug fixes and many new features, including a latency detail graph, additional log and config files, and the disabling of heavy-load collectors automatically when there are too many tables.

NOTE: Percona Monitoring and Management (PMM) employs a client/server model. You must download and install both the client and server applications. The directions for doing this are in the documentation.

Download Percona Monitoring and Management 2.1.0

 

Percona Server for MongoDB 4.2.1-1

On November 13, 2019, we released Percona Server for MongoDB version 4.2.1-1, which includes all of the new features of the latest version of MongoDB 4.2 Community Edition, as well as the Percona Memory Engine storage engine, encrypted WiredTiger storage engine, and enhanced query profiling.  Percona Server for MongoDB 4.2.1-1 adds the ability for remote streaming hot backups to Amazon S3 or compatible storage such as MinIO, and is now included in all our active MongoDB releases (3.6, 4.0, and 4.2).

Download Percona Server for MongoDB 4.2.1-1

 

Percona Server for MySQL 5.7.28-31

As of November 13, 2019, Percona Server for MySQL 5.7.28-31 is now the current GA (Generally Available) release in the 5.7 series. It is based on MySQL 5.7.27 and includes all the bug fixes in it. If you’re currently using Percona Server for MySQL 5.7, Percona recommends upgrading to this version of 5.7 prior to upgrading to Percona Server 8.0. Percona Server for MySQL is trusted by thousands of enterprises to provide better performance and concurrency for their most demanding workloads.

Download Server for MySQL 5.7.28-31

That’s it for this roundup, and be sure to follow us on Twitter to stay up-to-date on the most recent releases! Percona is a leader in providing best-of-breed enterprise-class support, consulting, managed services, training and software for MySQL, MariaDB, MongoDB, PostgreSQL, and other open source databases in on-premises and cloud environments.

Nov
13
2019
--

Let Percona Actively Manage Your Databases To Achieve Peak Performance

Percona Managed Database Services

Percona Managed Database ServicesData drives every aspect of your business so your databases need to deliver optimum performance and availability to keep you competitive.

A business requires 24x7x365 database coverage. Keeping your databases stable, performant, and optimized is crucial to your business success.

We understand that finding and retaining qualified DBAs to manage mission-critical database environments can be difficult — Percona is ideally placed to help you meet this challenge. Our Managed Services team is on hand to provide database support at a fraction of the cost of a dedicated, in-house, full-time DBA.

How Percona Managed Services Can Help Your Business

Percona has introduced two new Managed Services options to help you feel confident that your database is performing at the highest level.

Percona Managed Database Services (PMDS) is a flexible, managed database service that delivers exceptional, enterprise-grade expertise across a variety of high-performance enterprise database environments.

PMDS gives you affordable in-depth technical expertise on demand. Our experts proactively monitor your databases around the clock, keeping them running at an optimum level, whether on-premises or in the cloud. This allows us to reduce critical incidents and meet database performance goals, allowing your engineering team to focus on your core business.

The Key Benefits of PMDS:

  • Proactive database monitoring and alert/response mean your database has 24x7x365 oversight.
  • With our robust change management system, you can feel confident any required database modifications are industry best practices.
  • When problems do occur, incident management and root cause analysis (RCA) services are in place to identify and solve issues quickly.
  • Inclusive allocated DBA hours allow you to implement Percona’s recommendations without delay.
  • Your dedicated service delivery manager (SDM) holds monthly calls and produces a report card.
  • Automated reports provide you with monthly security assessments and a weekly health check.

Please visit our webpage to find out more and to download our latest datasheet.

To accompany PMDS we also offer Percona Advanced Managed Database Service (PAMDS). PAMDS is an enhanced Percona service that offers your business additional, specific and in-depth database reporting. This service is ideal for businesses with volatile, complex, or rapidly-expanding database environments.

You can add PAMDS at any point in your engagement with Percona. Please visit our webpage to find out more and to download our latest datasheet.

Percona Monitoring and Management

As part of our managed services offerings, we also utilize Percona Monitoring and Management (PMM). PMM is an award-winning, free, open source platform for managing and monitoring the performance of your database environment.

PMM allows you to visualize query performance for MySQL, PostgreSQL, and MongoDB environments and is used by 1,000’s of organizations worldwide. With PMM you can monitor multiple databases, multiple technologies, and data from multiple providers easily and quickly, regardless of location.

Contact us

Percona Managed Services provides tailored managed database services for your business and helps you lower costs and manage your database complexity.

Our Managed Services team provides deep operational knowledge of MySQL, MongoDB, MariaDB, Amazon AWS, Amazon Aurora and Amazon RDS, Microsoft Azure, and Google Cloud Platform to ensure your database performs at the highest level.

For more information on how Percona Managed Services can help your business, please contact us at +1-888-316-9775 (USA), +44 203 608 6727 (Europe), or have us reach out to you.

Nov
11
2019
--

Prepare Your Databases for High Traffic on Black Friday

Prepare Your Databases For High Traffic

Prepare Your Databases For High TrafficIt’s November, so we all know what that means; it’s peak shopping season, and no date is bigger than Black Friday. But how will your database handle all that new, relentless traffic? Not only does your database have to handle traffic without slowing down, but web servers can sometimes see such sudden traffic as an attack; meaning your site(s) could go down completely.

Every year there are news stories about websites that were unresponsive or disappeared completely right at the exact moment when potential shoppers were coming online. Don’t let this be you! To ensure your databases are prepared for a high traffic event, download our Database Disaster Prevention Checklist and read what we advise you do before, during, and after the big day. Let’s get started.

What You Need To Know About High Traffic Events

  1. Your users expect instant response and immediate feedback from your application. If you don’t give it to them, your competition will.
  2. Database slowdowns for you can be perceived as downtime for your customers, and they will lose confidence in your ability.
  3. A few seconds of downtime costs you not only direct revenue but also lost future business. Use our Cost of Database Downtime Calculator to see just how much downtime could cost you.
  4. When you failover a slow system, the slowness follows to the new system. If your slowness alleviates, it may be because your customers went somewhere else when you were down.
  5. Time is finite; you can’t get more of it. You have to make the most of it. It can be much more valuable than money.

Before the Event

  1. Setup monitoring and tooling before the event. If you can’t see what’s going on, how can you measure your success? Percona Monitoring and Management can help with that.
  2. Load test your applications and test how you will scale under normal and peak loads. The best time to find bottlenecks is before the event, as during is costly and impactful.
  3. Test failover and understand how quickly you can recover. The worst time to find out your failover doesn’t work is during the busiest day of the year.
  4. Put a code and configuration freeze in place in advance of the event. It’s really hard to ensure performance if the application is growing and evolving.
  5. Get a second opinion, double-check, and don’t assume. A large portion of your business is tied to this event. Trust but verify things are ready; it’s worth it. Most big outages are caused by easily overlooked things.
  6. Check your backups. Make sure you have reliable and consistent backups of your databases. This will make it easier to restore a crashed database. Percona XtraBackup for MySQL can help.

During the Event

  1. Realize that failing over to another system is the absolute last resort.  Failing over a busy system moves the traffic to a new server. Additionally, most systems are slower when traffic is added as it takes time to warm up the cache.
  2. Have the right people standing by to monitor, tweak, and fix issues before they get out of hand. Too many issues are prolonged by waiting to get the right people in the room to fix issues. Many larger companies make this an all-hands event.
  3. Don’t lose sight of the goal! Getting back up and running and allowing customers access to the site is your goal, not developing a permanent fix in the heat of the moment. Time to make an impact is finite, but equally important people under pressure are more prone to make mistakes.  An easier temporary fix to get you through the day can work in your favor, as long as you don’t forget to make the permanent one eventually.
  4. Don’t make the problem worse. Some activities can cause cascading slowness… know the impact of the changes before you make them. We get a lot of calls from people who had good intentions to try and fix a minor issue but made a much bigger problem. The road to hell is paved with good intentions.
  5. Collect and store the data needed to analyze and improve for the next event. Often when things don’t go right, issues end up being transient and difficult to understand after the fact. Get the data you need, when things are going well or not.

After the Event

  1. Analyze and understand your traffic and usage. Use this data to plan, enhance, and tweak your strategy for future events.
  2. Don’t leave the quick fixes in place and just forget about them, these could escalate at the worst times. Take the time and expense to fix them during slow periods.
  3. Learn from your mistakes and build a plan to mitigate problems and risks in the future.
  4. Update your systems to the latest builds and security fixes. Take advantage of the slower load and catch up after a freeze/blackout period around the event.
  5. Don’t fall into complacency. Congrats that you survived this year, but each application and user base is a living, breathing entity, and what worked last year may not work this year. You have to analyze, plan, and review on a regular basis.

Conclusion

Now you’re better prepared for the database high-traffic days coming your way soon. For more information, learn how to ensure peak database performance for your event and download our Database Disaster Prevention Checklist, or contact us today. Percona’s experts can maximize your application performance with our open source database support, managed services or consulting for MySQL, MariaDB, MongoDB, PostgreSQL in on-premises and cloud environments.

Database Disaster Prevention Checklist

Oct
31
2019
--

How Percona Support Handles Bugs

how percona handles bugs

how percona handles bugsOne of the great things about Percona, and a Percona Support contract, is that we not only guarantee application performance but we also provide bug fixes for covered software—and not just advice on how to use it. This is most likely missing from most customer’s in-house support, as it requires a team with code knowledge to build and test infrastructure, which only a few companies can afford to invest in.

Whether you deploy MySQL®, MariaDB®, MongoDB®, or PostgreSQL—on-premise, in the cloud, in a DBaaS environment, bare metal, virtualized or containerized—Percona Support has you and your database covered.

Now, back to bugs. While there is no such thing as “bug-free” software, there are often some misunderstandings about bugs and how they are handled. What is a bug? What is a feature? What is a repeatable bug? How will Percona troubleshoot the bug? In this post, we’ll answer some of these questions, and detail how Percona Support supports bug reporting.

Features vs. Bugs

Sometimes, software is designed to work a certain way that may not be what some users expect or want. However, that doesn’t mean that it is a “bug” in the true sense—it may just require a change in behavior to use in the correct manner rather than the way it was utilized in the past. These are considered features rather than bugs.

Unfixable Bugs

There are some behaviors that most people would call a bug, but they arise from design limitations or oversight that are impossible to fix in the current GA version without introducing changes that would destabilize the software. These bugs will need to be fixed in future GA releases. Some bugs are not bugs but rather design tradeoffs. These can’t be “fixed” unless tradeoffs are made, and are therefore tied closer to “features” than bugs.

Workaround

There are going to be unexpected behaviors, unfixable bugs, and bugs that take time to fix, so our first practical response to running into this type of bug is finding a workaround that does not expose it. The Percona Support team helps identify these types of bugs and build workarounds that will result in minimal impact on your business. But be prepared: changes to the application, deployed version, schema, or configuration are often required.

Emergencies

Emergencies are just that—emergencies. When you have one, Percona’s first area of focus is to restore your system to working order. Percona offers 24x7x365 support for production outages to all of our support customers, as well as options for real-time electronic and phone access to its expert technical support team, not just asynchronous communications through a ticketing system.

Bug Turnaround Times

We cannot guarantee turnaround time on a bug fix, as all bugs are different. Some are rather trivial for which we can provide a hotfix as soon as 24 hours after we have a repeatable test case. Others are much more complicated and can take weeks of engineering to fix (or be determined non-fixable in the current GA version of the software). The best thing to do is to report a bug and provide any additional information which would be helpful to get it resolved. (Check out our article “How to report bugs, improvements, and new feature requests” for more information.

Verified Bug Fixes

Once you submit a bug, we will first verify if it is actually a bug. As we detailed above, it might be a feature, or intended behavior, or a user mistake. It’s also possible that it only happened one time and it cannot be repeated. Having a repeatable test case that reveals a bug is the best way for it to be fixed quickly. Our support team is often able to help you create a test case if you’re unable to do so on your own.

Sporadic Bugs

Bugs that only show up sporadically are the hardest ones to fix. For example, you might have a system crash once every few months with no way to repeat it. The cause of such bugs can be very complicated; such as a buffer overrun in one piece of code causing corruption and crashes in other places hours later. And while there are a number of diagnostic tools that exist for such bugs, they can still take some time to resolve. Finally, without that repeatable test case, it is often impossible to verify that the proposed fix actually resolves the bug.

Environmental Bugs

Some bugs are caused by what can be called your “environment”, or setup. It could be hardware bugs or incompatibilities, a build not quite compatible with your version of the operating system, etc. In some cases, we can very clearly point to issues in your environment, and in others, we may suspect the environment is an issue and will ask to see if the bug also happens in other environments, such as with different hardware or OS installation.

Hot Fixes

Our default policy is that we fix bugs in the next release of our software so it can go through the full GA cycle and be properly documented. If workaround can be found so that you can wait until the next release for a fix, this is the best choice. If not, with a Percona Support Contract, we can provide you with a hotfix—a special build containing the version of the software you’re running, with the bug fix of interest applied. Hotfixes are especially helpful if you’re not looking to do a full software upgrade—requiring several revisions—but want to validate the fix with the minimum number of changes. Hotfixes might also be different from the final bug fix that goes into the GA release, as our goal is to provide a working solution for you faster. Afterward, we may optimize or re-architect the code, come up with better option names, etc. that will resolve any outstanding bugs.

Bug Diagnostics

Depending on the nature of the bug, there are multiple tools that our support team will use for diagnostics and finding a way to fix the bug. To set expectations, this can be a very involved process requiring that you provide information or try things on your system, such as:

  • If you have a test case that can be repeated by the Percona team to trigger the bug, the diagnostic problem is solved from the customer side. Internal debugging starts at this point.
  • If we have a crash that we can’t repeat on our system we may ask you to enable “core” file or run the program under a debugger so we can get more information when the crash happens.
  • If the problem is related to performance, you should be ready to gather information such as EXPLAIN, status counters, information from performance schema, etc. along with system-level information like pt-pmp output, pt-stalk, oprofile, or perf.
  • If the problem is a “deadlock,” we often need information from gdb about the full state of the system. Information from processlist, performance_schema, and SHOW ENGINE INNODB STATUS can also be helpful.
  • It may also be helpful to have a test system on which you can repeat the problem in your environment and experiment without impacting a production environment. It is not possible in all cases, but it is useful for bug resolution.
  • Sometimes, for hard-to-repeat bugs, we will need to run a special diagnostics build that provides us with additional debug information. Or, we might need to run a debug build or do a run under valgrind or other software designed to catch bugs. This can have a large performance impact, so it is good to see if your workload can be scaled down for this to be feasible.
  • Depending on your environment, we might need to login to troubleshoot your bug or request that you upload the data needed to repeat the bug in our lab (assuming it is not too sensitive). In cases where direct login is not possible, we can help you create a repeatable test case via phone, chat, or email. Using screen sharing can also be very helpful.

Bugs and Non-Percona Software

Percona Support does cover some software not produced by Percona. For open source software, if it is not exempt from bug fix support, we will provide the custom build with a bug fix as well as provide the suggested fix to the software maintainer for its possible inclusion in its next release. For example, if we find a bug in the MySQL Community Edition, we will pass our suggested fix to the MySQL Engineering team at Oracle. For other software that is not open source, such as Amazon RDS, we can help to facilitate creation and submission of a repeatable test case and workaround, but we can’t provide a fix as we do not have access to the source code.

In Conclusion

When we think about software bugs, there are some good parallels with human “bugs”. Some issues are trivial to diagnose and the fix is obvious, while others might be very hard to diagnose, with doctor after doctor still not able to determine the cause of your disease. Then, even when the diagnosis is found, a cure is not always available or feasible, and we have to settle for “managing” a disease—our parallel to implementing changes and settling for a workaround. In the same way as human doctors, we can’t guarantee we will get to the root of every problem, or fix every problem we find. However, as with having good doctors, having us on your team will help maximize your chances of a successful bug resolution.

How Percona Can Help

Percona’s experts can maximize your database performance with our open source database support, managed services or consulting professional services. For more information on our database services, contact us at +1-888-316-9775 (USA), +44 203 608 6727 (Europe), or have us reach out to you directly.

Sep
16
2019
--

Through the Eyes of a TAM at Percona

TAM at Percona

TAM at PerconaAs a Technical Account Manager at Percona, I get the privilege of working with some of our largest clients.  It is exciting to work where I get to see massive deployments that are pushing current utilization limits. In these environments, however, there are different sorts of challenges that the database teams often face:

  • Automation in managing 1000s of servers
  • Capacity planning
  • Architecting for massively sharded environments
  • Operational maintenance of the fleet

While these challenges aren’t unique to deployments, they become much more complex and frame interesting discussions.  While not unique, the impact of fundamental problems is intensely magnified at scale.

You’ve likely had a bad query that wasn’t using an index make it into production before; the pager goes off at 2 am (30 minutes after a release) that one of your servers had a spike in CPU.  You crawl out of bed, connect to the server, see 45 copies of the same query in the processlist and immediately see the issue. It’s a quick fix; you run the ALTER to add the index, the server returns to normal, and you go back to bed at 2:15 am.

Now, imagine that query was deployed to 1000 servers against a table that takes 18 hours to ALTER.  The CPU spike brings the entire fleet comes to a screeching halt.  That is a scenario that may involve some executives being “less than pleased” with the situation while derailing your week/month/career.

In short – scale really does matter.  True, you don’t want to spend 6 months over-optimizing a new MVP that you are trying to get to market first.  But that doesn’t mean you shouldn’t start optimizing it sooner rather than later.

More posts from the TAM team on the way

This series of posts from our TAM team aims to highlight the potential impact of fundamental issues in large deployments.  Other topics will include discussion about the different types of challenges we see working with clients operating at web-scale.  Keep your eyes open the first posts in this series over the coming weeks!

Aug
20
2019
--

The Impact of Downtime on Your Business

Impact of Downtime

Impact of DowntimeOur latest white paper The Hidden Costs of Not Properly Managing Your Databases discusses the potential losses that you can incur if you do not have a properly configured database and infrastructure setup. A Google study recently found that if an application does not respond in three seconds or less, more than half of mobile website users will leave your site. Even if your system is up, but running slowly, impatient users may perceive this as an outage and go elsewhere.

The impact on your bottom line can be very real. Large social media and gaming websites stand to lose tens of thousands (in some cases hundreds of thousands) of users due to slow applications and websites. Users expect continuous and consistent service. It is essential that you optimize your applications and websites to ensure the best and fastest possible performance.

The Cost of Downtime

A Gartner study estimated the average cost per minute of downtime at $5,600 dollars. At $300,000 per hour, this is a price that few companies can comfortably afford. It is alarming how few well-established companies lack an adequate plan to deal with unexpected downtime.

Our white paper outlines some common disaster recovery strategies which every company should consider implementing. We offer advice on reducing the overall costs of running your database and minimizing the risk of downtime and performance spikes.

To accompany this white paper, we welcome you to use one of our free, bespoke, cost-estimation tools:

The Database Management Savings Calculator gives you a breakdown of how much you could save over a three-year period by implementing different database optimization methods. Potential savings can be substantial, up to 50% of your total database costs over a three-year period.

The Database Downtime Calculator estimates the financial impact that a slow response or downtime can have on your business. This calculator takes into account the revenue that your application generates and factors in how many employees are affected by an outage, as well as how long it would take to restore service.

Reducing the likelihood and impact of downtime requires a solid process, a high-level of expertise, and the right resources in place. Percona has extensive experience advising companies on the best way to configure, manage, and run their databases. We can help you reduce slowdowns, improve workload, and substantially delay the need for upgrades.

Download our white paper for further insight, or contact us directly to discuss how we can help ensure your database is working efficiently, and advise you on managing and mitigating downtime.

Hidden Cost of not managing database

May
01
2017
--

Webinar Thursday 5/1/2017: Percona Software News and Roadmap Update Q2 2017

Percona Software News

Percona Software NewsCome and listen to Percona CEO Peter Zaitsev on Thursday, May 4, 2017 at 11:00 am (PST) / 2:00 pm (EST) discuss Percona’s software news and roadmap, including Percona Server for MySQL and MongoDB, Percona XtraBackup, Percona Toolkit, Percona XtraDB Cluster and Percona Monitoring and Management.

During this webinar, Peter will talk about newly released features in Percona software, show a few quick demos and share with you highlights from the Percona open source software roadmap.

Peter will also talk about new developments in Percona commercial services, and finish with a Q&A.

You can register for the webinar here.

Peter ZaitsevPeter Zaitsev, CEO of Percona

Peter Zaitsev co-founded Percona and assumed the role of CEO in 2006. As one of the foremost experts on MySQL strategy and optimization, Peter leveraged both his technical vision and entrepreneurial skills to grow Percona from a two-person shop to one of the most respected open source companies in the business. With over 150 professionals in 20 plus countries, Peter’s venture now serves over 3000 customers – including the “who’s who” of internet giants, large enterprises and many exciting startups. Percona was named to the Inc. 5000 in 2013, 2014 and 2015.

Peter was an early employee at MySQL AB, eventually leading the company’s High-Performance Group. A serial entrepreneur, Peter co-founded his first startup while attending Moscow State University where he majored in Computer Science. Peter is a co-author of High-Performance MySQL: Optimization, Backups, and Replication, one of the most popular books on MySQL performance. Peter frequently speaks as an expert lecturer at MySQL and related conferences, and regularly posts on the Percona Data Performance Blog. Fortune and DZone also tapped Peter as a contributor, and his recent ebook Practical MySQL Performance Optimization Volume 1 is one of percona.com’s most popular downloads.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com