Nâng cấp Magento 2.4.5 lên 2.4.8: Tháo Ngòi Nổ “Nợ Kỹ Thuật” Trước Thềm AWS Cắt Hỗ Trợ MySQL 8.0

Answer-first: Đừng coi việc nâng cấp từ Magento 2.4.5 lên 2.4.8 là một bản vá phần mềm thông thường. Thực chất, đây là một cuộc đại tu hạ tầng toàn diện (nhảy cóc - Leapfrog strategy) buộc phải thực hiện trước ngày 31/07/2026 — thời điểm AWS RDS ngừng hỗ trợ MySQL 8.0. Bài viết này bóc tách 6 đứt gãy kiến trúc chí mạng (PHP 8.4, OpenSearch 2.19, Uppy) và cung cấp lộ trình di chuyển Blue/Green Deployment.

1. Quả Bom “Nợ Kỹ Thuật” Mang Tên Cổ Tức Đám Mây

Trong thế giới E-commerce B2B và B2C quy mô lớn, nếu hệ thống của bạn vẫn đang chạy Magento 2.4.5 ở thời điểm hiện tại, bạn đang ngồi trên một quả bom nổ chậm mang tên Technical Debt (Nợ kỹ thuật). Ngòi nổ của quả bom này không nằm ở bản thân mã nguồn Magento, mà nằm ở hệ sinh thái hạ tầng bên dưới:

1. Thông báo “tử hình” MySQL 8.0 từ AWS: Amazon Web Services đã chính thức xác nhận MySQL 8.0 sẽ đạt End of Standard Support (EoSS) vào ngày 31/07/2026. Sau ngày này, mọi database chưa được nâng cấp sẽ bị ép chuyển sang trạng thái RDS Extended Support, kéo theo khoản phụ phí khổng lồ (Surcharge) tính trên mỗi vCPU chỉ để nhận các bản vá bảo mật.
2. Sự sụp đổ của PHP 8.1: Magento 2.4.5 dựa trên nền tảng PHP 8.1, một phiên bản ngôn ngữ đã lỗi thời và không còn nhận được các bản cập nhật bảo mật chủ động từ cộng đồng.

Việc “cố đấm ăn xôi” không chịu nâng cấp không chỉ làm phình to chi phí vận hành (TCO), mà còn đặt doanh nghiệp vào nguy cơ vi phạm tiêu chuẩn bảo mật thẻ thanh toán (PCI Compliance). Chặng đến bắt buộc và mang tính chiến lược dài hạn (Leapfrog) của chúng ta là Magento 2.4.8 LTS, hoạt động trên PHP 8.4 và MariaDB 11.4 / MySQL 8.4.

2. 6 Đứt Gãy Kiến Trúc Chí Mạng (The 6 Fatal Breaking Changes)

Một sai lầm cực kỳ phổ biến của các CTO và Tech Lead là giao phó việc nâng cấp này cho một bạn Dev Junior với lệnh composer update. Thực tế, bước nhảy “nhảy cóc” từ 2.4.5 thẳng lên 2.4.8 chứa đựng 6 “tử huyệt” kiến trúc có thể đánh sập hệ thống ngay lập tức.

Tử huyệt 1: Lựa Chọn Database Ngã Ba Đường (MySQL 8.4 hay MariaDB 11.4?)

Khi nâng cấp Database Engine từ MySQL 8.0 lên bản mới (như khuyến nghị của AWS RDS), bạn sẽ phải đối mặt với một quyết định kiến trúc lớn. Oracle đã mặc định vô hiệu hóa plugin xác thực huyền thoại mysql_native_password trên MySQL 8.4.

• Tác động: Nếu các ứng dụng bên thứ 3 (ERP, CRM) sử dụng thư viện kết nối cũ chưa hỗ trợ caching_sha2_password, toàn bộ hệ thống sẽ báo lỗi Connection Refused.
• Xử lý: Phải chạy lệnh SELECT user, plugin FROM mysql.user; để di chuyển user cũ sang chuẩn SHA2 trước khi nâng cấp DB.

