We published a blog a few months back about incorporating telemetry into our core database products. My colleague, Bartek, did a great job highlighting the benefits to both Percona and our users, so I won’t re-list them all here, but we did want to let everyone know that our alpha phase is over (a small agent that runs one time at installation) and we’re launching our GA’d telemetry solution (and there will be another blog on that too!). This solution runs more frequently than the alpha and will include a lightweight agent that works in conjunction with a DB plugin to gather metrics and transmit them to Percona. That agent will live in its own repository since it’s shared across all our core DB products and is a required package for installation even if you choose to disable telemetry.
Why are we writing this?
Because there will come a time when you may encounter one of the following two errors when installing or updating our products (Percona Server for MySQL, Percona XtraDB Cluster, Percona Server for MongoDB, and our Percona for PostgreSQL):
Error for RPM
|
1 2 3 |
Error: Problem: conflicting request Nothing provides percona-telemetry-agent needed by XXX Command returned status: 1 |
Error for DEB
|
1 2 3 |
The following packages have unmet dependencies: Depends: percona-telemetry-agent but it is not installable E: Unable to correct problems, you have held broken packages. |
Why does it need its own repository?
Can’t you just embed it in the same repository as the database? Great questions…and I promise I asked the same thing on several occasions. The truth is, we’re pretty serious about security, and by putting the agent in its own repository, we can react faster and more thoroughly to any security updates needed for the agent. There are three repositories just for Percona Server for MySQL, three more for Percona XtraDB Cluster, and when you add in Percona Server for MongoDB and Percona Distribution for PostgreSQL, you can see there are over a dozen copies of the same file that need to be updated and then independently verified…that’s just too much room for error even with automation!
So what do you need to do?
Those of you already using the Percona Release repository simply need to update the package, and you’ll be good to go! You already know the benefits…you can stop reading!
Not using Percona Release?
😱 Please let me share with you the value you’re missing!
Repositories, in general, provide a bunch of benefits to you, and these benefits only get better with scale.
- Future updates are a breeze with apt update/upgrade or yum update, and we spend an inordinate amount of time testing multiple upgrade paths using this method so you can confidently go from the supported version to the latest while also being able to target specific versions as needed if you’re an n-1 kind of person!
- Repositories are easy to mirror and set up your own internal distribution hub so you only need to refresh the packages once to your hub and then can easily distribute this to your entire fleet of servers, your network admins will love you!
The benefits of using Percona Release are:
- All our packages are signed, and Percona Release includes the GPG keys to validate you’re getting only the packages we intended you to get and not some shady software claiming to be from us.
- We try to make the hard stuff easier by giving you tools that make complex installations simple! We ship a bunch of scripts with Percona-Release that will take care of much of the heavy lifting, so in the case of installing Percona Server for MySQL, running
percona-release setup -y ps80 will disable conflicting repo providers of the software and install Percona Server…and you can rest assured that the next time you try to update Percona Server with your package manager, you won’t accidentally get the OS providers version of any tools. - You can easily enable/disable repos with a single command and switch back and forth between release, testing, and experimental channels. I mean, do you really want to mess with yum.conf.d files?
- Last month, we retired two very old repositories (percona-original and percona-tools) because just about everything in there is end of life. By installing Percona-Release we’ll automatically disable stale repositories and ensure you have important repositories enabled to get the most out of Percona software.
So the moral of this story is: Install the Percona-Release repository and rest easy knowing that you’ll always have access to the latest and greatest software from Percona available with just a simple yum/apt update!
