RDS MySQL 8.0 از Standard Support خارج شد؛ حالا چه کنیم؟
Amazon RDS for MySQL 8.0 در 31 ژوئیه 2026 از Standard Support خارج شد و از امروز 1 اوت، ماندن روی این major version وارد مسیر Extended Support پولی می شود. در این راهنما می بینید چه چیزی واقعاً عوض شده، چه زمانی باید به MySQL 8.4 بروید و چطور migration را با pre-check، Blue/Green و rollback کم ریسک کنید.
از 31 ژوئیه چه اتفاقی برای RDS MySQL 8.0 افتاد؟
Amazon RDS for MySQL 8.0 در 31 ژوئیه 2026 به پایان Standard Support رسیده است. این اتفاق به معنی خاموش شدن فوری دیتابیس های 8.0 نیست؛ تفاوت مهم این است که از 1 اوت 2026، نمونه هایی که روی این major version باقی مانده اند وارد مسیر RDS Extended Support می شوند و هزینه این پشتیبانی افزوده آغاز می شود. AWS برای MySQL 8.0 پایان Extended Support را 31 ژوئیه 2029 اعلام کرده است. در عمل، تیم ها سه انتخاب دارند: مهاجرت به MySQL 8.4، ماندن موقت روی 8.0 با هزینه Extended Support، یا بازطراحی برنامه مهاجرت برای زمانی بسیار نزدیک.
چیزی که نباید انجام دهید این است که فقط به دلیل روشن بودن instance نتیجه بگیرید وضعیت عادی است. Standard Support یک مرز عملیاتی است: بعد از آن، هزینه و سیاست patching تغییر می کند و باقی ماندن روی نسخه قدیمی باید تصمیم آگاهانه و زمان دار باشد. AWS Extended Support همچنان critical و high CVEها، patchهای مشکلات بحرانی و امکان استفاده از پشتیبانی استاندارد AWS را فراهم می کند، اما این سرویس پولی است و برای خرید زمان طراحی شده، نه تبدیل 8.0 به مقصد دائمی معماری.
سه مسیر تصمیم گیری: Upgrade، Extended Support یا تعویق کنترل شده
| مسیر | مزیت | ریسک/هزینه | مناسب برای |
|---|---|---|---|
| ارتقا به MySQL 8.4 | خروج از Extended Support و رفتن به major پشتیبانی شده | نیاز به تست سازگاری و برنامه downtime/rollback | اغلب workloadهای تولیدی با امکان تست |
| ماندن موقت روی 8.0 با Extended Support | زمان بیشتر برای تست و رفع incompatibility | هزینه اضافی و بدهی فنی ادامه دار | سیستم های حساس که مهاجرت فوری پرریسک است |
| تعویق بدون برنامه | هیچ مزیت واقعی | افزایش هزینه، ریسک عملیاتی و migration اضطراری در آینده | توصیه نمی شود |
برای اکثر تیم ها پاسخ صحیح «ارتقا همین دقیقه» نیست؛ پاسخ صحیح این است که امروز migration plan زمان دار داشته باشید. دیتابیس production معمولاً به ORM، connector، stored procedure، parameter group، authentication plugin، read replica، ETL و ابزارهای observability متصل است. major upgrade ممکن است هرکدام از این نقاط را تحت تأثیر بگذارد. بنابراین Extended Support می تواند یک buffer منطقی باشد، اما فقط وقتی milestone خروج از آن، owner و deadline مشخص دارید.
چرا مهاجرت 8.0 به 8.4 فقط تغییر عدد نسخه نیست؟
AWS این ارتقا را major engine version upgrade می داند و آن را خودکار انجام نمی دهد. MySQL 8.4 تغییرات رفتاری و تنظیماتی دارد که باید در محیط شبیه production بررسی شوند. نمونه مهمی که AWS صریحاً ذکر می کند authentication است: در RDS for MySQL 8.4، mysql_native_password به صورت پیش فرض غیرفعال است و caching_sha2_password مسیر پیش فرض محسوب می شود. اگر سرویس قدیمی، driver یا حساب دیتابیس شما هنوز به روش قبلی وابسته باشد، ممکن است مشکل نه در خود دیتابیس بلکه در لحظه اتصال برنامه ظاهر شود.
قبل از مهاجرت، inventory بسازید: نسخه و minor دقیق instance، parameter group، option group، accountهای دیتابیس و authentication plugin آن ها، engine-specific SQL modeها، event scheduler، replication topology، dependencyهای application، نسخه connectorها و هر ابزار backup یا CDC. این inventory باعث می شود تست شما به چند query دستی محدود نشود. هدف این است که بفهمید «چه چیزهایی فرض کرده اند MySQL 8.0 است» و آن فرض ها را قبل از cutover پیدا کنید.
Pre-check را روی Clone اجرا کنید، نه در اوج بار Production
AWS در راهنمای عملی خود توصیه می کند MySQL Shell check-for-server-upgrade را روی instance بازیابی شده از snapshot اجرا کنید، چون این ابزار metadata را گسترده اسکن می کند و اجرای آن روی production می تواند روی workload اثر بگذارد. خروجی checker یافته ها را به Error، Warning و Notice تقسیم می کند. Errorها می توانند مانع upgrade شوند، Warningها نیاز به ارزیابی موردی دارند و Noticeها بیشتر اطلاعاتی اند. در کنار این ابزار، RDS هنگام major upgrade pre-upgrade validation خودش را نیز اجرا می کند و این دو مجموعه کنترل کاملاً یکسان نیستند.
mysqlsh -- util check-for-server-upgrade \
--user=<user-name> --host=<instance-endpoint> --port=3306 \
--target-version=8.4.xاین فرمان نمونه ای است که AWS در راهنمای مهاجرت آورده است. برای production بهتر است ابتدا snapshot را restore کنید، دسترسی های لازم را روی clone بدهید و checker را همان جا اجرا کنید. سپس یافته ها را تبدیل به backlog مهاجرت کنید: هر Error باید owner و اصلاح مشخص داشته باشد؛ Warningها باید با test case برنامه بررسی شوند؛ و بعد از رفع موارد، checker دوباره اجرا شود. یک بار اجرای precheck بدون چرخه اصلاح و تکرار، assurance کافی ایجاد نمی کند.
Blue/Green چه زمانی از In-place Upgrade بهتر است؟
In-place upgrade از نظر مراحل ساده تر است، اما blast radius بیشتری دارد: همان instance اصلی وارد فرایند major upgrade می شود و rollback آن به سادگی downgrade نسخه نیست. برای سیستم هایی که downtime و rollback برایشان حساس است، AWS Blue/Green Deployments گزینه جذاب تری است. ایده این است که محیط سبز را از production ایجاد کنید، آن را به 8.4 ارتقا دهید، تست های برنامه را روی آن انجام دهید و سپس switchover کنترل شده داشته باشید. این روش هزینه و هماهنگی بیشتری دارد، اما test surface بسیار واقعی تری فراهم می کند.
| معیار | In-place Upgrade | Blue/Green |
|---|---|---|
| پیچیدگی اجرایی | کمتر | بیشتر |
| امکان تست نسخه جدید قبل از Cutover | محدودتر | قوی تر |
| Downtime | به فرایند upgrade وابسته | برای کاهش downtime طراحی شده |
| Rollback | نیازمند برنامه جدا و restore/replication | قابل طراحی با محیط قبلی و replication |
| مناسب برای | سیستم های کم ریسک تر و maintenance window مناسب | Production حساس و workloadهای مهم |
Blue/Green به معنی rollback جادویی نیست. قبل از switchover باید مشخص کنید اگر بعد از cutover خطای منطقی دیده شد چه می کنید و داده های جدید چگونه به محیط قبلی برمی گردند. AWS در راهنمای خود reverse replication یا AWS DMS را به عنوان بخشی از سناریوی rollback بررسی می کند. نکته اصلی این است که rollback باید پیش از migration طراحی و تمرین شود؛ بعد از خراب شدن production زمان مناسبی برای تصمیم گیری درباره جهت replication نیست.
Extended Support را به عنوان هزینه خرید زمان ببینید
Extended Support برای MySQL 8.0 از 1 اوت 2026 وارد مرحله قیمت گذاری سال اول می شود. AWS هزینه را بر اساس vCPU و ساعت محاسبه می کند و Region و مدت ماندن بعد از Standard Support روی رقم نهایی اثر دارند. در Multi-AZ، primary و standby هر دو ظرفیت محاسباتی دارند و اثر هزینه می تواند بیشتر شود. به همین دلیل تصمیم مهاجرت باید در سطح fleet انجام شود؛ شاید یک instance کوچک هزینه قابل تحملی داشته باشد، اما ده ها Multi-AZ database و read replica می توانند هزینه تعویق را به یک آیتم جدی تبدیل کنند.
در این مقاله عدد ثابت قیمت نمی دهیم، چون قیمت به Region، اندازه و توپولوژی بستگی دارد و ممکن است تغییر کند. روش درست این است که inventory RDS را استخراج کنید، vCPU هر instance و replica را محاسبه کنید و هزینه Extended Support را برای دوره واقعی تعویق در AWS Pricing Calculator یا صفحه رسمی قیمت گذاری مدل کنید. سپس آن را کنار هزینه مهندسی migration بگذارید. این مقایسه معمولاً باعث می شود «فعلاً بمانیم» از یک تصمیم مبهم به یک trade-off قابل اندازه گیری تبدیل شود.
Runbook پیشنهادی مهاجرت 8.0 به 8.4
- تمام RDS MySQL 8.0ها را در همه Regionها و حساب ها inventory کنید و owner هرکدام را مشخص کنید.
- نسخه minor دقیق، topology، Multi-AZ، read replica، parameter group و وابستگی های برنامه را ثبت کنید.
- یک snapshot تازه بگیرید و clone قابل تست بسازید؛ pre-upgrade checker و RDS validation را اجرا کنید.
- authentication، connectorها، ORM، queryها، stored procedureها، jobها و ابزارهای CDC/ETL را روی 8.4 تست کنید.
- برای workload مهم Blue/Green را ارزیابی کنید؛ برای workload ساده تر maintenance window و in-place را با downtime واقعی آزمایش کنید.
- قبل از production، backup restore و rollback را تمرین کنید و معیارهای abort را مکتوب کنید.
- cutover را با metricهای latency، error rate، replication lag، connection failure و query performance مانیتور کنید.
- بعد از تثبیت، resourceهای قدیمی و Extended Support dependency را حذف و runbook را برای بقیه fleet تکرار کنید.
پرسش های متداول
آیا RDS MySQL 8.0 از 31 ژوئیه 2026 خاموش می شود؟
خیر. Standard Support پایان یافته و دیتابیس می تواند تحت RDS Extended Support ادامه دهد؛ این مسیر پولی است.
هزینه Extended Support برای MySQL 8.0 از چه زمانی شروع می شود؟
طبق جدول رسمی AWS، قیمت گذاری سال اول Extended Support برای MySQL 8.0 از 1 اوت 2026 آغاز می شود.
مقصد توصیه شده برای ارتقای RDS MySQL 8.0 چیست؟
AWS مسیر major upgrade از MySQL 8.0 به MySQL 8.4 را پشتیبانی و برای خروج از پایان پشتیبانی توصیه می کند.
آیا major upgrade به 8.4 خودکار انجام می شود؟
خیر. AWS major version upgrade را به دلیل ریسک سازگاری خودکار انجام نمی دهد و باید آن را برنامه ریزی و درخواست کنید.
برای کاهش downtime بهتر است In-place برویم یا Blue/Green؟
برای workload حساس، Blue/Green امکان تست محیط سبز و switchover کنترل شده می دهد؛ انتخاب نهایی به topology، downtime و rollback شما بستگی دارد.
قبل از upgrade چه تستی اجرا کنیم؟
AWS استفاده از MySQL Shell check-for-server-upgrade روی clone بازیابی شده از snapshot را در کنار validation داخلی RDS پیشنهاد می کند.
منابع رسمی و جمع بندی
تاریخ های پشتیبانی در تقویم رسمی نسخه های RDS for MySQL آمده است و ماهیت Extended Support در مستندات RDS Extended Support توضیح داده می شود. برای طراحی upgrade، راهبردهای رسمی AWS برای مهاجرت MySQL 8.0 به 8.4 و راهنمای precheck، Blue/Green و rollback دو مرجع اجرایی اصلی هستند.
جمع بندی: امروز مسئله اصلی MySQL 8.0 «آیا هنوز کار می کند؟» نیست؛ مسئله این است که از این نقطه به بعد ماندن روی آن یک تصمیم هزینه دار و زمان دار است. اگر هنوز migration plan ندارید، اول inventory و clone بسازید، سپس compatibility را اندازه بگیرید و بعد روش cutover را انتخاب کنید. Extended Support برای خریدن زمان مفید است، اما بهترین استفاده از آن تبدیل زمان خریداری شده به مهاجرت آزمایش شده و قابل rollback است.