[!TIP] Architecture Decision: MariaDB 11.4 LTS vs MySQL 8.4 LTS Dù hỗ trợ cả hai, nền tảng đang ngầm dịch chuyển sang MariaDB 11.4 vì ưu thế vượt trội về hiệu năng. MariaDB bản Community (miễn phí) có sẵn tính năng Thread Pooling, giúp server chịu tải mượt mà ở mức 200+ concurrent connections trong các kỳ Flash Sale. Tính năng này trên MySQL bị khóa ở bản Enterprise (RDS mặc định không có). Tuy nhiên, nếu roadmap hạ tầng của bạn hướng tới Amazon Aurora, hãy kiên định với MySQL 8.4 để đảm bảo tính tương thích.

Tử huyệt 2: Lỗi chí mạng Address Validation (Khách mất tiền oan)

Một lỗi ngầm (Bug) cực kỳ nguy hiểm ở bản 2.4.8 đã được ghi nhận: hệ thống từ chối các tên Thành phố (City) chứa dấu chấm.

• Tác động: Nếu khách hàng nhập địa chỉ là "Tp. HCM" hoặc "St. Helens", luồng Checkout sẽ bị sập (Silent Order Failure). Khách hàng không thể thanh toán nhưng không rõ nguyên nhân.
• Xử lý: Tech Lead phải chú ý cài đặt ngay bản vá ACSD-67904 của Adobe sau khi nâng cấp để tránh mất doanh thu oan uổng.

Tử huyệt 3: Khai tử Elasticsearch — Cơn Ác Mộng OpenSearch 2.19

Từ phiên bản 2.4.6, Adobe đã chính thức rời bỏ Elasticsearch do các mâu thuẫn về giấy phép (Licensing), và ép buộc toàn bộ hệ sinh thái chuyển sang dùng OpenSearch (bản 2.4.8 yêu cầu phiên bản 2.19).

• Tác động: OpenSearch 2.19 có một quy định cực kỳ hà khắc: Tên Index (Index Prefix) bắt buộc phải viết thường toàn bộ (lowercase).
• Rủi ro: Nếu trong Magento Admin (Stores > Configuration > Catalog Search), tiền tố index của bạn có chứa chữ in hoa (ví dụ: Magento_Production), toàn bộ tính năng tìm kiếm sản phẩm và trang danh mục (Catalog Category) sẽ tê liệt ngay sau khi nâng cấp. Lỗi “Invalid Index Name” sẽ tràn ngập file log.

Tử huyệt 4: PHP 8.4 Strict Types & Cổng Thanh Toán

Magento 2.4.8 yêu cầu PHP 8.3 hoặc 8.4. Phiên bản PHP 8.4 cực kỳ khắt khe về kiểu dữ liệu (Strict Typing) và khai tử hoàn toàn các tính năng cũ.

• Tác động: Đa số các Extension cổng thanh toán nội địa (Momo, VNPay, ZaloPay) hoặc cổng giao hàng được viết từ thời 2.4.4 sẽ văng lỗi FATAL ERROR: TypeError ngay tại khoảnh khắc khách hàng nhấn nút “Place Order”.
• Xử lý: Đây không phải là việc sửa code, mà là việc quản trị Vendor. Bạn phải rà soát file composer.json và đảm bảo toàn bộ 3rd-party vendor đã cung cấp gói (package) tương thích PHP 8.4.

Tử huyệt 5: Sự bốc hơi của TinyMCE và jQuery/fileUploader

Bản nâng cấp 2.4.8 thay đổi chóng mặt ở lớp Frontend Admin:

• Tác động 1: Trình soạn thảo văn bản mặc định (WYSIWYG) TinyMCE đã bị thay thế hoàn toàn bởi HugeRTE. Bất kỳ module Blog hay Page Builder bên thứ 3 nào dùng JS cũ sẽ bị trắng trang.
• Tác động 2: Thư viện upload cũ bị thay thế bằng Uppy. Mọi module có chức năng upload hình ảnh/tài liệu trong Admin sẽ sập nếu không được refactor lại theo chuẩn Uppy.

