
به اشتراک بگذارید
Downgrade کردن نسخه Mysql در Cpanel یا MariaDB (که جایگزین رایج آن است)، یکی از حساسترین عملیاتهای مدیریتی در حوزه سرور است. زمانی که شما یک بهروزرسانی (Upgrade) انجام میدهید، دیتابیسهای شما برای کار با قابلیتهای جدید بهینهسازی میشوند؛ اما گاهی اوقات، سیستم مدیریت محتوای قدیمی شما (مانند نسخههای خاص وردپرس یا جوملا) با این نسخههای جدید سازگار نیستند و خطا میدهند. در چنین شرایطی، برگشت به نسخه قبلی MySQL در cPanel به یک ضرورت تبدیل میشود تا عملکرد سایتهایتان به حالت عادی بازگردد.
💡 نکته مهم: Downgrade؛ آخرین راهحل
- ✅ Downgrade نباید راهحل دائمی باشد. این عملیات صرفاً یک راهکار موقت برای حل فوری ناسازگاریها است.
- ✅ تنها در وبداده: ما فرآیند را بهگونهای توضیح میدهیم که حداقل ریسک از دست رفتن داده را داشته باشید.
حتماً زمانی که این مقاله را باز کردهاید، به دنبال یک راهنمای فنی و عملی هستید تا بتوانید سرویسهای دیتابیس سرور مجازی خود را که پس از آپگرید دچار مشکل شدهاند، نجات دهید. ما به شما قول میدهیم که در این مقاله، آموزش گامبهگام و جامعی را ارائه دهیم که نه تنها مراحل عملیاتی را پوشش میدهد، بلکه شما را با ریسکها، دلایل ناسازگاری نسخههای جدید MySQL در cPanel و راهکارهای عیبیابی پس از عملیات نیز آشنا میسازد. پس همراه ما باشید تا با دانش و اطمینان کامل، این عملیات حساس را انجام دهید. 😉👇
بهترین VPS های وبداده حاصل مجازی سازی اختصاصی با منابع بالا و قدرتمند در بیش از 9 لوکیشن از آسیا تا اروپا و آمریکا…
برای مشاهده موقعیتهای
سرور مجازی وبداده
روی دکمه زیر کلیک کنید
سرور مجازی وبداده
روی دکمه زیر کلیک کنید
آنچه در این مقاله میخوانید:
4.3تست اتصال
Downgrade نسخه MySQL در WHM و cPanel چیست؟
Downgrade کردن نسخه Mysql در Cpanel به معنای بازگرداندن سیستم پایگاه داده MySQL یا MariaDB به یک نسخه قدیمیتر و پایدارتر است که قبلاً روی سرور شما نصب بوده است. این عملیات برخلاف آپگرید، که معمولاً فرآیندی خودکار و با سازگاری بالاتر است، میتواند چالشبرانگیز باشد. دلیل این چالش آن است که نسخههای جدیدتر دیتابیس اغلب ساختار جداول را برای عملکرد بهتر و امنیت بالاتر تغییر میدهند، و بازگشت به نسخه قدیمیتر ممکن است با فرمتهای جدید دادهها سازگار نباشد.
چرایی نیاز به برگشت به نسخه قبلی MySQL در cPanel
نیاز به برگشت به نسخه قبلی MySQL در cPanel معمولاً به دلیل وجود ناسازگاریهای فنی بین نرمافزارهای قدیمی مشتری و نسخههای جدید دیتابیس (مانند MySQL 8.0 یا MariaDB 10.6) رخ میدهد. برای مثال، بسیاری از سیستمهای مدیریت محتوا (CMS) و فریمورکهای قدیمی یا حتی پلاگینهای خاص، ممکن است از توابع (Functions) یا ساختارهای رمزنگاری استفاده کنند که در نسخههای جدید دیتابیس حذف شدهاند یا تغییر کردهاند.
📌 Case Study (تجربه واقعی یک کاربر)
در سال 2024، یکی از کاربران سرویس های میزبانی پس از آپگرید از MariaDB 10.3 به 10.6 با مشکل عدم شناسایی کامل جداول InnoDB در یک CMS قدیمی مواجه شد. در این حالت، دادهها وجود داشتند اما دسترسی به آنها ممکن نبود. ما با کمک Downgrade به نسخه 10.3 و اجرای دستور REPAIR TABLE توانستیم سرویس را بدون اتلاف داده، سریعاً برگردانیم.
در سال 2024، یکی از کاربران سرویس های میزبانی پس از آپگرید از MariaDB 10.3 به 10.6 با مشکل عدم شناسایی کامل جداول InnoDB در یک CMS قدیمی مواجه شد. در این حالت، دادهها وجود داشتند اما دسترسی به آنها ممکن نبود. ما با کمک Downgrade به نسخه 10.3 و اجرای دستور REPAIR TABLE توانستیم سرویس را بدون اتلاف داده، سریعاً برگردانیم.
ریسکهای Downgrade دیتابیس و اهمیت بکاپ گرفتن
عملیات Downgrade ذاتاً پرریسک است. بزرگترین ریسک، خرابی ساختار دادهها (Corruption) است؛ به ویژه اگر دیتابیسهای شما از قابلیتهای جدیدی استفاده کرده باشند که در نسخه قدیمی وجود ندارند. به همین دلیل، بکاپ گرفتن قبل از Downgrade MySQL در WHM یک گام ضروری و غیرقابل چشمپوشی است.
⚠️ هشدار حیاتی: هرگز بدون داشتن یک بکاپ کامل و تست شده، اقدام به Downgrade نکنید.

