Bug #68250 | Current semi-synchronous replication may cause deadlock | ||
---|---|---|---|
Submitted: | 2 Feb 2013 0:35 | Modified: | 23 Apr 2013 13:10 |
Reporter: | Yoshinori Matsunobu (OCA) | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.6.9 | OS: | Any |
Assigned to: | Luis Soares | CPU Architecture: | Any |
[2 Feb 2013 0:35]
Yoshinori Matsunobu
[7 Feb 2013 12:30]
Luis Soares
We are able to reproduce it deterministically! Working on a patch.
[25 Feb 2013 8:45]
Bill Qu
The described deadlock scenario is strange, due to we already flushed the net before get read_pos from slave in after_send_event(...). See below. Invoke link: Binlog_transmit_delegate::after_send_event(...) -> repl_semi_after_send_event(...) -> ReplSemiSyncMaster::readSlaveReply(...) int ReplSemiSyncMaster::readSlaveReply(NET *net, ...) { ...... /* We flush to make sure that the current event is sent to the network, * instead of being buffered in the TCP/IP stack. */ if (net_flush(net)) { sql_print_error("Semi-sync master failed on net_flush() " "before waiting for slave reply"); goto l_end; } ...... log_file_pos = uint8korr(packet + REPLY_BINLOG_POS_OFFSET); ...... result = reportReplyBinlog(server_id, log_file_name, log_file_pos); ...... } The above test (running concurrent inserts from 100 threads by using mysqlslap) should cause deadlock scenario described in Bug#68251 instead of this one. I am also curious why the reporter's patch can gain performance. Could you please post your configuration, such as the time of semi-sync timeout and so on?
[26 Mar 2013 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
[23 Apr 2013 13:10]
Bill Qu
net_flush() Will not cause the deadlock scenario described in the description.