It seems quite normal for rolled back transactions to discard the gtid. There can be gaps in the gtid because of this.
The important bit is because its semisync there shouldn't be a committed insert and nor should the transaction be in the binary log.
As a final check, start all slaves, do a transaction that succeeds, and check the binary log to ensure that despite the gaps, the new transaction is there and the rolled back transaction isn't.
I tested with go mysql connector driver, need to do more logic to handle this scenario for long transaction operation, and timeout logic to cancel this operation, something else to retry the failed transaction.
Let the server cancel it for you:
SET STATEMENT max_statement_time=10 FOR INSERT INTO ....
Please report if this doesn't work.
So the title here indicates that it will produce binlog. Is that correct or are you making the assumption based on gtid increments?
(dbausr@localhost) [(none)] 18:27:02> show processlist;
|
+----+-------------+-----------+--------+----------+--------+--------------------------------------+-----------------------------------------------------------------------------------+----------+
|
| Id | User | Host | db | Command | Time | State | Info | Progress |
|
+----+-------------+-----------+--------+----------+--------+--------------------------------------+-----------------------------------------------------------------------------------+----------+
|
| 6 | system user | | NULL | Slave_IO | 174550 | Waiting for master to send event | NULL | 0.000 |
|
*| 41 | dbausr | localhost | sbtest | Query | 55 | Waiting for semi-sync ACK from slave | SET STATEMENT max_statement_time = 5 FOR INSERT INTO sbtest.t1 VALUES(1654075999) | 0.000 |*
|
| 44 | dbausr | localhost | NULL | Query | 0 | starting | show processlist | 0.000 |
|
+----+-------------+-----------+--------+----------+--------+--------------------------------------+-----------------------------------------------------------------------------------+----------+
|
3 rows in set (0.00 sec)
|
did not take effect with this way
bnestere do you think max_statement_time should be respected by semisync?
It might be harder on a COMMIT to return with an error, however galera would.
Sorry for the late reply, I was on vacation last week.
I think this situation is captured by rpl_semi_sync_master_wait_point. When set to AFTER_COMMIT (the default), I think max_statement_time would not be respected. If set to AFTER_SYNC, I think max_statement_time should be respected. Note too, however, rpl_semi_sync_master_timeout is considered independently from max_statement_time. That is, if rpl_semi_sync_master_timeout > max_statement_time, the server would await an ACK for rpl_semi_sync_master_timeout, even if it is greater than max_statement_time.
With that said, it would make sense to me that if AFTER_SYNC is used, the ACK wait would be overridden with max_statement_time if it is less than rpl_semi_sync_master_timeout. In AFTER_COMMIT mode; however, they make sense to be independent to me.
Elkin, what are your thoughts?