Install Percona Server for MySQL on Ubuntu 26.04 / 24.04

The version decision comes first, and it changed recently. Percona shipped the final Percona Server for MySQL 8.0 release in June 2026, and 9.7 LTS arrived only days ago, which leaves 8.4 LTS as the mature line to put on a new server. Everything below targets that line.

Original content from computingforgeeks.com - post 5417

Percona’s build drops in where Oracle’s MySQL Community Server sits, then adds the XtraDB storage engine, per-table and per-index counters, a thread pool and a handful of hash UDFs. Installation runs through Percona’s own apt repository and the percona-release helper. This guide covers the repository setup, the install, what the shipped defaults actually are (several are not what people assume), securing the server, creating a database and user, and remote access over TLS. The install and configuration path was run on Ubuntu 26.04, Ubuntu 24.04 and Debian 13 against Percona Server for MySQL 8.4.10-10, and the repository, package and version details were re-checked against Percona’s live indexes in August 2026.

Which Percona Server for MySQL release to install

Install the 8.4 LTS line. It is the mature line, it maps to Oracle’s MySQL 8.4 LTS, and 9.7 LTS is days old with reorganised packaging, which is not what you want under a database you have to run.

One trap if you do go looking at 9.7: percona-release setup ps-97-lts passes validation, disables every other Percona repository, then enables nothing, because the helper has no alias mapping for it. Use percona-release enable ps-97-lts instead.

Line	Status	Repository component	What it means for you
8.4 LTS	Active	ps-84-lts	Install this. Quarterly releases, current binaries for Ubuntu and Debian.
8.0	End of life	ps-80	Final community release was 8.0.46-37 on 10 June 2026. Of the three bases here, only noble still carries 8.0 server binaries, so that is the one place you can install it by accident. trixie publishes just percona-mysql-shell, and the resolute index is empty, so enabling it there succeeds and installs nothing. Do not use it.
5.7	End of life	none for current releases	Dead since October 2023. The ps-57 path returns 404 for Ubuntu 24.04 and newer. Paid post-EOL support only.
9.7 LTS	Released	ps-97-lts	First build is 9.7.1-1, dated 5 August 2026. Days old, and its apt packaging was split into new components. Percona skipped Innovation releases 9.0 through 9.6 entirely.

That last row is the part people miss. Percona publishes nothing between 9.0 and 9.6, so the upgrade path from 8.4 skips straight to 9.7 rather than a series of small hops. Plan capacity and support windows around that.

The 8.0.46-37 release note is the marker for the 8.0 line closing. If you are running 8.0 today, an in-place upgrade to 8.4 is the work item, not a fresh install.

One honest caveat before you add a third-party repository. Ubuntu 26.04 carries mysql-server at 8.4.10 in its own archive, the same upstream release Percona builds against. If all you want is MySQL at a current version, apt install mysql-server gets you there with no extra repository. Percona’s build earns its place when you want XtraDB, the per-table and per-index counters, the thread pool, or binary compatibility with XtraBackup and Percona Toolkit.

What you need first

A server running Ubuntu 26.04, Ubuntu 24.04 or Debian 13, a user with sudo, and outbound access to repo.percona.com. Note percona-release writes an http:// URL into the list file, so an egress policy that allows only 443 breaks apt update. Percona also publishes packages for Ubuntu 22.04 and Debian 12 in the same repository if you are stuck on an older base.

Sizing is driven by your working set, not by a fixed number. InnoDB wants its buffer pool around 70% of RAM on a dedicated database host, so start from the size of the data you actually read: a 10 GB hot working set means 16 GB of RAM as a realistic floor, and busy OLTP boxes commonly land between 16 GB and 64 GB. Disk is your dataset plus binary logs plus redo plus roughly 30% headroom, on storage that does fsync quickly, because commit latency is the number that shows up in application timings. CPU matters less than most people expect until concurrency climbs past a couple of hundred active connections.

The three test machines here ran 2 vCPU, 4 GB RAM and a 20 GB disk. That is a floor for following along, not a production recommendation.

If you want the stock upstream packages instead, the MySQL Community Server install on Ubuntu and Debian covers that path. On the RHEL side, see Percona MySQL Server on CentOS and RHEL, where the package names and config layout differ.

Add the Percona repository

Percona distributes a small helper package that manages repository definitions for every product it ships. Grab it along with the three packages it needs:

sudo apt update
sudo apt install -y curl gnupg2 lsb-release
curl -O https://repo.percona.com/apt/percona-release_latest.generic_all.deb

The download is a single generic deb that works across both distributions:

sudo apt install -y ./percona-release_latest.generic_all.deb

Installing it enables two repositories immediately (prel for the helper itself and telemetry) but no product repository. You pick that next:

sudo percona-release setup ps-84-lts

setup disables every other Percona repository before enabling the one you named, which is what keeps an old 8.0 definition from silently winning the version comparison:

* Disabling all Percona Repositories
* Enabling the Percona Server for MySQL - PS 8.4- repository
Fetched 27.2 kB in 2s (17.1 kB/s)

The generated list file is managed, so do not hand-edit it. Confirm the codename matched your release:

cat /etc/apt/sources.list.d/percona-ps-84-lts-release.list

On Ubuntu 26.04 the codename resolves to resolute, on 24.04 to noble, and on Debian 13 to trixie:

#
# This repo is managed by "percona-release" utility, do not edit!
#
deb [signed-by=/usr/share/keyrings/percona-keyring.gpg] http://repo.percona.com/ps-84-lts/apt resolute main
deb-src [signed-by=/usr/share/keyrings/percona-keyring.gpg] http://repo.percona.com/ps-84-lts/apt resolute main

One difference worth noticing before you install. The number of published point releases is not the same on every base:

apt-cache policy percona-server-server

Ubuntu 24.04 carries five versions back to 8.4.5, Debian 13 carries three, and Ubuntu 26.04 carries exactly one because Percona only started building for resolute recently. If you pin versions in configuration management, check this before you write the pin.

percona-server-server:
  Installed: (none)
  Candidate: 8.4.10-10-1.resolute
  Version table:
     8.4.10-10-1.resolute 500
        500 http://repo.percona.com/ps-84-lts/apt resolute/main amd64 Packages

What the tools repository actually contains

Plenty of guides tell you to run percona-release enable tools release as a matter of course. It is worth knowing what that gets you, because the answer depends entirely on which distribution you are running.

sudo percona-release enable tools release
sudo apt update

enable adds a repository without touching the others, unlike setup. Here is what was actually published in that repository when this was tested:

Package	Ubuntu 24.04 (noble)	Debian 13 (trixie)	Ubuntu 26.04 (resolute)
percona-toolkit	3.6.0	not published	not published
percona-xtrabackup-84	8.4.0-2	not published	not published
percona-xtrabackup-80	8.0.35-31	not published	not published
pmm2-client	2.42.0	not published	not published
proxysql2	2.6.3	not published	not published
percona-backup-mongodb	2.7.0	not published	not published
libdbd-mysql-perl	5.013-3	5.013-3	not published

The Ubuntu 26.04 column is not a typo. The resolute directory exists and returns HTTP 200, and its Packages index is zero bytes. Enabling the tools repository on 26.04 succeeds and gives you nothing at all. Debian 13 gets one Perl library. Read that table as a statement about the tools component only, because most of those products still ship for these codenames from their own components.

Backups are where that bites, and the fix is a different component rather than a different operating system. XtraBackup is how you take hot physical backups of a running InnoDB dataset, and it publishes from pxb-84-lts, which carries percona-xtrabackup-84 at 8.4.0-6 for resolute and trixie as well as noble. Use enable rather than setup so the server repository stays active:

sudo percona-release enable pxb-84-lts
sudo apt update
sudo apt install -y percona-xtrabackup-84

Check the binary answers before trusting a backup schedule to it:

xtrabackup --version

The version must match the server’s major line. An 8.0 XtraBackup cannot back up an 8.4 datadir.

Percona Toolkit is the same story. Its own pt component carries 3.7.1-4 for all three codenames, which beats the 3.7.1-2 in Ubuntu 26.04’s archive and is five minor series ahead of the 3.2.1 that Debian 13 ships:

sudo percona-release enable pt release
sudo apt update
sudo apt install -y percona-toolkit

The Percona Toolkit walkthrough covers what the toolkit is for once you have it.

Install Percona Server for MySQL

One package pulls the server, the client and the shared config:

sudo apt install -y percona-server-server

Ten packages land on Ubuntu 26.04, eleven on 24.04, and sixteen on Debian 13 because Debian’s minimal cloud image has no Perl. Download size is about 161 MB on Ubuntu and 169 MB on Debian, expanding to 527 MB and 578 MB on disk respectively. Note the dependency list includes percona-telemetry-agent, which is covered further down.

The service starts and enables itself, no systemctl enable --now needed:

systemctl status mysql --no-pager

The unit is called mysql, not percona-server, and the description confirms which build is running:

● mysql.service - Percona Server
     Loaded: loaded (/usr/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-07-31 11:11:26 UTC; 4s ago
    Process: 25310 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
   Main PID: 25357 (mysqld)
     Status: "Server is operational"
      Tasks: 36 (limit: 3522)
     Memory: 541.3M (peak: 556M)

Check what the defaults actually are

Log in over the socket. On Ubuntu and Debian the root account authenticates with auth_socket, so sudo is the credential and there is no temporary password in the log:

sudo mysql -e "SELECT VERSION(), @@version_comment;"

The revision string is the fastest way to prove you got Percona’s build rather than the distribution’s MySQL:

VERSION()	@@version_comment
8.4.10-10	Percona Server (GPL), Release '10', Revision 'd76e81f4'

Version, service state, listening address and engine in one place on the 26.04 box:

Now the four defaults that surprise people. Ask the server directly:

sudo mysql -e "SELECT @@bind_address, @@innodb_buffer_pool_size/1024/1024 AS pool_mb, @@max_connections;"
sudo mysql -e "SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME LIKE '%password%';"
sudo mysql -e "SELECT * FROM mysql.component;"

Read those three results together and the picture is clear:

@@bind_address	pool_mb	@@max_connections
*	128.00000000	151

PLUGIN_NAME	PLUGIN_STATUS
sha256_password	ACTIVE
caching_sha2_password	ACTIVE
mysql_native_password	DISABLED

component_id	component_group_id	component_urn
1	1	file://component_percona_telemetry

bind_address is *, which means the server listens on every interface the moment it starts. That is a real difference from the distribution packages: Ubuntu’s own mysql-server sets bind-address = 127.0.0.1 in /etc/mysql/mysql.conf.d/mysqld.cnf and mariadb-server sets the same in 50-server.cnf. Percona ships no such line. If the machine has a public address, mysqld is answering on it right now. There is a second listener too: the X Plugin binds 33060 on every interface by default and is governed by its own variable. Firewall before you do anything else.

The buffer pool is 128 MB regardless of how much RAM the box has, mysql_native_password is compiled in but disabled, and password validation is not installed. Only the telemetry component is loaded.

TLS is the pleasant surprise. Percona generates a certificate authority and a server certificate at first start, so encrypted connections work with no configuration:

sudo mysql -e "SELECT @@ssl_ca, @@ssl_cert, @@ssl_key; SHOW VARIABLES LIKE 'tls_version';"

Those are self-signed, so they authenticate nothing, but they do encrypt the wire:

@@ssl_ca	@@ssl_cert	@@ssl_key
ca.pem	server-cert.pem	server-key.pem
Variable_name	Value
tls_version	TLSv1.2,TLSv1.3

Secure the install

mysql_secure_installation ships with the package and still works, but on a fresh 8.4 install it has very little left to do: there is no anonymous user, no test database, and root is already socket-authenticated. The one thing worth taking from it is the password policy component, which you can install directly:

sudo mysql -e "INSTALL COMPONENT 'file://component_validate_password';"
sudo mysql -e "SHOW VARIABLES LIKE 'validate_password%';"

It defaults to a MEDIUM policy, eight characters, with mixed case, a digit and a symbol required. It defaults to a MEDIUM policy, eight characters, with mixed case, a digit and a symbol required:

Variable_name	Value
validate_password.changed_characters_percentage	0
validate_password.check_user_name	ON
validate_password.dictionary_file	
validate_password.length	8
validate_password.mixed_case_count	1
validate_password.number_count	1
validate_password.policy	MEDIUM
validate_password.special_char_count	1

Anything weaker now gets rejected at CREATE USER time with ERROR 1819 (HY000): Your password does not satisfy the current policy requirements, which is the behaviour you want on a shared server.

Error: “ERROR 1698 (28000): Access denied for user ‘root’@’localhost'”

This one catches almost everybody, and the reason is that the command that causes it reports success. Setting a root password the obvious way does nothing:

sudo mysql -e "ALTER USER 'root'@'localhost' IDENTIFIED BY 'Str0ng#Root2026';"
sudo mysql -e "SELECT user, host, plugin, LENGTH(authentication_string) AS pw_len FROM mysql.user WHERE user='root';"

No error is printed, and yet the plugin is unchanged and the stored password is zero bytes long. IDENTIFIED BY without a plugin keeps whatever plugin the account already has, and auth_socket has nowhere to put a password:

user	host	plugin	pw_len
root	localhost	auth_socket	0

So the login you expect to work fails, over the socket and over TCP alike:

ERROR 1698 (28000): Access denied for user 'root'@'localhost'

The whole sequence in one terminal, from the ALTER that reports nothing wrong through to the login that fails:

The fix is to name the plugin explicitly:

sudo mysql -e "ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'Str0ng#Root2026';"

Now mysql -u root -p works. Understand the trade you just made, though: sudo mysql stops being passwordless and starts returning ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO), which breaks maintenance scripts that relied on socket auth. Unless something genuinely needs to log in as root over the network, leave root on auth_socket and give applications their own accounts. To go back:

