MySQL LTS და Innovation რელიზები: რომელი ვერსია გაუშვა

2026 წლის ბოლოს production მონაცემთა ბაზისთვის პასუხი არის LTS რელიზი: MySQL 8.4 ან MySQL 9.7. ორივე წლების განმავლობაში იღებს შეცდომებისა და უსაფრთხოების გამოსწორებებს, არცერთი არ ცვლის ქცევას საკუთარი სერიის შიგნით და ორივე უსაფრთხო არჩევანია აპლიკაციისთვის, რომელსაც ხელს აღარ ახლებ. MySQL 8.0 დასრულებულია - მისი ბოლო რელიზი, 8.0.46, 2026 წლის აპრილში გამოვიდა და Oracle მისთვის სხვა გამოსწორებებს აღარ აქვეყნებს. Innovation რელიზები (8.1-დან 8.3-მდე, 9.0-დან 9.6-მდე და ახლა უკვე კალენდარული ნუმერაციის 26.7) production ხარისხისაა, მაგრამ მხარდაჭერილია მხოლოდ შემდეგი რელიზის გამოსვლამდე, დაახლოებით სამი თვე. ანუ მის გაშვებას ნიშნავს წელიწადში ოთხჯერ განახლება რელიზებით, რომლებსაც ფუნქციების წაშლის უფლება აქვთ.

ამ სტატიაში განვიხილავთ ორ ხაზს, მნიშვნელოვან თარიღებს, 2026 წლის ივლისიდან შემოღებულ ახალ კალენდარულ ვერსიებს, განახლების დასაშვებ და დაუშვებელ მარშრუტებს და იმას, თუ როგორ არის შენი რეალური ვერსია დამოკიდებული წყაროზე: Linux დისტრიბუტივზე, Oracle-ის რეპოზიტორიებზე თუ Docker ტეგზე, რომელიც შეიძლება ქვეშ გამოგეცალოს.

ორი სარელიზო ხაზი#

8.0-მდე MySQL-ს ყოველ მთავარ ვერსიაზე ერთი ხანგრძლივი სერია ჰქონდა და ახალი ფუნქციები patch რელიზებში ჩნდებოდა. 8.0.18-მა მოიტანა hash join-ები და EXPLAIN ANALYZE; 8.0.30-მა - innodb_redo_log_capacity. ორი სერვერი, ორივე "8.0", შეიძლება საკმაოდ განსხვავებულად მოქცეულიყო. 2023 წლის ივლისში 8.1-დან დაწყებული, Oracle-მა რელიზები ორ ხაზად გაყო.

Oracle-ის სახელმძღვანელო ორივე ხაზს "production-grade quality"-ის უწოდებს. განსხვავება ხარისხში კი არა, ცვლილებაშია. LTS სერია ქცევით გაყინულია: 8.4.1-დან 8.4.11-მდე მხოლოდ გამოსწორებებია და არა ახალი ფუნქციები ან სხვა ნაგულისხმევი მნიშვნელობები. სწორედ ამიტომ მუშაობს LTS სერიის შიგნით ადგილზე downgrade - მონაცემების ფორმატი არ იცვლება, ამიტომ თუ patch-მა პრობლემა შეგიქმნა, 8.4.11-დან 8.4.10-ზე დაბრუნება შეგიძლია.

Innovation რელიზი საპირისპიროა. თითოეულს შეუძლია ფუნქციების deprecated-ად გამოცხადება ან წაშლა, რეზერვირებული სიტყვების შეცვლა, ოპტიმიზატორის ქცევის შეცვლა და ნაგულისხმევი მნიშვნელობების შეცვლა. სახელმძღვანელო აფრთხილებს, რომ ასეთმა ცვლილებებმა "can have a big impact" შეიძლება მოახდინოს, განსაკუთრებით SQL სინტაქსსა და მოთხოვნების წარმადობაზე. Innovation ციკლში წაშლილი ფუნქციები სამუდამოდ იშლება მის დამხურავ LTS-ში, ამიტომ 8.0-დან 8.4-ზე გადასვლამ ვერსიის ნომერზე მეტი რამ დააზიანა - 8.1, 8.2 და 8.3-ის ყველა წაშლა ერთბაშად მოვიდა. MySQL 8.4 LTS: რა შეიცვალა ამ ცვლილებებს ჩამოთვლის.

აქამდე ნიმუში ასეთია: Innovation რელიზების სერია, შემდეგ LTS, რომელიც შედეგს ყინავს.

თარიღები, რომლებიც მნიშვნელოვანია#

ეს ის თარიღებია, რომლებიც კალენდარში უნდა ჩაიწერო. Oracle-ის Lifetime Support Policy LTS სერიას აძლევს ხუთ წელს premier მხარდაჭერას და სამს extended მხარდაჭერას, პირველი GA რელიზიდან დათვლით. Community Edition-ის მომხმარებლისთვის პრაქტიკული აზრი მარტივია: patch რელიზები ამ ვადის ბოლომდე გამოდის.

9.7-ის თარიღები გამომდინარეობს "ხუთი პლუს სამი" წესიდან, რომელიც 2026 წლის აპრილის GA-ზეა გამოყენებული; ზუსტი თვის დასადასტურებლად Oracle-ის lifetime support დოკუმენტს გადახედე. ნებისმიერ შემთხვევაში, 8.4 კიდევ წლებით არის მხარდაჭერილი - მისი დატოვების აჩქარება არ გჭირდება და აპლიკაციას, რომელიც 2025 წელს გადავიდა 8.4-ზე, ამ ათწლეულის ბოლომდე ხელახლა გადასვლა არ დასჭირდება.

8.0-ის შესახებ: "end of life" ნიშნავს, რომ Oracle-ისგან გამოსწორებები აღარ მოდის, მათ შორის 2026 წლის აპრილის შემდეგ აღმოჩენილი უსაფრთხოების მოწყვლადობებისთვის. ზოგი დისტრიბუტივი და ღრუბლოვანი პროვაიდერი საკუთარ პაკეტებს კიდევ ცოტა ხანს ინახავს - Ubuntu 22.04-მა და 24.04-მა 8.0.46 2026 წლის ივნისში მიიღეს, ხოლო Oracle-მა 8.0 საკუთარ HeatWave სერვისზე 2027 წლის აპრილამდე გაახანგრძლივა - მაგრამ ეს იმ ხაზის ბოლო patch-ებია, რომელსაც არავინ ავითარებს. სერვერი, რომელიც ჯერ კიდევ 8.0-ზეა, პირველი უნდა დაგეგმო.

კალენდარული ვერსიები 26.7-დან#

2026 წლის ივლისში MySQL-მა ნუმერაცია შეცვალა. 9.7 არის ბოლო სარელიზო ხაზი თანმიმდევრული ნომრებით; ყველაფერი შემდეგ იყენებს კალენდარულ ვერსიებს YY.M.P ფორმით - წლის ორი ციფრი, რელიზის თვე, patch ნომერი. 2026 წლის ივლისის Innovation რელიზია 26.7.0, ხოლო შემდეგ Innovation რელიზებს Oracle-მა 26.10, 27.1, 27.4 და 27.7 დაარქვა.

აქ ორი რამ აბნევს ხალხს.

პირველი, ნომერი უკვე აღარ გეუბნება, რომელი ხაზია. 26.7 Innovation რელიზია იმიტომ, რომ ასე ამბობს Oracle, და არა მისი ციფრების გამო, ხოლო მომავალ LTS-საც კალენდარული ნომერი ექნება. ხაზი ყოველთვის რელიზის ჩანაწერებით ან იმ რეპოზიტორიით დაადგინე, საიდანაც დააინსტალირე, და არა ვერსიის სტრიქონიდან გამოცნობით. მუშა სერვერზე:

SELECT @@version, @@version_comment;

@@version_comment აჩვენებს build-ს, მაგალითად MySQL Community Server - GPL; დისტრიბუტივის build-ები საკუთარ ტექსტს ამატებენ.

