[{"data":1,"prerenderedAt":205},["ShallowReactive",2],{"seo-verification":3,"blog-mysql-8-0-end-of-life-migration-vps-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-mysql-8-0-end-of-life-migration-vps-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":148,"ctaBody":149,"ctaButton":150,"ctaUrl":151,"relatedPosts":152},464,"mysql-8-0-end-of-life-migration-vps",{"fr":12,"en":10,"ar":13,"es":14},"mysql-8-0-eol-migration-vps","mysql-8-0-انتهاء-الدعم-ترقية-vps","mysql-8-0-fin-de-soporte-migracion-vps","MySQL 8.0 to 8.4 LTS migration on a VPS: step-by-step guide","MySQL 8.0 EOL April 30, 2026: no more security patches. Migrate to MySQL 8.4 LTS — breaking changes, pre-checks, in-place upgrade and when to pick MariaDB 11.x.",10,0,false,"2026-10-17T00:00:00+00:00","2026-10-18T21:57:56+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Databases","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmysql-8-0-eol-migration-vps-poster.svg","On April 30, 2026, Oracle officially ended support for MySQL 8.0: no more security patches will be released for this branch. Every CVE identified against MySQL 8.0 remains permanently open on your server. MySQL 8.4, the first LTS release in the MySQL 8 series, takes over with guaranteed support through April 2032. This guide covers the incompatibilities to know, the checks to perform before the switch, the in-place upgrade procedure on a Linux VPS, and the concrete cases where MariaDB 11.x is a better fit.",[35,39,42,45,55,58,64,95,98,100,102,105,136,138,145],{"type":36,"title":37,"body":38},"h2","Why migrate now: EOL and CVE exposure","The official end-of-life date for MySQL 8.0 is April 30, 2026, per the Oracle Lifetime Support calendar (oracle.com\u002Fsupport\u002Flifetime-support\u002F). From that date, Oracle no longer publishes security patches for the 8.0.x branch, regardless of a CVE's severity. Servers remaining on 8.0 accumulate a security debt that grows with every quarterly Oracle CPU (Critical Patch Update) — without ever being addressed.",{"type":40,"body":41},"p","MySQL 8.4 is the first version designated LTS in MySQL's history. Oracle guarantees its support through April 2032 (dev.mysql.com\u002Fdoc\u002Frelnotes\u002Fmysql\u002F8.4\u002F). Unlike the innovation branches 8.1, 8.2 and 8.3 — released between 2023 and 2024 without extended support — version 8.4 receives security patches and stability fixes over the long term. For a production database on a VPS, it is the only MySQL branch that offers a credible planning horizon.",{"type":36,"title":43,"body":44},"Breaking changes to know before upgrading","—",{"type":46,"items":47},"ul",[48,49,50,51,52,53,54],"**`mysql_native_password` removed**: the `mysql_native_password` authentication plugin is permanently removed in MySQL 8.4 (it was only deprecated in 8.0). Any user account relying on this plugin will fail to connect immediately after the upgrade. PHP applications older than PHP 8.1, WordPress without PDO configured properly, and legacy JDBC clients are the most common cases. The replacement is `caching_sha2_password`, the default since MySQL 8.0 but bypassed by many legacy configurations.","**`authentication_policy` parameter change**: the default becomes `caching_sha2_password`, and any `default_authentication_plugin` line in `my.cnf` is now silently ignored. If your `my.cnf` still defines this parameter, replace it with `authentication_policy`.","**Removal of `innodb_file_format` and related options**: the `innodb_file_format` variable is removed. Tables created with `ROW_FORMAT=COMPRESSED` still work, but any attempt to set `innodb_file_format` at runtime produces an error. Verify that your DDL scripts no longer reference this variable.","**JSON type changes**: MySQL 8.4 strengthens JSON\u002FSQL conformance. Functions like `JSON_TABLE()` and `JSON_VALUE()`, and JSON paths with malformed Unicode characters, may behave differently. Validate tables with large JSON columns in a test environment before switching to production.","**Charset and collation**: `utf8mb4` and `utf8mb4_0900_ai_ci` remain the defaults, but MySQL 8.4 more strictly rejects columns declared as `utf8` (alias for `utf8mb3`). A collation migration may be required for historical databases created under MySQL 5.7.","**Removed or renamed system variables**: several variables present in 8.0 and marked deprecated are removed in 8.4 — notably `innodb_undo_tablespaces`, `slave_*` (replaced by `replica_*`), and `query_cache_*` (the query cache was removed in 8.0). A `mysqlcheck` run reports relevant warnings.","**Replication**: replication-related variable names have definitively switched to `source`\u002F`replica` terminology. Any script or monitoring tool still calling `SHOW SLAVE STATUS` must be updated to `SHOW REPLICA STATUS`.",{"type":36,"title":56,"body":57},"Prerequisites before starting","A database engine migration in production cannot be improvised. Three conditions must be met before starting anything: a verified backup, exact knowledge of your current version, and an application compatibility check.",{"type":46,"items":59},[60,61,62,63],"**Complete and verified backup**: run `mysqldump --all-databases --single-transaction --routines --events > backup_pre_migration.sql` and verify the file is readable (consistent size, no `ERROR` message at the end of the file). An unverified backup is not a backup.","**Current version and table engines**: run `SELECT VERSION(); SHOW VARIABLES LIKE 'innodb_version';` and list non-InnoDB tables with `SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine != 'InnoDB' AND table_schema NOT IN ('information_schema','performance_schema','mysql','sys');`. Any MyISAM or MEMORY table must be evaluated before the upgrade.","**Application compatibility**: identify the authentication plugin for each account with `SELECT user, host, plugin FROM mysql.user;`. Any user on `mysql_native_password` must be migrated to `caching_sha2_password` before or during the upgrade.","**Available disk space**: an in-place upgrade on Debian\u002FUbuntu may temporarily double the space used by ibdata files. Verify at least 20% free space on the `\u002Fvar` partition.",{"type":65,"title":66,"steps":67},"steps","MySQL 8.0 → 8.4 LTS migration procedure on a VPS",[68,71,74,77,80,83,86,89,92],{"title":69,"body":70},"Full backup with verification","Run `mysqldump --all-databases --single-transaction --routines --events --triggers > \u002Froot\u002Fbackup_mysql80_$(date +%Y%m%d).sql`. Verify the end of the file with `tail -5 \u002Froot\u002Fbackup_mysql80_*.sql`: the last line should be `-- Dump completed on …`. Store this file off the VPS (S3 object storage, NFS, local copy) before proceeding.",{"title":72,"body":73},"Audit accounts and authentication plugins","Run `SELECT user, host, plugin FROM mysql.user ORDER BY plugin;`. For each user on `mysql_native_password`, execute `ALTER USER 'name'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';`. Update the connection string of each affected application (PHP DSN, Laravel `.env`, WordPress configuration) before the upgrade.",{"title":75,"body":76},"Check deprecated variables in my.cnf","Open `\u002Fetc\u002Fmysql\u002Fmysql.conf.d\u002Fmysqld.cnf` (or `\u002Fetc\u002Fmy.cnf` depending on your distribution) and remove or replace: `default_authentication_plugin` → `authentication_policy = caching_sha2_password`, `slave_*` → `replica_*`, `innodb_undo_tablespaces`, `query_cache_size`, `query_cache_type`. Any unknown variable blocks MySQL 8.4 from starting.",{"title":78,"body":79},"Clean service stop and snapshot","On a Proxmox or KVM VPS, take a snapshot before touching packages: use your control panel or your hosting provider's API. Then: `systemctl stop mysql` and verify the service is stopped with `systemctl status mysql`.",{"title":81,"body":82},"Add the MySQL 8.4 repository and update packages","On Debian 12 \u002F Ubuntu 22.04: download the MySQL repository configuration package from `dev.mysql.com\u002Fdownloads\u002Frepo\u002Fapt\u002F` (select the `.deb` for your distribution), install it with `dpkg -i mysql-apt-config_*.deb`, select MySQL 8.4 LTS in the menu, then run `apt-get update && apt-get install mysql-server`. The package manager replaces the 8.0 binary with the 8.4 binary and automatically upgrades MySQL system files.",{"title":84,"body":85},"Upgrade system tables","On first startup of MySQL 8.4, the engine updates system tables automatically. Check the logs: `journalctl -u mysql -n 50 | grep -i 'upgrade\\|error'`. If the automatic upgrade did not run (rare with some distributions), run manually `mysql_upgrade --user=root --password`.",{"title":87,"body":88},"Post-upgrade verification","Connect and verify the version: `SELECT VERSION();` should return `8.4.x`. Then run `mysqlcheck --all-databases --auto-repair --user=root --password` to detect any table corruption. Check the error log (`\u002Fvar\u002Flog\u002Fmysql\u002Ferror.log`) and the presence of system databases: `SHOW DATABASES;` should list `sys`, `performance_schema` and `information_schema`.",{"title":90,"body":91},"Application functional testing","Restart your application and check sensitive points: database connection, user authentication, queries on JSON columns, stored procedures. On a PHP application, temporarily enable error display or check application logs. An error `The server requested authentication method unknown to the client` means an account is still on unmigrated `mysql_native_password`.",{"title":93,"body":94},"Cleanup and monitoring activation","Delete the local backup file once the off-VPS copy is confirmed. Check your monitoring tool (Prometheus `mysqld_exporter`, Netdata, Zabbix): some metric names changed between 8.0 and 8.4, especially replication-related ones. Schedule an error log check at 24h and 72h post-migration.",{"type":36,"title":96,"body":97},"MariaDB 11.x: when to prefer this alternative","MariaDB 11.x is a MySQL fork that has diverged significantly since version 10.3. There are specific cases where MariaDB 11.x is more appropriate than upgrading to MySQL 8.4, and cases where it is not.",{"type":40,"body":99},"**Prefer MariaDB 11.x if** your application already uses MariaDB-specific features (system-versioned tables, sequences, Spider engine, native Galera Cluster); if you need a multi-master cluster without the complexity of MySQL Group Replication; or if you operate under strict license constraints and want to remain on a fork maintained by the MariaDB Foundation (LGPL). MariaDB 11.4 LTS is the current stable branch with support through 2029, and MariaDB 11.x retains `mysql_native_password` by default — simplifying migration of legacy applications.",{"type":40,"body":101},"**Prefer MySQL 8.4 LTS if** your application was developed and tested specifically against MySQL (ORMs like Laravel Eloquent or Hibernate that use MySQL-specific features); if you use MySQL Enterprise for features like the audit plugin or commercial Thread Pool; or if your hosting provider only supports MySQL-optimized backups (Percona XtraBackup). Migrating from MySQL 8.0 to MariaDB 11.x is a cross-engine migration, riskier, and beyond the scope of this guide — it warrants a dedicated procedure with full integration testing.",{"type":103,"body":104},"tip","**Rollback possible within 24 hours**: if you took a VPS snapshot before the upgrade, restoring it returns the entire server to the MySQL 8.0 state within minutes. Without a snapshot, rollback from a SQL dump is possible but slower: create a second VPS, restore the dump with `mysql \u003C backup_mysql80_*.sql`, redirect the application, then decommission the old VPS. Only delete the backup and snapshot after 72 hours of stable production on MySQL 8.4.",{"type":106,"title":107,"headers":108,"rows":113},"comparison","MySQL 8.0 vs MySQL 8.4 LTS vs MariaDB 11.x",[109,110,111,112],"Criterion","MySQL 8.0","MySQL 8.4 LTS","MariaDB 11.x",[114,119,124,128,132],[115,116,117,118],"Security support","Ended (Apr 30, 2026)","Through April 2032","Through 2029 (11.4 LTS)",[120,121,122,123],"mysql_native_password","Present (deprecated)","Removed","Present by default",[125,126,126,127],"Multi-master cluster","Group Replication","Native Galera Cluster",[129,130,130,131],"MySQL application compatibility","Native","Mostly compatible, some gaps",[133,134,134,135],"License","GPL + commercial Enterprise","LGPL (MariaDB Foundation)",{"type":36,"title":137,"body":44},"Troubleshooting: common errors after migration",{"type":46,"items":139},[140,141,142,143,144],"**`ERROR 1045 (28000): Access denied`** after upgrade: check the account's authentication plugin with `SELECT plugin FROM mysql.user WHERE user='name';`. If it is still `mysql_native_password`, the upgrade did not migrate this account — rerun `ALTER USER … IDENTIFIED WITH caching_sha2_password BY '…';`.","**`Unknown system variable 'default_authentication_plugin'`**: this variable is no longer recognized in 8.4. Remove it from `my.cnf` and replace with `authentication_policy = caching_sha2_password` if you want to enforce this globally.","**MySQL does not start after upgrade**: check `\u002Fvar\u002Flog\u002Fmysql\u002Ferror.log`. The most common error is an unknown system variable in `my.cnf`. Comment out variables one by one until the source is identified, then fix it.","**Degraded performance on sort queries**: MySQL 8.4 applies index ordering more strictly on some queries. Run `EXPLAIN` on slow queries and verify that covering indexes are still used. `ANALYZE TABLE table_name;` forces a statistics refresh.","**`performance_schema.replication_applier_status` table not found in monitoring scripts**: some `performance_schema` tables were renamed or reorganized. Update monitoring queries to use the new view names documented at `dev.mysql.com\u002Fdoc\u002Frefman\u002F8.4\u002Fen\u002Fperformance-schema.html`.",{"type":36,"title":146,"body":147},"Moving to MySQL 8.4 LTS: key takeaways","Migrating from MySQL 8.0 to MySQL 8.4 LTS is an in-place upgrade achievable in under an hour on a well-prepared VPS. The two most common failure points are the removal of `mysql_native_password` — which breaks legacy application connections if accounts are not migrated — and removed system variables in `my.cnf` that prevent the service from starting. Pre-auditing these two points reduces the risk to nearly zero. For stacks that need `mysql_native_password` or a multi-master cluster without configuration complexity, MariaDB 11.4 LTS is a credible alternative, provided the migration is treated as a separate operation with its own integration tests.","A Linux VPS for your MySQL 8.4 database","Host MySQL 8.4 LTS on a managed Linux VPS, with snapshots included to secure every migration.","View Linux VPS plans","\u002Fvps-linux",[153,172,190],{"id":154,"slug":155,"slugs":156,"title":160,"excerpt":161,"readTime":162,"views":18,"isPinned":19,"publishedAt":163,"updatedAt":164,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},57,"hosting-mysql-on-a-vps",{"fr":157,"en":155,"ar":158,"es":159},"heberger-mysql-vps","استضافة-mysql-على-خادم-vps","alojar-mysql-en-un-vps","Hosting MySQL on a VPS: complete guide","Install MySQL 8.4 LTS on a VPS: prerequisites, security hardening, InnoDB performance, secure remote access, automated backups, and troubleshooting.",9,"2026-04-24T00:00:00+00:00","2026-09-17T14:09:38+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":170,"appSlug":171},"databases","mysql-stack",{"id":173,"slug":174,"slugs":175,"title":179,"excerpt":180,"readTime":17,"views":18,"isPinned":19,"publishedAt":181,"updatedAt":182,"category":183,"categories":184,"featuredImage":30,"bgImage":31,"posterImage":186,"relatedSolution":187},146,"mariadb-on-a-vps-free-fast-controlled-sql",{"fr":176,"en":174,"ar":177,"es":178},"heberger-mariadb-vps","mariadb-على-vps-sql-حر-وسريع-وتحت-السيطرة","alojar-mariadb-en-un-vps","MariaDB on a VPS: free, fast, controlled SQL","Deploy MariaDB on a ServOrbit VPS: 1-click install, automated backups, InnoDB tuning and secure remote access.","2026-01-30T00:00:00+00:00","2026-10-07T23:07:24+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[185],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mariadb-vps-poster.svg",{"categorySlug":188,"appSlug":189},"db","mariadb-stack",{"id":191,"slug":192,"slugs":193,"title":197,"excerpt":198,"readTime":199,"views":18,"isPinned":19,"publishedAt":200,"updatedAt":21,"category":201,"categories":202,"featuredImage":30,"bgImage":31,"posterImage":204,"relatedSolution":30},461,"migrate-postgresql-from-rds-cloud-sql-supabase-to-vps",{"fr":194,"en":192,"ar":195,"es":196},"postgresql-migrer-cloud-vers-self-hosted-vps","نقل-postgresql-من-rds-و-cloud-sql-و-supabase-إلى-vps","migrar-postgresql-de-rds-cloud-sql-o-supabase-a-un-vps","Migrate PostgreSQL from RDS, Cloud SQL or a managed DB to a VPS","Step-by-step PostgreSQL migration plan from RDS, Cloud SQL and Supabase to a self-hosted VPS: exact commands, source-specific pitfalls and zero-downtime cutover.",13,"2026-10-16T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[203],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-migrer-cloud-vers-self-hosted-vps-poster.svg",1792361095172]