· ReadyStack
Worked example
Real numbers from this tool, line by line.
Six lines in one sample replication runbook break a MySQL 8.0 to 8.4 upgrade, and backend teams on Amazon RDS for MySQL 8.0 have been paying AWS Extended Support since 1 August 2026 for every month those lines stay in the repo.
The dates come from the AWS release calendar for RDS for MySQL. MySQL 8.0 reached the end of standard support on 31 July 2026. Extended Support year 1 pricing started on 1 August 2026, year 3 pricing starts on 1 August 2028, and Extended Support ends on 31 July 2029. AWS's own pricing example for RDS for MySQL is $0.100 per vCPU-hour in US East (Ohio) for years 1 and 2. One 8-vCPU instance running 8,760 hours a year comes to 8 x $0.100 x 8,760 = $7,008 a year, before the instance price.
So the upgrade to 8.4 LTS is the cheaper path. The trouble is that the upgrade checks look at the wrong place. The RDS pre-upgrade check and util.checkForServerUpgrade() read the objects inside the running database. They do not read the replica rebuild runbook, the cron job that polls replication lag, the my.cnf in the Ansible role or the Terraform parameter group. Those files upgrade without a complaint and then fail the first time someone runs them against 8.4.
Here is the sample file that ships with the extension, and what MySQL 8.4 Upgrade Lint says about it:
STOP SLAVE; -- removed in 8.4: STOP REPLICA CHANGE MASTER TO MASTER_HOST=...; -- removed: CHANGE REPLICATION SOURCE TO ... SOURCE_HOST START SLAVE; -- removed: START REPLICA SHOW SLAVE STATUS; -- removed: SHOW REPLICA STATUS FLUSH HOSTS; -- removed: TRUNCATE TABLE performance_schema.host_cache SET PERSIST_ONLY default_authentication_plugin = ...; -- removed: authentication_policy
Each of the six worked on 8.0. On 8.4 the four SLAVE and MASTER statements are syntax errors, FLUSH HOSTS is gone, and setting the removed variable raises an error. The bundled fixed version of the same file returns zero findings.
The extension carries 34 rules, all taken from the section "Features Removed in MySQL 8.4" of the MySQL 8.4 reference manual. They cover the ten SLAVE and MASTER replication statements, the MASTER_* options of CHANGE REPLICATION SOURCE TO, FLUSH HOSTS, server variables such as binlog_transaction_dependency_tracking, transaction_write_set_extraction, slave_rows_search_algorithms, master_info_repository and have_ssl, the options skip-host-cache, --old, --new and --language, three Group Replication variables, the keyring_file and authentication_fido plugins, and the Com_slave_* status counters that dashboards still read. Two rules only warn: IDENTIFIED WITH mysql_native_password, because 8.4 no longer enables that plugin by default, and DISABLE ON SLAVE in events, which is deprecated.
Why not ask a chatbot? Most public replication tutorials were written for MySQL 5.7 and 8.0, and assistants still produce CHANGE MASTER TO and SHOW SLAVE STATUS. A rule list read from the reference manual does not drift.
The free part is complete on its own. Open any .sql, .cnf, .ini or .tf file in VS Code, or paste it into the web page, and every blocker appears with its line number and the line to write instead.
The next job is the upgrade ticket: one list of every blocker across every runbook, config file and parameter group. That is the paid part, a one-time licence that scans the whole workspace at once and exports one report as Markdown and CSV.
Start with the file you trust least, usually the replica rebuild runbook nobody has run since the last failover.
15 seconds — what it actually does
Questions people ask
What does MySQL 8.4 Upgrade Lint check?
It reads .sql, .cnf, .ini and .tf files line by line and flags 34 statements, options, variables and plugins that MySQL 8.4 removed, such as SHOW SLAVE STATUS, CHANGE MASTER TO, the MASTER_* options, FLUSH HOSTS, default_authentication_plugin and binlog_transaction_dependency_tracking. Every finding gives the line number and the replacement to write instead, for example SHOW REPLICA STATUS.
Who is MySQL 8.4 Upgrade Lint for?
Backend developers, DBAs and platform teams running Amazon RDS for MySQL 8.0, whose standard support ended on 31 July 2026, and who keep replication runbooks, monitoring queries, my.cnf files and Terraform parameter groups in a Git repository. It also fits anyone moving a self-managed MySQL 8.0 server or replica set to the 8.4 LTS release.
Why not rely on the RDS pre-upgrade check or a chatbot?
The RDS pre-upgrade check and util.checkForServerUpgrade() read the objects inside the running database. They never open the runbooks, cron scripts, my.cnf files and parameter groups in your repository, so a SHOW SLAVE STATUS in a monitoring script upgrades cleanly and then fails on 8.4. Chatbots trained on MySQL 5.7 and 8.0 examples still write CHANGE MASTER TO.
What is free and what does the $29 licence add?
Free, with no key: lint the open .sql, .cnf, .ini or .tf file in VS Code or paste it into the web page, and see all 34 rules with the line number and fix on each finding. The $29 one-time licence scans every migration, my.cnf and parameter group in the workspace at once and exports one Markdown and CSV report for the upgrade ticket.
What does staying on RDS MySQL 8.0 cost?
RDS for MySQL 8.0 standard support ended on 31 July 2026, and AWS has billed Extended Support since 1 August 2026. The AWS pricing example is $0.100 per vCPU-hour in US East (Ohio) for years 1 and 2. One 8-vCPU instance running 8,760 hours a year costs 8 x $0.100 x 8,760 = $7,008 a year on top of the instance price.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. MySQL 8.4 Upgrade Lint (RDS MySQL 8.0) checks the file you open against 34 rules from a rule set dated 2026-09-28, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.