მეორე, patch ნომრები LTS სერიის შიგნით ახლა კვარტალურ უსაფრთხოების ციკლს მიჰყვება. თითოეული კვარტალური Critical Patch Update (CPU) მესამე ნომერს ზრდის: 8.4.11, შემდეგ 8.4.12. თუ სერიოზულ მოწყვლადობას კვარტლებს შორის გამოსწორება სჭირდება, Oracle გამოუშვებს მიზნობრივ patch-ს (CSPU) მეოთხე ნომრით - 8.4.11.1, 8.4.11.2 - და შემდეგი კვარტალური რელიზი ისევ სამ ნომერზე ბრუნდება. Innovation რელიზებზე მესამე ნომერი 0-ზე რჩება, რადგან კვარტლის გამოსწორება უბრალოდ შემდეგი Innovation რელიზია. Windows MSI პაკეტები ოთხნაწილიან ვერსიებს სხვაგვარად აკოდირებენ (8.4.11.1 ინსტალერის მეტამონაცემებში 8.4.1101-ად ჩანს), რაც მხოლოდ კოსმეტიკურია.

სკრიპტები, რომლებიც mysql --version-ს ან SELECT VERSION()-ს ამუშავებენ და მთავარ ვერსიას ერთციფრიანად თვლიან, 26.7.0-ს არასწორად წაიკითხავენ. ვერსიები კომპონენტების მიხედვით რიცხობრივად შეადარე და არა სტრიქონებად, და გადაამოწმე მონიტორინგის დაფები და Ansible-ის ან Puppet-ის facts, რომლებიც "მთავარი ვერსია 8 ან 9" პირობით ტოტავენ.

განახლებისა და downgrade-ის მარშრუტები#

ტრეკების მოდელს მკაცრი წესები მოჰყვება იმის შესახებ, თუ რომელი გადასვლა არის სერვერის მიერ ადგილზე მხარდაჭერილი. მოკლედ: LTS-იდან შემდეგ LTS-ზე, არასოდეს ერთის გამოტოვებით.

წესები, როგორც სახელმძღვანელოშია ჩამოყალიბებული:

• LTS სერიის შიგნით ადგილზე განახლებაც და downgrade-იც მხარდაჭერილია. 8.4.3-დან 8.4.11-ზე და უკან გადასვლა დასაშვებია.
• ერთი LTS-იდან შემდეგზე ადგილზე განახლება მხარდაჭერილია: 8.4.x-დან 9.7.x-ზე. LTS-ის გამოტოვება არ შეიძლება - 8.4-იდან პირდაპირ იმ LTS-ზე ვერ გადახვალ, რომელიც 9.7-ს მოჰყვება.
• Innovation რელიზი ადგილზე განახლდება იმავე ციკლის უფრო გვიან Innovation რელიზზე ან მის დამხურავ LTS-ზე: 9.1-დან 9.2-ზე, ან 9.5-დან 9.7-ზე.
• Innovation რელიზი პირდაპირ ვერ გადაკვეთს შემდეგ ციკლს. 8.3 9.0-ზე 8.4-ის გავლით გადადის.
• მხოლოდ 9.7 LTS-ს შეუძლია ადგილზე განახლება პირველ კალენდარულ ციკლში, რომელსაც 26.7 იწყებს.
• Innovation რელიზის downgrade-ს ყოველთვის სჭირდება ლოგიკური dump და load.

8.0 მოდელამდეა, მაგრამ იგივე პრინციპი მასზეც მოქმედებს: 8.0-დან 8.4-ზე ადგილზე გადასვლა ახალი 8.0 patch-იდან მხარდაჭერილია; 8.0-დან 9.7-ზე გზა 8.4-ზე გადის. 5.7-მა ჯერ 8.0-ს უნდა მიაღწიოს.

ლოგიკური dump და load ამ წესების უმეტესობას გვერდს უვლის. mysqldump-ის ან MySQL Shell-ის dump 8.0-დან ან 8.4-დან თითქმის ყველა შემთხვევაში იტვირთება 9.7-ში, რადგან ის უბრალოდ SQL-ია; შეიძლება შინაარსი ჩავარდეს - ანგარიშები წაშლილ authentication plugin-ებზე, რეზერვირებული სიტყვები იდენტიფიკატორებად, არარსებული definer-ები. ესაა გზა ნებისმიერი hosted ბაზისთვისაც, სადაც პროვაიდერის სერვერზე binary-ებს ვერ ჩაანაცვლებ. mysqldump backup და restore flag-ებს განიხილავს, ხოლო MySQL-ის ახალ ჰოსტზე გადატანა - გადართვას.