Tử huyệt 6: Cơ chế Default Indexer thay đổi

• Tác động: Từ bản 2.4.8, chế độ Indexer chuyển mặc định từ Update on Save sang Update by Schedule.
• Rủi ro: Mặc dù điều này giải cứu hiệu năng cho Admin Panel khi chỉnh sửa hàng loạt sản phẩm, nhưng nó bẻ gãy các luồng API đồng bộ giá Real-time từ hệ thống ERP bên ngoài. Dữ liệu giá/tồn kho sẽ bị delay theo nhịp Cronjob (thường là 1 phút) thay vì cập nhật ngay lập tức.

3. Lộ Trình Di Chuyển Zero-Downtime (Blue/Green Deployment)

Đối mặt với 6 rủi ro trên, việc áp dụng chiến lược In-place Upgrade (Nâng cấp đè trực tiếp lên Server Production) là một hành động “tự sát”. Dưới đây là lộ trình 4 Phase chuẩn Enterprise:

1. Phase 1: Infrastructure & Dependency Audit (1 Tuần)

   • Clone toàn bộ Production xuống môi trường Staging.
   • Nâng cấp OS: Cài PHP 8.4, dựng OpenSearch 2.19, và clone DB sang MariaDB 11.4 (hoặc MySQL 8.4).
   • Audit composer.json: Liệt kê 100% các extension cần mua bản update.

2. Phase 2: Core Upgrade & Refactoring (2 Tuần)

   • Chạy lệnh cập nhật Core với cờ -W (with-dependencies) để bắt Composer giải quyết xung đột:

     composer require-commerce magento/product-community-edition 2.4.8 -W
     

   • Chạy bin/magento setup:di:compile. Mỗi dòng chữ Đỏ (Error) ném ra ở đây là một file PHP bị lỗi Strict Types cần Dev sửa tay. Đổi Index Prefix thành chữ thường và chạy lại indexer:reindex.

3. Phase 3: End-to-End (E2E) Testing (1 Tuần)

   • Dựng kịch bản Blackbox Testing. Bắt buộc test kỹ luồng Thanh toán (Mock Payment) và tích hợp ERP Sync. Một lỗi lọt ra ngoài có thể làm bốc hơi doanh thu của cả ngày.

4. Phase 4: Cut-over lên Production (15 Phút Downtime)

   • Ứng dụng mô hình Amazon RDS Managed Blue/Green Deployments để đồng bộ Real-time DB từ cụm 8.0 (Blue) sang cụm 8.4 (Green).
   • Freeze Production hiện tại, copy codebase bản mới lên server Green.
   • Switchover DNS từ Blue sang Green. Mọi thứ hoàn tất.

4. Dự Toán Thời Gian (Effort Estimation)

Một dự án nâng cấp quy mô trung bình (khoảng 20 - 30 Custom Extensions) lên phiên bản 2.4.8 sẽ tiêu tốn khoảng 180 giờ làm việc (Man-hours), tương đương 4.5 Tuần với team size 3 người.

Kết luận

Nâng cấp Magento 2.4.8 LTS không phải là một dự án “Nice-to-have” (có thì tốt). Đó là một mệnh lệnh sinh tồn (Survival Mandate) đối với hệ thống E-commerce khi đồng hồ đếm ngược của AWS RDS MySQL 8.0 EoSS đang nhích dần về vạch đích. Bằng cách nhìn nhận nó như một dự án di chuyển hạ tầng toàn diện và áp dụng chiến lược Blue/Green, các Tech Lead hoàn toàn có thể vô hiệu hóa quả bom “Nợ kỹ thuật” này một cách êm ái.

(Bài viết này thuộc chuỗi phân tích Kiến trúc Hệ thống E-commerce. Bạn có thể tham khảo thêm các góc nhìn chiến lược khác dưới đây):

• Có nên tiếp tục đầu tư vào Magento trong năm 2026?
• Khi nào nên chuyển đổi từ Magento sang Microservices?
• Kiến trúc Event-Driven chia tách Đơn hàng (Order Splitting)