Error 2023 occurs when the deprecated SHOW SLAVE HOSTS command is executed against MySQL 8.0.32 or later, where the CR_PROBE_SLAVE_HOSTS client error code was removed.
MySQL Error 2023 CR_PROBE_SLAVE_HOSTS happens when clients call the removed SHOW SLAVE HOSTS command on MySQL 8.0.32+. Update your code to use SHOW REPLICAS or query performance_schema.replication_connection_status and upgrade client libraries to resolve the issue.
Error on SHOW SLAVE HOSTS: CR_PROBE_SLAVE_HOSTS was removed after 8.0.32.
Error 2023 is a client-side exception thrown when a program issues the obsolete SHOW SLAVE HOSTS statement against a MySQL server running version 8.0.32 or later.
The underlying client constant CR_PROBE_SLAVE_HOSTS was deleted, so the library can no longer map the response.
The error surfaces as: "Error on SHOW SLAVE HOSTS: CR_PROBE_SLAVE_HOSTS was removed after 8.0.32." Modern MySQL no longer supports probing for slave hosts this way, reflecting both terminology changes and replication redesign.
The failure appears immediately after the client sends SHOW SLAVE HOSTS or functions that implicitly call it, such as mysqlrpladmin or custom monitoring scripts.
It is common during upgrades where the server jumps past 8.0.32 while legacy code remains unchanged.
Cross-version mismatches also trigger the fault. An older libmysqlclient (or connector) compiled with the deprecated constant will raise error 2023 even if the SQL text is not present, because the symbol no longer exists on the server.
Unhandled Error 2023 breaks replication health checks, orchestration tools, and dashboards that rely on replica discovery.
Production clusters may lose visibility into replica lag and failover readiness, increasing recovery times and operational risk.
Removing the faulty call eliminates noisy logs and lets DevOps teams adopt the supported performance_schema views for replica inventory, aligning with MySQL’s inclusive terminology and feature roadmap.
The primary trigger is the deprecation and removal of SHOW SLAVE HOSTS in MySQL 8.0.32.
Any invocation of that statement will now fail.
Secondary triggers include outdated client libraries referencing the deleted constant, version mismatches between application containers and the upgraded database, and third-party scripts never updated for the new replica schema.
Replace SHOW SLAVE HOSTS with supported alternatives, upgrade connectors, and ensure server and client versions align.
Galaxy’s AI SQL copilot can auto-refactor legacy queries and warn about deprecated syntax in real time.
Upgrade scripts calling SHOW SLAVE HOSTS must be edited to query performance_schema.replication_connection_status instead. CI pipelines should pin connector versions compatible with the target MySQL release.
Containers bundling old libmysqlclient need rebuilding.
A quick check with mysql --version inside the image confirms the client build date.
Monitor the MySQL release notes before major upgrades, run deprecation scans in Galaxy or CI, and enable strict SQL_MODE warnings so obsolete statements fail in staging first.
Centralize replica discovery logic through the performance_schema views or Cluster Metadata APIs, which are version-stable going forward.
Error 1681 (ER_WARN_DEPRECATED_SYNTAX) flags other removed statements.
Treat these warnings early.
Error 1146 (Table doesn’t exist) often replaces slave discovery logic when performance_schema is disabled. Enable the schema or grant proper privileges.
Error 3068 (ER_SLAVE_RELAY_LOG_READ_FAILURE) appears in replication setups with mismatched versions. Align versions and verify replica credentials.
.
Yes. Versions before 8.0.32 continue to accept the statement. Plan to migrate before upgrading the server.
Query performance_schema.replication_connection_status or use the MySQL InnoDB Cluster metadata tables.
MySQL 8.0.32 keeps SHOW SLAVE STATUS as a compatibility alias but recommends SHOW REPLICA STATUS instead.
Galaxy’s editor flags deprecated commands in real time and suggests the correct performance_schema queries, reducing upgrade risk.
.avif)
.avif){kind=logo}
