Client-side error raised when a probe process cannot connect to a MySQL replica during health checks or Group Replication monitoring.
MySQL Error 2024: CR_PROBE_REPLICA_CONNECT signals that the replication health probe cannot open a network session to the replica host. Check network reachability, port, and SSL settings, then retry the probe to restore replication monitoring.
Error connecting to replica: CR_PROBE_REPLICA_CONNECT was added in 8.0.33.
MySQL Error 2024 with condition name CR_PROBE_REPLICA_CONNECT is a client-side connection error introduced in MySQL 8.0.33. It appears when a probing process that monitors replication health cannot open a TCP or UNIX socket to the designated replica host. The failure stops the probe, blocks Group Replication auto-rejoin, and may trigger failover decisions.
Prompt resolution keeps replicas synchronized and prevents unnecessary promotion of another server.
The error typically arises when the replica is unreachable on the declared host or port. Firewalls, DNS misconfiguration, or the replica service being down will break the handshake. SSL or TLS negotiation mismatches can also return CR_PROBE_REPLICA_CONNECT because the probe aborts before authentication.
Less common causes include max_connections exhaustion on the replica, mismatched client connect_timeout values, or incorrect bind-address settings.
In containerized deployments, stale service discovery records or orchestration health probes racing with MySQL startup also surface the condition.
Begin by confirming that the replica listens on the expected interface and port with tools like netcat or mysqladmin ping. Review MySQL logs on both primary and replica for socket or certificate errors. If SSL is enabled, align client and server cipher suites. Increase replica max_connections if saturation is detected.
Once connectivity succeeds, rerun the replication probe or restart the monitoring process to clear the error.
After a host reboot, MySQL may start slower than the replication manager, causing early probes to fail. Adding restart delays or healthcheck retries eliminates transient CR_PROBE_REPLICA_CONNECT events. When moving replicas across subnets, update replication_manager_configuration.host before restart to point at the new IP.
In Kubernetes, mount the proper CA certificates into the probe container so that SSL validation passes.
Keep replicas reachable through stable DNS entries or floating IPs, enforce uniform SSL policies across the fleet, and monitor port availability continuously. Automate firewall rule updates during scaling, and configure connection poolers with graceful backoff to prevent sudden max_connections spikes.
Periodically test replica connectivity with simple mysqladmin ping jobs so that production probes never hit unknown states.
Galaxy's modern SQL editor surfaces real-time connection diagnostics within the UI. If CR_PROBE_REPLICA_CONNECT appears, the editor flags the replica connection string, suggests the correct host and port, and provides one-click retry. Collaboration features let engineers share the failing query and endorsed fix, preventing repeated outages. Galaxy's connection monitoring alerts teams before probes fail, reducing unexpected replication gaps.
.
The probe cannot resolve the hostname or route a packet to the IP address, often due to DNS typos, subnet changes, or firewall blocks.
The replica process is stopped or still starting, so the TCP port is closed when the probe connects.
The replica listens on a non-default port or only on localhost, while the probe targets a different interface.
Client and server certificates or cipher suites differ, causing the handshake to abort before authentication.
max_connections on the replica is fully utilized, rejecting new sessions, including the health probe.
.
It is categorized as a client error because the failure happens on the probing process before any server response.
The error itself does not break replication but may trigger a failover or mark the replica unhealthy, indirectly halting data flow.
Occasional transient events during restarts are safe to ignore, but repeated alerts signal a deeper connectivity problem.
The code and condition were added in MySQL 8.0.33. Earlier versions will report generic connection errors instead.
.avif)
.avif){kind=logo}