ნებისმიერ გადასვლამდე გაუშვი MySQL Shell-ის upgrade checker ძველ სერვერზე იმ სამიზნე ვერსიით, რომელსაც გეგმავ:

$ mysqlsh root@db.example.com:3306 -- util check-for-server-upgrade \    --target-version=9.7.2

გამოიყენე MySQL Shell, რომელიც სულ მცირე სამიზნე ვერსიის ტოლფასად ახალია, რადგან checker მხოლოდ მასზე ადრე გამოშვებულ ვერსიებს იცნობს.

production-ში რომელი ვერსია გაუშვა#

უმეტესობისთვის არჩევანი ორ მხარდაჭერილ LTS სერიას შორისაა.

დარჩი 8.4-ზე ან გადადი მასზე, თუ შენი აპლიკაცია მასზე უკვე მუშაობს, თუ ჰოსტინგ პროვაიდერი მას გთავაზობს, ან თუ შენმა ORM-მა, driver-მა ან ხელსაწყოებმა 9.x-ს ჯერ არ დაუწია. 8.4-ს premier მხარდაჭერა 2029 წლამდე აქვს; მანამდე გადასვლას არაფერი გაიძულებს. ის ასევე კონსერვატიული სამიზნეა 8.0-იდან, რადგან 8.0-დან 8.4-ზე გზა კარგად გადაულახავია და 8.4 ჯერ კიდევ საშუალებას გაძლევს mysql_native_password დროებით ისევ ჩართო.

აირჩიე 9.7 ახალი პროექტისთვის ისტორიის გარეშე, ან თუ გინდა ის, რაც 9.0-დან 9.6-მდე გაჩნდა: VECTOR მონაცემთა ტიპი, ოპტიმიზატორის ახალი სამუშაოები და რამდენიმე ფუნქცია, რომელიც Oracle-მა 9.7-ით Enterprise-იდან Community Edition-ში გადმოიტანა, მათ შორის replication applier-ის მეტრიკები და Group Replication-ის flow-control სტატისტიკა. ფასიც იცოდე: mysql_native_password 9.0-ში მთლიანად წაიშალა, ამიტომ ნებისმიერი ანგარიში ან კლიენტი, რომელიც მასზე ჯერ კიდევ არის დამოკიდებული, ვერ იმუშავებს და უკან ჩასართავი გადამრთველი არ არსებობს. ყველა driver-მა caching_sha2_password უნდა იცოდეს.

გამოიყენე Innovation რელიზი ტესტირებისთვის, დეველოპმენტ გარემოებისთვის, რომლებიც იმას მიჰყვებიან, რაც მოდის, ან თუ გჭირდება კონკრეტული ფუნქცია ახლავე და გუნდი მზადაა ყოველ კვარტალში განახლებისთვის. 26.x-ის production-ში გაშვება ლეგიტიმურია - Oracle მას უჭერს მხარს - მაგრამ მხოლოდ იმ შემთხვევაში, თუ ვინმეს ეკისრება ეს კვარტალური განახლება და აპლიკაციის ტესტები ყოველ ახალ რელიზზე გადის.

წესი, რომელიც გამართლებულია: production LTS-ზე, ერთი staging ან CI ბაზა ყველაზე ახალ Innovation რელიზზე. როცა შემდეგი LTS მოვა, Innovation-ის პერიოდის წაშლები CI-ში უკვე გამოჩნდება და production-ის განახლება დაგეგმილი იქნება და არა შემთხვევით აღმოჩენილი.

დისტრიბუტივის პაკეტები#

