slave doesn't set status to STOPPED after max-reconnect failures

Bug #956214 reported by Daniel Nichter on 2012-03-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Undecided
Stewart Smith

Bug Description

Related to bug 743958 (need way to determine master status/information from slave), while testing bug 956200 (slave config file option max-reconnects doesn't work) I found that even after the slave exhausts its attempts to connect to the master, the status is still RUNNING when it should switch to STOPPED and display an error message.

To reproduce:

1. Let slave fail to reconnect max-reconnect times
2. Query the sys_replication tables and see:

drizzle> select * from sys_replication.io_state\G
*************************** 1. row ***************************
master_id: 1
   status: RUNNING
error_msg:

drizzle> select * from sys_replication.applier_state\G
*************************** 1. row ***************************
              master_id: 1
 last_applied_commit_id: 5
originating_server_uuid: 44E71752-D51E-4B34-81C9-A32AA5C97020
  originating_commit_id: 5
                 status: RUNNING
              error_msg:

Related branches

Stewart Smith (stewart) on 2012-04-15
Changed in drizzle:
assignee: nobody → Stewart Smith (stewart)
status: Confirmed → Fix Committed
Daniel Nichter (daniel-nichter) wrote :

The linked branch actually fixes this bug by calling setIOState(err_msg, false); if _is_connected is false after all reconnect attempts.

Changed in drizzle:
milestone: none → 7.2.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers