By Greg Nowak. Updated 17 October 2026.
A request to “install MySQL 5.6” deserves a conversation before anyone opens a terminal. Does the application require that release, or is someone following an old deployment document?
For a business owner, operations lead or agency, the difference affects maintenance costs, security updates and future hosting choices. A useful installation plan answers three questions: which release the application supports, how patches will reach it, and who owns the next upgrade.
Choose a release series before an exact version
Start by separating a release series, such as MySQL 8.4 LTS, from a particular package build within it. Most production requirements should specify a compatible series and allow tested maintenance updates.
My recommendation for a typical business application is the newest LTS series supported by its application, connectors and hosting platform. Oracle describes LTS as the stable-feature option; Innovation releases introduce more frequent changes and require a faster testing and upgrade cadence. Both are production-grade, according to its release model documentation.
| Your situation | Starting point | Evidence to keep |
|---|---|---|
| New production application | Newest compatible LTS series | Application and connector compatibility |
| Vendor specifies a release | Vendor-certified series or build | Certification reference and review date |
| Reproducing a defect | Exact build in an isolated environment | Package list and reproduction steps |
| Legacy 5.6 or 5.7 dependency | Dependency investigation and migration plan | Named owner and exception deadline |
| New features are essential | Innovation track | Test coverage and upgrade schedule |
Oracle now documents calendar versions such as 26.7.0. The number alone does not identify an LTS release or prove upgrade compatibility. Its APT download page lists 9.7 LTS and 8.4 LTS alongside Innovation and older series; repository availability alone is insufficient evidence for a production choice.
Install through Oracle's APT repository deliberately
If Ubuntu's native package meets the requirement, an additional repository may be unnecessary. If you need Oracle's packages, first confirm support for your Ubuntu release and architecture.
For a fresh server, download the repository configuration package from Oracle and verify its published signature. Replace the placeholder filename below with your downloaded file, then select the required server series in the configuration dialogue:
sudo dpkg -i /path/to/mysql-apt-config_VERSION_all.deb
sudo apt-get update
apt-cache policy mysql-server mysql-community-server
sudo apt-get -s install mysql-serverCheck the candidate version, repository origin and simulated transaction. When they match the plan:
sudo apt-get install mysql-server
systemctl status mysqlOracle's APT installation guide treats existing installations separately. Enabling this repository changes package sourcing; replacing Ubuntu MySQL, direct-download packages or MariaDB requires the appropriate migration procedure. Inventory packages, configuration and data before proceeding.
To change the selected series later:
sudo dpkg-reconfigure mysql-apt-config
sudo apt-get update
apt-cache policy mysql-server mysql-community-serverThat changes what APT will offer. Complete upgrade testing before installing the new candidate, and schedule downtime: Oracle's guide states that APT updates restart MySQL.
Install an exact build only when the requirement needs it
An exact version is useful for reproducing a bug or satisfying a documented certification. First inspect the builds available from your configured repositories:
apt-cache policy mysql-community-server
apt-cache madison mysql-community-serverAPT accepts package=version. Replace VERSION_FROM_APT with the complete version string, including its packaging suffix. Simulate the proposed selection first:
sudo apt-get -s install mysql-community-server='VERSION_FROM_APT'MySQL uses several related packages. Review every proposed server, client, common-file and library change. If other components also need explicit versions, include their package=version selections in the same transaction and simulate it again. Execute the reviewed command without -s only when the complete package set is consistent.
The APT command reference documents version selection and simulation. It also warns that version selection can downgrade packages. A successful dependency calculation does not establish that an existing MySQL data directory can be downgraded safely.
Selecting a version for one installation does not freeze future updates. A persistent APT preference or package hold is a separate decision. If you need one, record the affected packages, reason, owner and removal date. Include a route for applying security fixes while the exception remains open.
Give legacy databases an upgrade route
For a 5.6 or 5.7 requirement, ask for the actual blocker: a plugin, authentication method, SQL behaviour, connector or vendor support condition. Budget for resolving that dependency alongside the database work.
Oracle's supported upgrade paths require 5.7 to pass through 8.0 before 8.4. A 5.6 installation needs the preceding 5.7 step too. Calendar-versioned releases add compatibility rules; do not infer a valid jump from a higher number.
Run MySQL Shell's Upgrade Checker for the intended target, rehearse with representative data, and agree a recovery method. Reinstalling yesterday's packages should never be the entire rollback plan.
Finish with application and recovery checks
Check both the installed client and the running server:
mysql --version
mysql -u root -p -NBe 'SELECT VERSION();'
systemctl is-active mysql
dpkg-query -W 'mysql*'The SQL command prompts for the database password. If the administrator account uses socket authentication, use sudo mysql -NBe 'SELECT VERSION();' instead. Review package status as well as version numbers; package records can remain after removal.
Then test the workflows that matter: sign-in, writes, background jobs, reports and integrations. Inspect error logs, confirm monitoring and restore a backup into a separate environment. Record the restore time against the downtime the business can tolerate.
Leave a short handover covering the chosen series, package source, patching process, backup location and next review. Agency teams should make the ongoing maintenance owner explicit before launch.
If an inherited database or conflicting vendor requirements are holding up delivery, talk to Greg about an installation or migration plan. Bring the current versions and application requirements so the work can start with a clear scope.
Related on GrN.dk
- WordPress Supports Old PHP; Your Production Server Shouldn’t
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- MySQL Zero-Date Import Errors: A Safer Fix for Legacy Data
Need help with this kind of work?
Discuss your MySQL installation or migration with Greg Get in touch with Greg.