რასაც apt install mysql-server ან dnf install mysql-server გაძლევს, დამოკიდებულია დისტრიბუტივის რელიზზე და არა იმაზე, რასაც Oracle ამჟამად გირჩევს. დისტრიბუტივები ვერსიას ყინვისას ირჩევენ და რელიზის მთელი სიცოცხლის განმავლობაში ინახავენ.

Ubuntu 24.04-ზე mysql-server პაკეტი ჯერ კიდევ mysql-server-8.0-ია. Ubuntu-მ მას 8.0.46 2026 წლის ივნისში მიაწოდა, მაგრამ Oracle-ისგან 8.0.47 აღარ მოვა, ამიტომ Ubuntu 24.04 სერვერი, რომელიც დისტრიბუტივის MySQL-ს უშვებს, გაჩერებულ ხაზზეა. გამოსავალი ორია: ოპერაციული სისტემა 26.04-ზე განაახლე, ან 8.4 Oracle-ის რეპოზიტორიიდან დააინსტალირე.

Debian ცალკე აღნიშვნას იმსახურებს, რადგან ხალხს უკვირს: apt install default-mysql-server Debian-ზე MariaDB-ს აყენებს და mysql ბრძანება MariaDB-ის კლიენტია. MariaDB MySQL 5.5-იდან გამოიყო და მას შემდეგ გაიყო - ის MySQL-ის ვერსია არ არის, აქვს საკუთარი რელიზებისა და მხარდაჭერის გრაფიკი და MySQL 8.4-ის data directory-ს ვერ კითხულობს. თუ Debian-ზე თავად MySQL გჭირდება, ის Oracle-ის APT რეპოზიტორიიდან ან Docker-იდან მოდის.

იმის სანახავად, რა გაქვს რომელიმე მათგანზე:

$ mysqld --version$ apt-cache policy mysql-server      # Debian and Ubuntu$ dnf info mysql-server              # RHEL family

Oracle-ის საკუთარი რეპოზიტორიები#

Oracle APT და Yum რეპოზიტორიებს repo.mysql.com-ზე აქვეყნებს და სწორედ აქ ირჩევა ხაზი პირდაპირ. რეპოზიტორიის დაყენების პაკეტი (mysql-apt-config Debian-სა და Ubuntu-ზე, mysql84-community-release და მსგავსი RHEL ოჯახში) აყენებს კონფიგურაციას, სადაც ერთ სერიას ირჩევ: 8.4 LTS რეპოზიტორიას, 9.7 LTS რეპოზიტორიას ან Innovation რეპოზიტორიას.

Yum-ის მხარეს თითოეული ხაზი ცალკე სახელდებული რეპოზიტორიაა და ზუსტად ერთს რთავ. სახელმძღვანელოს მაგალითი იყენებს mysql-innovation-community-ს Innovation-ისთვის და mysql-9.7-lts-community-ს 9.7 LTS-ისთვის:

$ dnf repolist all | grep mysql$ sudo dnf config-manager --disable mysql-innovation-community$ sudo dnf config-manager --enable mysql-9.7-lts-community

Debian-სა და Ubuntu-ზე არჩევანი დიალოგში კეთდება, როცა mysql-apt-config ინსტალირდება, და მოგვიანებით შეიძლება შეიცვალოს:

$ sudo dpkg-reconfigure mysql-apt-config$ sudo apt update

ვერსიის ნაცვლად ხაზის არჩევის აზრი ისაა, რა ხდება apt upgrade-ზე. LTS რეპოზიტორია 8.4.10-დან 8.4.11-ზე გადაგიყვანს და არასოდეს 9.7-ზე. Innovation რეპოზიტორია ერთი Innovation რელიზიდან შემდეგზე გადაგიყვანს, რაც Innovation-ის არსია, და მასზე მიმართული unattended-upgrades დავალება ბაზის ფუნქციურ განახლებას გააკეთებს, როცა Oracle რაიმეს გამოუშვებს. production სერვერზე ჩართე LTS რეპოზიტორია და სხვა არაფერი. ასევე, სანამ დაეყრდნობი, შეამოწმე, აქვეყნებს თუ არა Oracle რეპოზიტორიას შენი დისტრიბუტივის რელიზისთვის - დისტრიბუტივის ახალი რელიზები ზოგჯერ გამოსვლიდან თვეების შემდეგ ემატება.