mysql -u root -p -e "ALTER USER 'root'@'localhost' IDENTIFIED WITH auth_socket;"

Error: “ERROR 1524 (HY000): Plugin ‘mysql_native_password’ is not loaded”

Old application stacks that ask for the legacy authentication plugin hit this on 8.4:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

The plugin is still in the binary, it is just not loaded at startup any more. Upgrading the client library is the correct answer, since caching_sha2_password has been the default since MySQL 8.0 and every current connector speaks it. If you truly cannot, open the server config:

sudo vim /etc/mysql/mysql.conf.d/99-legacy-auth.cnf

Add the load directive, then restart the service:

[mysqld]
mysql_native_password = ON

Treat that as a migration deadline rather than a setting. The plugin was removed outright in the 9.x line, which is where the upgrade path from 8.4 leads.

Create a database and an application user

Put the values you will reuse into shell variables so you edit one block instead of hunting through the rest of the guide:

export DB_NAME="shopdb"
export DB_USER="shopuser"
export DB_PASS="Str0ng#Shop2026"

Those live only in the current shell, so re-export them if you reconnect. Create the database and the account:

sudo mysql -e "CREATE DATABASE ${DB_NAME} CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;"
sudo mysql -e "CREATE USER '${DB_USER}'@'%' IDENTIFIED BY '${DB_PASS}';"
sudo mysql -e "GRANT ALL PRIVILEGES ON ${DB_NAME}.* TO '${DB_USER}'@'%';"

Check what the new account actually got:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user WHERE user = '${DB_USER}';"

New accounts pick up caching_sha2_password without you asking:

user	host	plugin
shopuser	%	caching_sha2_password

Give it a table and some rows so there is something real to query:

sudo mysql "${DB_NAME}" -e "CREATE TABLE orders (id INT AUTO_INCREMENT PRIMARY KEY, item VARCHAR(60) NOT NULL, qty INT NOT NULL, placed TIMESTAMP DEFAULT CURRENT_TIMESTAMP) ENGINE=InnoDB;"
sudo mysql "${DB_NAME}" -e "INSERT INTO orders (item, qty) VALUES ('widget',3),('sprocket',12),('flange',1);"
sudo mysql "${DB_NAME}" -e "SELECT * FROM orders;"

Three rows back means the engine, the grant and the charset all agree:

id	item	qty	placed
1	widget	3	2026-07-31 11:11:02
2	sprocket	12	2026-07-31 11:11:02
3	flange	1	2026-07-31 11:11:02

If you would rather drive this from a GUI than the shell, DBeaver on Ubuntu and Debian connects to it over the same credentials, and there is a broader survey of CLI and GUI tools for managing MySQL.

Open the port and connect from another host

The server is already listening on all interfaces, so the only thing standing between it and the network is the firewall. Allow SSH first. Enabling UFW with a single database rule and no SSH rule locks you out of the machine, which is exactly what happened on one of the test servers while writing this:

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow from 10.0.1.0/24 to any port 3306 proto tcp
sudo ufw --force enable

Scope the database rule to the subnet that needs it, because a bare ufw allow 3306 publishes the server to the internet. Verify what actually got installed:

sudo ufw status verbose

The listing should report Status: active, a default of deny (incoming), an OpenSSH rule, and 3306 restricted to the subnet you named. If 3306 shows Anywhere as its source, the from clause was dropped and the server is published to everything that can route to it.

