What Risks Does MySQL 5.7 End‑of‑Life Pose and How to Migrate to Domestic Open‑Source Forks?

MySQL 5.7 End‑of‑Life (EOL) and Associated Risks

Oracle announced that MySQL 5.7 will reach EOL in October 2023. After this date the version will no longer receive security patches, bug fixes, or official support, exposing production systems to several concrete risks:

Unpatched security vulnerabilities – new exploits can affect an unmaintained server, leading to unauthorized access, data leakage, or denial‑of‑service attacks.

Compliance violations – many regulatory frameworks require supported software; running an EOL database may breach those requirements.

Performance and stability degradation – future OS or hardware updates may be incompatible, causing slower query response or crashes.

Missing feature improvements – optimisations, new SQL syntax, and scalability enhancements introduced in later MySQL releases are unavailable.

Loss of vendor support – Oracle will not provide troubleshooting assistance, increasing mean‑time‑to‑recovery.

Typical Migration Strategies

Continue using MySQL 5.7 (high risk, short‑term only).

Upgrade to a supported Oracle‑maintained version such as MySQL 8.0.

Adopt a domestically maintained open‑source MySQL fork.

Switch to a commercial Chinese database product.

Upgrading to MySQL 8.0 is well documented but only postpones the next EOL. Commercial Chinese databases often involve higher licensing costs and compatibility testing effort.

Why Domestic Open‑Source Forks Are Viable

Domestic forks are built on the same source code base as MySQL (or Percona Server) and therefore retain binary compatibility with MySQL 5.7/8.0. They offer:

Low migration effort – existing client libraries and tools continue to work.

Reduced conversion cost – no need for extensive schema rewrites.

Alignment with national open‑source policies and local technical support.

Case Study: GreatSQL

GreatSQL is an open‑source MySQL‑compatible distribution maintained by Wanli Database. It is based on Percona Server and supports both MySQL 5.7 and 8.0 binaries.

Key Technical Features

Enterprise‑grade high availability : dynamic VIP assignment, intelligent leader election, and optional arbitration nodes for MySQL Group Replication (MGR).

Geographic tagging and read/write node binding to improve latency‑aware routing.

Performance optimisations : InnoDB parallel query support; TPC‑H benchmark shows 15‑40× throughput improvement over vanilla MySQL.

Security extensions : national‑cipher (SM2/SM3/SM4) support integrated into the MySQL keyring plugin, enhancing data‑at‑rest protection.

Release cadence : a new version is released roughly every six months; five major releases (including 5.7‑compatible and 8.0‑compatible) are publicly available.

Deployment Validation

GreatSQL has been deployed in production for Meizhou KeShang Bank’s data‑security platform. The deployment demonstrated high availability under financial‑grade workloads and passed security assessments by the China Academy of Information and Communications Technology.

Practical Migration Guidance

Assess current MySQL 5.7 instances for compatibility (character set, storage engine, plugin usage).

Choose a GreatSQL release that matches the existing major version (e.g., GreatSQL‑5.7.x for direct binary drop‑in).

Replace the MySQL binary path with the GreatSQL binary; update my.cnf only if required for new features (e.g., group_replication settings).

Run mysqld --initialize on a test environment, import a recent logical backup, and execute the application test suite.

Validate performance using representative workloads (e.g., TPC‑H or custom OLAP queries) to confirm expected speed‑up.

Enable the national‑cipher keyring_file plugin if compliance mandates SM algorithms.

Plan a phased rollout: start with non‑critical services, monitor replication health, then extend to critical workloads.

Conclusion

MySQL 5.7’s EOL creates tangible security, compliance, and stability risks. While upgrading to MySQL 8.0 is a straightforward stop‑gap, domestically maintained open‑source forks such as GreatSQL provide a low‑cost, compatible, and policy‑aligned path forward. Their enterprise‑grade features, regular release cadence, and proven deployments in financial systems make them a practical choice for Chinese enterprises seeking to mitigate EOL exposure without abandoning the MySQL ecosystem.