بکاپگیری کامل با mysqldump
mysqldump --all-databases --single-transaction --routines --triggers > /root/all_databases_backup.sql
gzip /root/all_databases_backup.sql جدول مقایسه ناسازگاری نسخههای جدید MySQL در cPanel
| ویژگی ناسازگار | MySQL 5.7 (قدیمی) | MySQL 8.0 (جدید) | دلیل اصلی Downgrade |
|---|---|---|---|
| احراز هویت پیشفرض | mysql_native_password | caching_sha2_password | عدم سازگاری درایورهای PHP قدیمی |
| توابع رمزنگاری | PASSWORD(), ENCRYPT() | حذف شده | وابستگی کدهای قدیمی |
| تعریف کاراکترها | UTF8mb3 (اغلب) | UTF8mb4 (پیشفرض) | خطاهای Encoding |
| فرمت ذخیرهسازی | InnoDB قدیمیتر | InnoDB جدید | مشکلات خواندن/نوشتن جدول |
| Group By بدون Aggregation | مجاز | نیاز به ONLY_FULL_GROUP_BY | خطای Query |
راهنمای عملی: مراحل Downgrade از طریق SSH
⚠️ نکته مهم: WHM رابط گرافیکی برای Downgrade ندارد. ابزار “MySQL/MariaDB Upgrade” در WHM فقط برای آپگرید است. برای Downgrade باید از خط فرمان SSH استفاده کنید.
روش 1: Downgrade MariaDB (پیشنهادی برای cPanel)
این روش امنترین و سادهترین راه برای بازگشت به نسخه قدیمی MariaDB در سرورهای cPanel است که از فایل پیکربندی اصلی cPanel (
cpanel.config) و اسکریپتهای خودکار استفاده میکند. با این روش، شما نیازی به حذف دستی پکیجها یا نگرانی درباره وابستگیهای نرمافزاری ندارید، چرا که cPanel بهصورت هوشمند تمام فایلهای مورد نیاز را مدیریت میکند. این روش برای مدیران سروری که میخواهند با حداقل دخالت دستی و حداکثر سازگاری با محیط cPanel، عملیات Downgrade را انجام دهند، بسیار مناسب است.مرحله 1: بکاپ کامل
mysqldump --all-databases --single-transaction > /root/all_databases_backup.sql
cp -r /var/lib/mysql /root/mysql_data_backup مرحله 2: توقف سرویس MySQL
systemctl stop mysql مرحله 3: تعیین نسخه هدف در cPanel Config
nano /var/cpanel/cpanel.config پیدا کردن و تغییر این خط:
mysql-version=10.6 به:
mysql-version=10.3 ذخیره و خروج (Ctrl+X, Y, Enter).
مرحله 4: اجرای cPanel Scripts برای Downgrade
/scripts/check_cpanel_rpms --fix --targets=mysql مرحله 5: راهاندازی مجدد MySQL
systemctl start mysql
mysql_upgrade --force
systemctl restart mysql روش 2: Downgrade دستی (برای کاربران پیشرفته)
این روش برای مدیران سرور با تجربه بالا طراحی شده که میخواهند کنترل کامل بر فرآیند نصب و حذف پکیجهای MariaDB داشته باشند و یا در شرایطی که روش اول به هر دلیلی کار نکرده است. در این روش، شما مستقیماً با مدیر بستههای سیستم عامل (YUM/APT) کار میکنید و بهصورت دستی نسخه فعلی را حذف کرده و نسخه قدیمی را نصب میکنید، که نیازمند درک عمیقتری از ساختار لینوکس و وابستگیهای نرمافزاری است. این روش زمانی توصیه میشود که بخواهید نسخه خاصی را که در مخازن پیشفرض cPanel موجود نیست نصب کنید یا نیاز به عیبیابی عمیقتر داشته باشید.
برای CentOS/AlmaLinux/Rocky:
systemctl stop mysql
yum remove MariaDB-server MariaDB-client MariaDB-common
yum install MariaDB-server-10.3.* MariaDB-client-10.3.* MariaDB-common-10.3.*
systemctl start mysql
mysql_upgrade --force
systemctl restart mysql برای Ubuntu/Debian:
systemctl stop mysql
apt remove mariadb-server mariadb-client
apt install mariadb-server-10.3 mariadb-client-10.3
systemctl start mysql
mysql_upgrade --force
systemctl restart mysql اعتبارسنجی و رفع مشکلات پس از Downgrade
پس از اتمام عملیات Downgrade، مهمترین مرحله تأیید موفقیتآمیز بودن فرآیند و اطمینان از سلامت کامل دیتابیسهاست. در این بخش شما یاد میگیرید چگونه با استفاده از دستورات تشخیصی و ابزارهای بررسی، نسخه نصب شده را تأیید کنید، وضعیت جداول را چک کنید و در صورت بروز خطاهای رایج مانند جداول خراب (Crashed Tables) یا ناسازگاری ساختار، به سرعت آنها را برطرف کنید. بدون این مرحله حیاتی، ممکن است دیتابیس شما به ظاهر کار کند اما خطاهای پنهانی داشته باشد که بعداً منجر به از دست رفتن داده یا اختلال در سرویسدهی شود.
تأیید نسخه جدید
mysql -V خروجی باید نسخه جدید (مثلاً 10.3) را نشان دهد.
بررسی وضعیت سرویس
systemctl status mysql
tail -f /var/log/mysql/error.log تست اتصال
mysql -u root -p -e "SHOW DATABASES;" عیبیابی خطاهای رایج
پس از Downgrade، احتمال بروز خطاهای مختلفی مانند جداول خراب شده (Crashed Tables)، عدم شناسایی جداول با وجود فایل فیزیکی، یا مشکلات در خواندن ساختار دیتابیس وجود دارد که ناشی از تفاوت فرمت ذخیرهسازی بین نسخههای مختلف MySQL/MariaDB است. در این بخش، شما با رایجترین خطاها و راهحلهای فوری آنها آشنا میشوید و یاد میگیرید چگونه با استفاده از دستورات REPAIR TABLE، OPTIMIZE TABL و ابزار
mysqlcheck بهصورت سیستماتیک تمام دیتابیسها را بررسی و تعمیر کنید. این مهارتها به شما کمک میکند تا بدون نیاز به بازیابی کامل از بکاپ، اکثر مشکلات را حل کنید و سرویس را در کوتاهترین زمان به حالت عادی برگردانید.خطای “Table marked as crashed”
REPAIR TABLE `database_name`.`table_name`; خطای “Table doesn’t exist” با وجود فایل
REPAIR TABLE `database_name`.`table_name`;
OPTIMIZE TABLE `database_name`.`table_name`; تعمیر تمام جداول یک دیتابیس
mysqlcheck -u root -p --auto-repair --optimize database_name تعمیر تمام دیتابیسها
mysqlcheck -u root -p --auto-repair --optimize --all-databases بازیابی از بکاپ (در صورت خرابی کامل)
اگر ساختار Schema بهطور کامل خراب شد:
systemctl stop mysql
rm -rf /var/lib/mysql/*
cp -r /root/mysql_data_backup/* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql یا بازیابی از SQL Dump:
mysql -u root -p < /root/all_databases_backup.sql جمعبندی: Downgrade کردن نسخه Mysql در Cpanel
ما در این مقاله، فرآیند حیاتی Downgrade کردن نسخه Mysql در Cpanel را بهطور کامل بررسی کردیم. از لزوم تهیه بکاپهای کامل شروع کردیم و سپس، راهنمای گامبهگام دسترسی از طریق SSH و cPanel Scripts را مرور کردیم.
💡 نکات کلیدی:
- WHM رابط گرافیکی برای Downgrade ندارد
- بکاپگیری قبل از عملیات ضروری است
- استفاده از
/var/cpanel/cpanel.configبرای تعیین نسخه - اجرای
mysql_upgrade --forceپس از Downgrade - تست و عیبیابی با REPAIR و OPTIMIZE
اگرچه هدف ما آموزش بود، اما تیم وب داده همواره در کنار شماست تا عملیاتهای پرریسک مانند Downgrade را با اطمینان کامل برای شما انجام دهد.
بهترین VPS های وبداده حاصل مجازی سازی اختصاصی با منابع بالا و قدرتمند در بیش از 9 لوکیشن از آسیا تا اروپا و آمریکا…
برای مشاهده موقعیتهای
سرور مجازی وبداده
روی دکمه زیر کلیک کنید
سرور مجازی وبداده
روی دکمه زیر کلیک کنید
❓ در صورتی که سوالی داشتید، میتوانید در بخش نظرات با ما در ارتباط باشید.
سوالات متداول از Downgrade کردن نسخه Mysql در Cpanel
1- آیا Downgrade کردن همیشه منجر به از دست رفتن داده میشود؟
خیر، اگر قبل از عملیات یک بکاپ کامل تهیه کنید، در بدترین حالت میتوانید دادههای خود را بازیابی کنید. از دست رفتن دادهها زمانی اتفاق میافتد که ساختار دیتابیس خراب شود و شما هیچ بکاپی نداشته باشید.
2- آیا میتوانم از WHM برای Downgrade استفاده کنم؟
خیر، WHM فقط ابزار آپگرید دارد. برای Downgrade باید از SSH و دستورات خط فرمان استفاده کنید.
3- بهترین نسخه برای برگشت کدام است؟
بهترین نسخه، نسخهای است که قبلاً روی سرور شما کار میکرد. توجه کنید:
- MySQL 5.7: به EOL رسیده (پشتیبانی امنیتی ندارد) – توصیه نمیشود
- MySQL 8.0: نسخه پایدار فعلی
- MariaDB 10.3/10.4: سازگاری بالا با سیستمهای قدیمی
- MariaDB 10.5/10.6: نسخههای جدیدتر با قابلیتهای بیشتر
4- اگر پس از Downgrade، وبسایتها هنوز خطا دادند چهکار کنم؟
مشکل احتمالاً از نسخه PHP یا خود کد است. نسخه PHP را به یک نسخه سازگار تغییر دهید و لاگهای سرور را بررسی کنید:
tail -f /usr/local/apache/logs/error_log 