From a second machine, connect as the application user. Two things differ on that host: it needs a MySQL client and Percona’s repository to get one, and the variables exported earlier live only on the database server. Skip MYSQL_PWD as well. MySQL’s own manual calls it extremely insecure, because some versions of ps expose the environment of a running process, and 8.4 deprecates it. A login path stores the credential in a 0600 file instead, obfuscated rather than encrypted, which stops shoulder surfing and shell history but not somebody who already has your account:

sudo apt update
sudo apt install -y curl
curl -fsSL -O https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo apt install -y ./percona-release_latest.generic_all.deb
sudo percona-release setup ps-84-lts
sudo apt install -y percona-server-client libperconaserverclient24-dev
mysql_config_editor set --login-path=shop --host=10.0.1.50 --user=shopuser --password
mysql --login-path=shop shopdb -e "SHOW SESSION STATUS LIKE 'Ssl_version'; SELECT COUNT(*) FROM orders;"

The dev package is not optional here. mysql_config_editor does not ship in percona-server-client; it lives in libperconaserverclient24-dev. Ubuntu’s own client carries it too, as mysql-client-core on 26.04 and mysql-client-core-8.0 on 24.04, but you cannot have both: Ubuntu’s package conflicts with virtual-mysql-client-core, which Percona’s client provides, so apt resolves it by removing Ubuntu’s client rather than co-installing. On a host already running Ubuntu’s mysql-server that removal cascades, because the server depends on the client, so read the apt plan before confirming it. Debian 13 has no archive package containing it at all, so on Debian the Percona dev package is the only route.

This is the part worth pausing on. Nothing about TLS was configured anywhere in this guide, and the cross-host session is still encrypted:

Variable_name	Value
Ssl_version	TLSv1.3
COUNT(*)
3

The same session from the client side, querying the table across the network:

The cipher negotiated in testing was TLS_AES_128_GCM_SHA256. Traffic is not in the clear by default the way it was on older releases. What you do not get is identity: the certificate is self-signed by a CA the server generated for itself, so tightening the client to --ssl-mode=VERIFY_CA without also handing it that CA file fails immediately.

ERROR 2026 (HY000): SSL connection error: CA certificate is required if ssl-mode is VERIFY_CA or VERIFY_IDENTITY

Copy /var/lib/mysql/ca.pem to the client and pass it with --ssl-ca to make verification work, or replace the generated pair with certificates from your own CA. In the meantime --ssl-mode=REQUIRED gets you encryption without verification, which is what the connection above was already doing.

What Percona Server adds over MySQL Community

The storage engine identifies itself differently, which is the visible tip of it:

sudo mysql -e "SHOW ENGINES;"

InnoDB reports as Percona-XtraDB, an enhanced fork with different scalability patching:

Engine	Support	Comment	Transactions	XA	Savepoints
InnoDB	DEFAULT	Percona-XtraDB, Supports transactions, row-level locking, and foreign keys	YES	YES	YES

The feature most worth turning on is per-object statistics, which upstream has no equivalent for. It is off by default:

sudo mysql -e "SET GLOBAL userstat = ON;"
sudo mysql -e "SELECT TABLE_SCHEMA, TABLE_NAME, ROWS_READ, ROWS_CHANGED FROM information_schema.TABLE_STATISTICS;"

You get read and write counters per table, which answers “which table is this workload actually hammering” without sampling the process list. SET GLOBAL does not persist, so add userstat = ON to the tuning file if you want the counters to survive the restart later in this guide:

TABLE_SCHEMA	TABLE_NAME	ROWS_READ	ROWS_CHANGED
shopdb	orders	3	0
mysql	columns	6	0
mysql	indexes	1	0

The same switch populates INDEX_STATISTICS, which is how you find indexes nothing reads before you drop them. There is also a component of hash functions borrowed from Percona Toolkit, installed on demand:

sudo mysql -e "INSTALL COMPONENT 'file://component_percona_udf';"
sudo mysql -e "SELECT fnv1a_64('computingforgeeks') AS fnv1a, murmur_hash('computingforgeeks') AS murmur;"

Those are used for checksumming rows during comparison and replication drift checks:

fnv1a	murmur
-8628345243952482491	3174512499296359451

A thread pool scheduler is compiled in as well, though thread_handling stays at one-thread-per-connection until you change it. It only pays off under high connection counts, so measure before switching.

None of this makes a single server highly available. When one box stops being enough, the same packages build out into a Percona XtraDB Cluster behind ProxySQL, and the Prometheus and Grafana monitoring setup works against a standalone server too.

Ubuntu and Debian differences worth knowing