Docker image-ის ტეგები#

Docker Hub-ზე ოფიციალური mysql image ტეგებს ხაზებს უკავშირებს და ზოგი ტეგი მოძრაობს. 2026 წლის ოქტომბრის მდგომარეობით მხარდაჭერილი ტეგებია:

თითოეულს აქვს -oracle ან -oraclelinux9 ვარიანტები; ყველა მიმდინარე image Oracle Linux 9-ზეა აგებული. Debian-ზე დაფუძნებული image-ის ვარიანტები 8.0-ს ეკუთვნოდა და მასთან ერთად გაქრა, ხოლო mysql:8.0 მხარდაჭერილ სიაში აღარ არის - ტეგი ჯერ კიდევ იწერება, მაგრამ მას აღარავინ აახლებს.

უბედური შემთხვევების უმეტესობა სამ ტეგს მოჰყვება.

latest Innovation რელიზია. Compose ფაილი image: mysql ან image: mysql:latest-ით შემდეგ docker compose pull-ზე ბაზას იმ Innovation რელიზზე განაახლებს, რომელიც მაშინ მიმდინარეა - და რადგან Innovation-ის downgrade-ს dump და load სჭირდება, ტეგის შეცვლით უკან დაბრუნება არ შეიძლება.

lts გადაადგილდა. სანამ 9.7 2026 წლის აპრილში გამოვიდოდა, mysql:lts 8.4 იყო. ვინც lts-ზე მიება, "სტაბილური" რომ ეგონა, შემდეგ pull-ზე ადგილზე განახლება მიიღო 8.4-დან 9.7-ზე - მხარდაჭერილი განახლება, მაგრამ ისეთი, რომელმაც mysql_native_password წაშალა და ტეგის შეცვლით ვერ გაუქმდებოდა. lts ისევ გადაადგილდება, როცა შემდეგი LTS მოვა.

8 ასევე გადაადგილდა. 8.0-ის სიცოცხლისას ის 8.0-ზე უთითებდა, ახლა კი 8.4-ზე უთითებს.

უსაფრთხო ნიმუში ისაა, რომ მიება იმ სერიას, რომელიც აირჩიე, და patch-ები თავისით მოვიდეს:

services:  db:    image: mysql:8.4    environment:      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root      MYSQL_DATABASE: app    volumes:      - db-data:/var/lib/mysql

mysql:8.4 იღებს 8.4 patch-ებს და არასოდეს გადახტება სხვა სერიაზე. თუ გინდა, რომ ყოველი patch ცალკე გადაწყვეტილება იყოს, მიება სრულ ვერსიას (mysql:8.4.11) და თავად აამაღლე. ორივე შემთხვევაში ვერსიას წინ volume-ში არსებული data directory მიიყვანს: უფრო ახალი სერიიდან გაშვებული container მას პირველ გაშვებაზე განაახლებს, ხოლო უფრო ძველი სერია მასზე ვერ ეშვება. Docker Compose პატარა stack-ებისთვის volume-ებსა და secret-ებს უფრო სიღრმისეულად განიხილავს.

შენი ვერსიის შემოწმება და დაგეგმვა#

მოკლე აუდიტი ნებისმიერი MySQL-ისთვის, რომელზეც პასუხისმგებელი ხარ:

1. იპოვე ზუსტი ვერსია SELECT @@version;-ით და ისიც, საიდან მოვიდა: დისტრიბუტივის პაკეტი, Oracle-ის რეპოზიტორია, Docker ტეგი თუ ჰოსტინგ პროვაიდერი.
2. ზემოთ მოცემული ცხრილებით დაუკავშირე ხაზსა და მხარდაჭერის თარიღს. ყველაფერი, რაც 8.0-ზე, 5.7-ზე ან Innovation რელიზზეა, რომელიც ბოლო არ არის, ახლა მხარდაუჭერელია.
3. შეამოწმე, როგორ ახლდება. დისტრიბუტივის პაკეტი დისტრიბუტივს მიჰყვება; Oracle-ის რეპოზიტორია - ჩართულ ხაზს; Docker ტეგი - იმას, რასაც ტეგი უთითებს; hosted ბაზა - პროვაიდერს.
4. თუ გადასვლა გჭირდება, აირჩიე სამიზნე LTS, გაუშვი upgrade checker, authentication mysql_native_password-დან გადაიტანე (იხილე MySQL-ის მომხმარებლები და პრივილეგიები) და ასლზე რეპეტიცია ჩაატარე.
5. იმ სერიის მხარდაჭერის დასასრულის თარიღი, რომელზეც აღმოჩნდები, კალენდარში ჩაწერე, მის დადგომამდე ერთი წლით ადრე.

