If you ran MySQL Enterprise Monitor, you've made this move once already. MEM reached end of life in January 2025, and Oracle's guidance was explicit: migrate to Oracle Enterprise Manager for MySQL, the plug-in that brought your MySQL targets into the Oracle EM console. A lot of teams did exactly that. It was the sensible call, since the plug-in came at no extra cost with a commercial edition and ran in the console they already operated for the rest of the estate.
Oracle has now published a deprecation notice for the EM plug-in as well, through My Oracle Support, its standard channel for lifecycle updates to supported customers. If you run the plug-in and haven't seen it yet, check MOS or ask your Oracle account team. Taken together with MEM's retirement, it puts a practical question in front of every team with MySQL targets in the console: what provides continuity from here?
Here's the part that matters if you're the one running these systems. The MySQL Plug-in for Oracle Enterprise Manager from Integration Plumbers, entering Early Access on July 31, 2026, picks up where Oracle's plug-in leaves off. It runs in the same console with the same operational model, restores the MEM capabilities the Oracle plug-in didn't include (backup visibility, curated thresholds, version end-of-life advisories), and its collection layer is built for MySQL 8.4, where monitoring written for older releases breaks quietly.
This post has four parts: how we got from MEM to here, what the Oracle plug-in covered and what it didn't, the 8.4 change that breaks old monitoring, and what our plug-in restores and builds forward.
1. How we got here
MySQL Enterprise Monitor was the closest thing the MySQL world had to a purpose-built monitoring console. It shipped sensible alert thresholds out of the box, it watched your backups, and it ran a catalog of advisors that told you when an instance was misconfigured or running on a version that had aged out of support. It reached end of life on January 1, 2025, and its documentation was retired from dev.mysql.com in early 2026; the pages survive now mostly in the downloadable manual and the Wayback Machine.
Oracle's EOL notice told MEM users where to go next: Oracle Enterprise Manager for MySQL, the plug-in that puts MySQL databases, InnoDB Clusters, and ClusterSets into the Oracle EM console as first-class targets. For enterprises already running Oracle EM for the rest of their estate, this was a reasonable landing spot, and it was actively maintained. The 13.5.6 release shipped in April 2026, the same month Oracle revised the plug-in's user guide for the EM 24ai platform.
Oracle has since published a deprecation notice for the plug-in through My Oracle Support, its standard channel for lifecycle guidance. For teams that migrated after MEM's retirement, the practical effect is one more planning exercise, and this time the opportunity to land on a plug-in built to stay in the console for the long term.
2. What the Oracle plug-in carried, and what it didn't
Credit where due: the Oracle plug-in was a real product. It collected around 500 metrics across roughly ninety categories, shipped a Query Analyzer, monitored InnoDB Cluster and ClusterSet topologies, supported autodiscovery, and could watch a remote MySQL host without installing an agent on it.
It was scoped, though, as a subset of MEM rather than a full successor, and the documentation is straightforward about that: the user guide describes the plug-in as based on MySQL Enterprise Monitor but containing "only a subset of MEM Advisors and graphs." The subset had a shape, and if you came from MEM, the missing pieces were exactly the ones you noticed:
- The backup dashboard didn't come across. MEM read the
backup_historyandbackup_progresstables that MySQL Enterprise Backup maintains and turned them into a dashboard: last successful full, last failure, run time and lock time history, and a coverage view that flagged instances with no configured backup at all. The Oracle plug-in has no equivalent. You get alerted on CPU and connections, not on "no successful backup in four days." - The advisor catalog came across in reduced form. MEM ran fourteen advisor categories. The plug-in ships five compliance rule groups totaling twenty-nine rules. Security alone went from roughly two dozen MEM advisors (anonymous accounts, root without password, insecure password hashes, privilege alterations) to five rules.
- The version advisor wasn't included. MEM had an advisor that flagged when an instance was no longer eligible for Oracle Premier Support because its version had aged out. With 8.0 community support ending in April 2026, that is precisely the check estates needed this year, and the plug-in doesn't have it.
So even before the deprecation notice, teams that moved from MEM to the plug-in were working around a gap. The notice now adds a planning horizon for the parts that did carry over.
3. The 8.4 change that breaks old monitoring
While all of this was happening, MySQL itself moved. 8.0 community support ended in April 2026, 8.4 is the LTS release everyone is migrating onto (supported through April 2029), and 8.4 did something monitoring tools have to reckon with: it removed the legacy replication interface.
SHOW SLAVE STATUS is gone. So are the Com_slave_* status counters and the master_info_repository settings that a lot of monitoring was built on. The replacement syntax (SHOW REPLICA STATUS, SHOW BINARY LOG STATUS, the REPLICA/SOURCE terminology) has been available for years, but plenty of collection code never moved to it.
What breaks depends on how your monitoring was written, and neither way is good. Tooling that still issues the removed commands gets a syntax error on 8.4: the query fails outright, which at least announces itself. Tooling that reads the old Com_slave_* counters gets something quieter and worse, because those variables simply stop appearing in SHOW STATUS. The metric doesn't error. It goes blank, which reads as "fine" right up until you need it during a failover.
This is the practical reason a deprecation notice matters for planning. A product in wind-down naturally receives less investment in tracking the server's changes, and a version migration is exactly when you most want your monitoring to keep pace.
4. Picking up where the plug-in leaves off
The MySQL Plug-in for Oracle Enterprise Manager from Integration Plumbers is built for the operators navigating this transition. If you deployed Oracle's plug-in, the model will feel familiar: MySQL targets in the Oracle EM console you already run, monitored through your existing agents, feeding the incident rules and notification chains you already maintain. No new console to learn, no separate pane of glass to justify.
On that foundation, the capabilities MEM was actually valued for come back:
- Your backups are visible again. The plug-in watches MySQL Enterprise Backup (and Percona XtraBackup) history and alerts on the things that matter: a failed backup, no successful backup in N days, a cluster member that isn't being backed up at all. This is the piece neither the Oracle plug-in nor any major APM tool picked up when MEM retired.
- The thresholds ship set. Curated WARNING and CRITICAL defaults arrive with the plug-in for replication lag, connection saturation, buffer-pool health, and backup age, so a freshly added target is useful on day one instead of silent until you tune it.
- End-of-life becomes a screen. A version advisory flags instances running on a release that's aged out of support, the same idea as MEM's "no longer eligible" advisor, now a check you can hand to an auditor. The fuller advisor catalog that made MEM valuable is being rebuilt on Oracle EM's own compliance framework as the next layer on top.
And it's a clean rebuild, which is an advantage. The collection layer is built 8.4-first, speaking the current replication syntax so it keeps working through the version you're migrating onto, with the older 8.0 tier handled as a deprecated, version-gated path rather than an afterthought. It runs from a single read-only grant (SELECT, PROCESS, REPLICATION CLIENT), a smaller footprint than the five privileges Oracle's plug-in required, with no SUPER, TLS that fails closed rather than silently dropping to plaintext, and your choice of a local or remote agent.
MEM has retired, and Oracle has signaled that the EM plug-in will wind down in time. The reasons you ran them don't have to retire with the products, though: knowing your backups are good, getting alerted before a threshold becomes an outage, being told when an instance has aged off a supported version. Those capabilities stay in the console you already use for the rest of your estate, rebuilt for the MySQL version you're actually running, on a roadmap that gets longer from here.
If you've re-platformed your MySQL monitoring once since 2025, you shouldn't have to keep doing it. That's the point of building this inside Enterprise Manager rather than beside it.
This is the fourth post in a series on the blind spots your estate monitoring leaves across MySQL, SQL Server, and DB2. The earlier three were The Backup You Can't See, on whether last night's backup actually succeeded; The DR-Readiness Gap, on whether a "synchronized" cluster could really fail over without losing data; and SQL Server 2016 End of Support, on the July 14 version cliff. This one traced the path from MEM's retirement through the Oracle plug-in's deprecation, what that plug-in carried and what it didn't, the 8.4 change that breaks older monitoring, and what our plug-in brings back into Oracle Enterprise Manager.
Get Early Access
Backup monitoring, curated thresholds, the version-EOL advisory, and an 8.4-safe collection layer arrive with the MySQL Plug-in for Oracle Enterprise Manager, and Early Access opens July 31, 2026. Re-platformed once already? Plan the next step on your own schedule this time. Learn more and sign up:
We bring the same least-privilege, TLS-first approach to the Microsoft SQL Server and DB2 plug-ins, too.
Next in the series: No Cliff, No Drama, on monitoring DB2 11.5 and 12.1, and the new ground ahead in z/OS and AI Query Optimizer coverage.
Didn't Oracle already replace MEM? Is that replacement being discontinued too?+
Yes. When MySQL Enterprise Monitor reached end of life in January 2025, Oracle directed customers to Oracle Enterprise Manager for MySQL, its EM plug-in, and many teams migrated. Oracle has since published a deprecation notice for that plug-in as well, through My Oracle Support. If you run the plug-in, confirm the details through MOS or your Oracle account team.
What did Oracle's plug-in not carry over from MEM?+
The user guide describes the plug-in as containing "only a subset of MEM Advisors and graphs." In practice the gaps were the ones MEM users relied on most: there's no backup dashboard, the advisor catalog went from fourteen categories to five compliance rule groups (twenty-nine rules total, with Security going from roughly two dozen advisors to five), and the version-EOL advisor that flagged unsupported instances wasn't included.
Why does MySQL 8.4 break monitoring that worked on 8.0?+
8.4 removed the legacy replication interface. SHOW SLAVE STATUS, the Com_slave_* status counters, and the master_info_repository settings are gone. Collection code that still issues the old commands gets a syntax error; code that reads the old counters gets something worse, because those variables simply stop appearing in SHOW STATUS, so the metric goes blank instead of erroring. A tool in wind-down can't be expected to track those changes going forward.
Does your plug-in monitor backups the way MEM did?+
Yes, and it's the capability neither the Oracle plug-in nor a general APM tool picked up when MEM retired. It reads MySQL Enterprise Backup history (and Percona XtraBackup) and alerts on what matters: a failed backup, no successful backup in N days, or a cluster member that isn't being backed up at all, collected over a standard connection with no agent on the database host.
I'm on Oracle's plug-in today. Why move now instead of later?+
Two reasons stack up. The deprecation notice gives the plug-in a defined horizon, and it was already missing MEM capabilities you may be working around. Meanwhile 8.4 is changing the replication surface underneath any tool that isn't actively tracking it. Moving to a plug-in that's built 8.4-first and restores the backup, threshold, and version-EOL capabilities means you re-platform once, deliberately, rather than again under pressure during a migration.
What access does the plug-in need on each instance?+
One read-only login with SELECT, PROCESS, REPLICATION CLIENT, a smaller footprint than the five privileges Oracle's plug-in required. There's no SUPER and no operating-system access, and the TLS connection fails closed rather than silently dropping to plaintext. You can point it at each instance through a local or a remote agent, whichever fits your topology.
