Bug #4380 | One-row INSERT/UPDATE/DELETE needn't be binlogged as 'killed' | ||
---|---|---|---|
Submitted: | 2 Jul 2004 14:26 | Modified: | 1 Aug 2004 17:00 |
Reporter: | Guilhem Bichot | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
Version: | 4.0 | OS: | Any (all) |
Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[2 Jul 2004 14:26]
Guilhem Bichot
[2 Jul 2004 14:31]
Guilhem Bichot
The same applies to other error codes than killed. As long as we reach the place where we write to the binlog, it means everything went all right, so we should in fact do: if (only_one_row_inserted) error_code_of_binlog_event=0;
[1 Aug 2004 17:00]
Guilhem Bichot
Hey Guilhem, you forgot one case when you wrote: "A one-row query is never partially executed. If it's in the binlog it means it went 100% ok." Values inserted by a one-row query can depend on if the connection is killed, so the slave needs to stop in this case. Example: INSERT INTO t VALUES(GET_LOCK("a", 10)); (if killed, NULL will be inserted) INSERT INTO t VALUES(MASTER_POS_WAIT("mybin.001", 10)); So, not easily fixable. In the future: - we'll feature row-level binary logging which will eliminate the problem - even with query-level binary logging, we'll soon (4.1 or 5.0) feature graceful shutdown levels, so that a query is not killed by shutdown until it has completed its update (binlog write included), so the problem will not happen for shutdown anymore, only happen for an explicit KILL (which is very rare).