FAQ#

MySQL 9.7 LTS რელიზია?

დიახ. MySQL 9.7.0 2026 წლის აპრილში გამოვიდა, როგორც 8.4-ის შემდეგ მეორე LTS სერია, და ხურავს 9.x Innovation ციკლს, რომელიც 9.0-ით დაიწყო. ის ასევე ბოლო სარელიზო ხაზია თანმიმდევრული ვერსიის ნომრებით; შემდეგი რელიზები კალენდარულ ვერსიებს იყენებენ, მაგალითად 26.7.

უსაფრთხოა Innovation რელიზის production-ში გაშვება?

Oracle მას უჭერს მხარს და production ხარისხისად მიიჩნევს, ამიტომ ეს უპასუხისმგებლობა არ არის. პრობლემა მხარდაჭერის ფანჯარაშია: თითოეული Innovation რელიზი იპატჩება მხოლოდ შემდეგის გამოსვლამდე, ამიტომ მხარდაჭერილად დარჩენა დაახლოებით ყოველ სამ თვეში ფუნქციურ განახლებას ნიშნავს, რომელთაგან თითოეულმა რაიმე შეიძლება წაშალოს. თუ თითოეულის გასატესტად დრო არ გაქვს, გამოიყენე LTS.

შემიძლია MySQL 8.0-დან პირდაპირ 9.7-ზე განახლება?

ადგილზე - არა. მხარდაჭერილი მარშრუტია 8.0-დან 8.4-ზე, შემდეგ 8.4-დან 9.7-ზე. 8.0-დან ლოგიკური dump, ახალ 9.7 სერვერში ჩატვირთული, ჩვეულებრივ მუშაობს, თუ არცერთი ანგარიში mysql_native_password-ზე არ არის დამოკიდებული და upgrade checker სერიოზულს არაფერს აჩვენებს.

რას მაძლევს mysql:latest Docker-ში?

მიმდინარე Innovation რელიზს - 2026 წლის ოქტომბრის მდგომარეობით 26.7-ს. ის ყოველ კვარტალში იცვლება. ბაზისთვის, რომელიც გიყვარს, მიება mysql:8.4-ს ან mysql:9.7-ს და არა latest-ს და არც lts-ს, რადგან lts შემდეგ LTS-ზე გადაადგილდება, როცა ის გამოვა.

აუცილებელია MySQL 8.4-ის დატოვება 9.7-ის სასარგებლოდ?

არა. 8.4-ს premier მხარდაჭერა 2029 წლის აპრილამდე აქვს და extended მხარდაჭერა 2032 წლის აპრილამდე, და ის კვარტალურ patch რელიზებს აგრძელებს. 9.7-ზე გადასვლა 2029 წლამდე დასაგეგმია, მაგრამ მანამდე ბოლო ვადა არ არსებობს.

MariaDB MySQL-ის ვერსიაა?

არა. MariaDB MySQL 5.5-ის fork-ად დაიწყო და ახლა ცალკე ბაზაა საკუთარი ვერსიებითა და მხარდაჭერის გრაფიკით. Debian მას აყენებს, როცა default-mysql-server-ს ითხოვ. კლიენტების უმეტესობასთან ის იგივე პროტოკოლით მუშაობს, მაგრამ მისი მონაცემთა ფაილები და ახალი ფუნქციები MySQL 8.4-თან ან 9.7-თან ურთიერთშესაცვლელი არ არის.