MySQL 8.0 atjaunināšana uz 8.4: kas salūzt un kā to izdarīt droši

MySQL 8.0 atjaunināšana uz 8.4 izskatās pēc neliela soļa: tas pats "8" nosaukumā, Oracle atbalstīta atjaunināšana uz vietas, un 8.0 jau vairs netiek atbalstīts. Testa serverī tas bieži aizņem dažas minūtes. Produkcijā problēmas rada viss, kas ir ap serveri: lietotnes konts, kas pēkšņi nevar pieslēgties, monitoringa skripts, kas izpilda SHOW SLAVE STATUS, my.cnf ar opciju, kas vairs nepastāv, un InnoDB noklusējumi, kas mainījušies zem jūsu slodzes. Neko no tā nav grūti salabot, ja to atrodat pirms atjaunināšanas.

Kāpēc tagad

Oracle beidza MySQL 8.0 atbalstu 2026. gada aprīlī, tātad Oracle tam vairs neizlaiž drošības labojumus. MySQL 8.4 ir nākamā LTS versija un dabisks mērķis lielākajai daļai produkcijas sistēmu. Ja domājat, vai lēkt uzreiz uz 9.7 LTS vai jaunajām kalendāra versijām, šo izvēli aplūko mūsu ceļvedis par MySQL versijām pēc 26.10. Šis raksts ir par to, kā tikt no 8.0 uz 8.4 bez dīkstāves.

Atbalstītie atjaunināšanas ceļi

Saskaņā ar MySQL atjaunināšanas ceļu tabulu pāreja no 8.0 laidiena uz 8.4 LTS ir atbalstīta ar trim metodēm:

• Atjaunināšana uz vietas: apturiet 8.0, uzstādiet 8.4 bināros failus uz tās pašas datu direktorijas, startējiet. Serveris pirmajā startā atjaunina datu vārdnīcu un sistēmas tabulas.
• Loģiskā izgāšana un ielāde: eksportējiet no 8.0, importējiet jaunā 8.4 serverī. Lēni lielām datubāzēm, bet iegūstat tīru jaunu instanci.
• Replikācija: izveidojiet 8.4 repliku savam 8.0 primārajam serverim, ļaujiet tai panākt un tad pārslēdzieties.

MySQL Clone ir norādīts tikai atjaunināšanai vienas sērijas ietvaros, tāpēc ar to no 8.0 uz 8.4 netikt. Replikācijas topoloģijai rokasgrāmata apraksta pakāpenisku atjaunināšanu: vispirms replikas, tad primārais serveris.

Kas salūzt: autentifikācija

Šī ir izmaiņa, kas visbiežāk pārvērš atjaunināšanu par incidentu. Sākot ar 8.4.0, novecojušais spraudnis mysql_native_password pēc noklusējuma vairs nav ieslēgts. Konti, kas to joprojām izmanto, nevar pieslēgties, kamēr tos nepārceļat uz caching_sha2_password vai neieslēdzat veco spraudni ar mysql_native_password=ON sadaļā [mysqld].

Atrodiet šos kontus 8.0 serverī pirms atjaunināšanas:

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'mysql_native_password';

Kontu pārcelšana uz caching_sha2_password ir pareizais ilgtermiņa risinājums, bet vispirms pārbaudiet katru klientu. Veci draiveri, daži ORM, BI rīki un mantotas lietotnes to var neatbalstīt vai tam vajag TLS vai RSA atslēgu apmaiņu. Īslaicīga mysql_native_password ieslēgšana ir saprātīgs veids, kā atdalīt servera atjaunināšanu no klientu darba, ja vien kādam ir atbildība par turpinājumu.

Saistīti: default_authentication_plugin ir noņemts. Tā vietā izmantojiet authentication_policy un ņemiet vērā, ka tā sintakse ir mainījusies.

Kas salūzt: noņemtās komandas un opcijas

MySQL 8.4 pabeidz atteikšanos no MASTER/SLAVE terminoloģijas. Šīs komandas tagad atgriež sintakses kļūdu:

• SHOW SLAVE STATUS → SHOW REPLICA STATUS
• START SLAVE / STOP SLAVE / RESET SLAVE → START / STOP / RESET REPLICA
• CHANGE MASTER TO → CHANGE REPLICATION SOURCE TO, un visas MASTER_* opcijas kļūst par SOURCE_*
• SHOW MASTER STATUS → SHOW BINARY LOG STATUS
• RESET MASTER → RESET BINARY LOGS AND GTIDS
• FLUSH HOSTS → TRUNCATE TABLE performance_schema.host_cache

Serveris parasti ir vieglākā daļa. Īstais darbs ir atrast katru vietu, kur izmanto vecās komandas: monitoringa pārbaudes, dublēšanas skriptus, pārslēgšanās rīkus, Ansible lomas, rīcības plānus. Nobīdes pārbaude, kas izgāžas ar sintakses kļūdu, panelī bieži izskatās kā "replikācija kārtībā", un tas ir sliktāk par brīdinājumu. Ja paļaujaties uz replikas veselības pārbaudēm, skatiet, kā tās uzraugām mūsu ceļvedī par MySQL replikācijas nobīdi.

Pazudušas ir arī vairākas servera opcijas, un to iestatīšana 8.4 izraisa kļūdu. Starp tām, kas joprojām sastopamas daudzās 8.0 konfigurācijās: default_authentication_plugin, binlog_transaction_dependency_tracking, --ssl, master_info_repository un relay_log_info_repository, slave_rows_search_algorithms, --skip-host-cache un transaction_write_set_extraction. Iztīriet tās no konfigurācijas pirms atjaunināšanas, nevis tās laikā.

Kas mainās klusi: InnoDB noklusējumi

Vairākas InnoDB noklusējuma vērtības mainītas versijā 8.4.0. Ja tās iestatāt skaidri, jums nekas nemainās. Ja paļāvāties uz noklusējumiem, serveris pēc atjaunināšanas uzvedas citādi:

• innodb_io_capacity: 200 → 10000. Fona izlāde kļūst daudz agresīvāka. Labi ātriem SSD vai NVMe, vērts pārskatīt lēniem vai ierobežotiem mākoņa sējumiem.
• innodb_adaptive_hash_index: ON → OFF.
• innodb_change_buffering: all → none.
• innodb_flush_method Linux vidē: fsync → O_DIRECT, ja tas tiek atbalstīts.
• innodb_log_buffer_size: 16 MiB → 64 MiB.
• innodb_buffer_pool_instances, lasīšanas un rakstīšanas I/O pavedieni, tīrīšanas pavedieni un lapu tīrītāji tagad tiek aprēķināti no bufera pūla izmēra un CPU skaita, nevis ir fiksēti skaitļi.

Jaunie noklusējumi ir saprātīgi mūsdienu aparatūrai, bet "saprātīgi vidēji" nav tas pats, kas "tāpat kā iepriekš". Salīdziniet veiktspēju ar reālistisku slodzi pirms produkcijas, un, ja kaut kas pasliktinās, jūs zināt, kurus parametrus skatīt vispirms.

Drošs atjaunināšanas plāns

1. Vispirms atjauniniet uz jaunāko 8.0 laidienu, lai sāktu no pilnībā salāpīta servera.
2. Palaidiet atjaunināšanas pārbaudītāju. MySQL Shell atjaunināšanas pārbaudītāju iesaka rokasgrāmata, un tas veic automātiskās pārbaudes jūsu mērķa versijai:

   mysqlsh -- util checkForServerUpgrade root@db-host:3306 --target-version=8.4.0

   Salabojiet katru kļūdu un izlasiet katru brīdinājumu. Sagatavošanas sarakstā ir arī manuālas pārbaudes, piemēram, novecojuši datu tipi, bāreņu .frm faili un trigeri bez definētāja.
3. Iztīriet konfigurāciju. Noņemiet dzēstās opcijas un pieņemiet skaidru lēmumu par augstāk minētajiem InnoDB iestatījumiem, nevis nejauši mantojiet jaunos noklusējumus.
4. Salabojiet klientus. Atrodiet mysql_native_password kontus, pārbaudiet draiverus un atjauniniet skriptus un monitoringu uz jaunajām replikācijas komandām. SHOW REPLICA STATUS, START/STOP REPLICA un CHANGE REPLICATION SOURCE TO jau darbojas jaunākajos 8.0 laidienos, tāpēc tās var nomainīt pirms atjaunināšanas. SHOW BINARY LOG STATUS un RESET BINARY LOGS AND GTIDS pastāv tikai no 8.2, tāpēc tās mainās kopā ar serveri.
5. Testējiet ar produkcijai līdzīgiem datiem un slodzi. Atjaunojiet nesenu dublējumu 8.4 testa serverī, palaidiet lietotnes testus un atkārtojiet reālistisku slodzi. Salīdziniet lēno vaicājumu žurnālus.
6. Vispirms atjauniniet replikas. Atjauniniet vienu repliku, novirziet uz to lasīšanas slodzi, sekojiet kļūdām un latentuma izmaiņām. Tad atjauniniet pārējās.
7. Pārslēdziet primāro serveri. Paaugstiniet 8.4 repliku plānotā apkopes logā vai atjauniniet veco primāro uz vietas. Paturiet 8.0 serveri, kas replicē, vai pārbaudītu dublējumu kā atgriešanās ceļu, līdz esat pārliecināti.

Pārvaldītais MySQL

RDS, Cloud SQL un Azure vidē bināros failus pārvalda pakalpojuma sniedzējs, bet ne saderības problēmas. Autentifikācija, noņemtās komandas jūsu skriptos un mainītie parametru noklusējumi joprojām attiecas uz jums, un pakalpojumu sniedzējiem parasti ir savas parametru grupas un termiņi, dažreiz ar papildu maksu par vecāku versiju izmantošanu. Pārbaudiet sava pakalpojuma sniedzēja dokumentācijā tā 8.4 parametru noklusējumus un izmantojiet blue/green vai uz replikām balstītu atjaunināšanu, ja tāda tiek piedāvāta.