Majisemi 舉辦網路研討會：探討「為何 MySQL 8.0 EOL 遷移決策停滯不前」

MySQL 8.0 EOL 對應：DBaaS 環境中的影響與風險

MySQL 8.0 的終止服務（EOL）即將於 2026 年 4 月到期。許多企業深知其必要性，卻因無法判斷從何處著手或如何設定優先順序而停滯不前。 特別是對於在生產環境中使用 Amazon RDS、Aurora 或 Cloud SQL 等 DBaaS 的企業而言，考量因素瞬間增加，例如因延伸支援（Extended Support）導致的成本上升、相容性、效能影響與停機風險，使得決策變得極為困難。這常導致許多企業陷入「僅進行調查卻無法做出決定」，或是因為焦慮而不斷推遲的情況。

為何 EOL 遷移變得困難

EOL 遷移不僅僅是版本升級，更需要連續進行多項決策，包括： - 判斷影響範圍 - 風險梳理 - 釐清討論焦點 - 分配企業內部與供應商的職責

然而，許多團隊在未釐清上述重點的情況下貿然開始作業，最終導致意料之外的トラブル（問題）與成本增加。

依據 DBaaS 提供商整理對應方針的必要性

在規劃 EOL 遷移時，針對不同的 DBaaS（如 RDS、Aurora、Cloud SQL），考量重點各異。例如： - Amazon RDS for MySQL：升級路徑與相容性風險 - Amazon Aurora MySQL：對獨家功能的依賴性與效能特性 - Google Cloud SQL：遷移選項與營運設計的差異

若未理解上述差異就盲目進行，可能導致停機、效能劣化以及工時超出預期，進而直接影響業務。

本研討會內容

本研討會聚焦於 DBaaS 環境（RDS/Aurora/Cloud SQL）下的 MySQL 8.0 EOL 遷移，將成功的升級策略整理為「決策軸」。目的不僅是程序說明，而是讓企業能夠自主判斷需要考量什麼、哪裡需要謹慎，以及如何整理作業流程。

主要學習內容包括： - EOL 遷移所需掌握的影響範圍與風險概覽 - MySQL 8.0 EOL 會發生什麼（包含 DBaaS 特有觀點） - RDS / Aurora / Cloud SQL 各自的對應方針與注意事項 - 基於服務特性的升級路徑構思 - 推動決策流程的視角 - 包含驗證與測試的實務操作方法 - 升級前後常見的錯誤與處理對策 - 常見的失敗模式與規避方法

推薦參與對象

- 在生產環境中使用 Amazon RDS / Aurora / Cloud SQL 的企業人員 - 使用 MySQL 8.0 但尚未著手規劃 EOL 遷移的企業 - 負責技術決策的資訊系統部門主管、開發負責人或 IT 負責人 - 需要憑自身判斷來解釋升級影響、風險與成本的人員 - 不希望完全依賴供應商，想要自主掌控決策過程的人員

主辦單位 - 主辦：株式會社 Pasona Data & Design - 協力：Majisemi 株式會社