The install path is genuinely the same on all three bases, which is not something you can say about the RHEL family. These are the differences that showed up in testing:

Item	Ubuntu 26.04	Ubuntu 24.04	Debian 13
Repo codename	resolute	noble	trixie
Point releases available	1	5	3
Packages installed	10	11	16 (pulls Perl)
Tools repo contents	empty	full set	one Perl library
AppArmor profile	loaded, complain mode	loaded, complain mode	loaded, complain mode
Config entry point	/etc/mysql/my.cnf with !includedir for conf.d and mysql.conf.d
Socket	/var/run/mysqld/mysqld.sock
Error log	/var/log/mysql/error.log

The AppArmor row deserves a note. The install puts a profile at /etc/apparmor.d/usr.sbin.mysqld and it loads, but the head of the profile reads /usr/sbin/mysqld flags=(complain), so it logs policy violations rather than blocking them. Confirm on the running process with sudo cat /proc/$(pgrep -x mysqld)/attr/current, which prints /usr/sbin/mysqld (complain). The sudo is required, since reading that file for a mysql owned process is denied to an unprivileged user. If you move the data directory, you will not be stopped by AppArmor, but you will find entries in the audit log. That is the opposite of the SELinux behaviour on Rocky Linux and AlmaLinux, where the policy is enforcing and ports need labelling.

Three defaults worth changing on day one

The buffer pool. 128 MB is a laptop setting. On a dedicated database host it should be roughly 70% of RAM, which on a 16 GB box means about 11 GB. This single value moves more performance than every other tuning knob combined, because it decides whether your hot data is served from memory or from disk.

sudo vim /etc/mysql/mysql.conf.d/99-tuning.cnf

Size the redo log alongside it, since a small redo capacity forces constant flushing on write-heavy workloads. Scale the pool value to your own host: the 11G below assumes 16 GB of RAM, and mysqld refuses to start if the pool exceeds what the machine has, which includes the 4 GB test boxes named earlier. On a host with generous swap or memory overcommit enabled it starts instead and gets OOM killed later, which is harder to diagnose:

[mysqld]
innodb_buffer_pool_size = 11G
innodb_redo_log_capacity = 2G
max_connections = 300

The listening address. If nothing external connects to this server, pin it to loopback rather than relying on the firewall alone. This is mutually exclusive with the remote access built earlier, so pick one. Two variables are involved and setting only the first is the usual mistake: bind-address governs the classic protocol on 3306, while the X Plugin listens separately on 33060 and defaults to every interface. Open the same file:

sudo vim /etc/mysql/mysql.conf.d/99-tuning.cnf

Add both lines under the existing [mysqld] group, not just the first:

bind-address = 127.0.0.1
mysqlx-bind-address = 127.0.0.1

Neither variable is dynamic, so both only take effect at the next start. After the restart further down, confirm with sudo ss -tlnp | grep -E ':(3306|33060)\s' that both lines show 127.0.0.1. A value of * or 0.0.0.0 means the listener is still on every interface. If nothing uses the X Protocol, mysqlx = OFF removes the listener altogether.

Telemetry. The install pulls in percona-telemetry-agent, which is enabled and running. It reads from /usr/local/percona/telemetry/ and posts to https://check.percona.com/v1/telemetry/GenericReport once every 86400 seconds. Percona documents what it collects, and on an air-gapped or regulated host you will want it gone regardless. Uninstalling the component alone is not enough, because a later restart reloads it, so set the server option first. Add this under [mysqld] in the same tuning file:

percona_telemetry_disable = 1

Then restart, drop the component and stop the agent:

sudo systemctl restart mysql
sudo mysql -e "UNINSTALL COMPONENT 'file://component_percona_telemetry';"
sudo systemctl disable --now percona-telemetry-agent
sudo mysql -e "SHOW GLOBAL VARIABLES LIKE 'percona_telemetry_disable';"

Restart once more, which is harmless if you already restarted for telemetry, then confirm the new values took. Both bind variables report * unless you added the loopback lines above. If you set mysqlx = OFF instead, the whole statement fails with ERROR 1193 (HY000): Unknown system variable 'mysqlx_bind_address', so drop that column in that case:

sudo systemctl restart mysql
sudo mysql -e "SELECT @@innodb_buffer_pool_size/1024/1024/1024 AS pool_gb, @@bind_address, @@mysqlx_bind_address;"

Those three edits take about two minutes and cover the gap between a package that starts successfully and a database you would put an application behind.