mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 05:22:25 +01:00
4 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
unknown
|
277b80da67 |
the results of binlog_statement_insert_delayed in STATEMENT - non-recommended mode i.e not checked
by make test - got changed due to show binlog events relocation to deterministic position at extra/binlog_tests/binlog_insert_delayed.test. mysql-test/r/binlog_statement_insert_delayed.result: results changed due to moving a binlog check affront of indetermistic queries. |
||
|
unknown
|
1ac90c6a50 |
Result of a binlog_statement_insert_delayed was affected by recent fixing of
binlog_row_binlog.test failure in team tree. Fixing the result. |
||
|
unknown
|
76fa1d4381 |
Fixing problems I identified in my auto_increment work pushed in July
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
more tests of binlogging of INSERT DELAYED: with multi-row INSERTs.
I identified why sleeps are needed to get a repeatable row-based
binlogged: because without sleeps rows sometimes get groupped
and so generate different row based events.
mysql-test/extra/rpl_tests/rpl_foreign_key.test:
don't forget to drop tables on slave too, otherwise it leaves
an orphan innodb table leading to rpl_insert_id failing sometimes
(like in pushbuild "sapsrv2 -max").
mysql-test/extra/rpl_tests/rpl_insert_id.test:
testing that if some statement does not update any row, it does
not pollute the auto_inc binlog variables of the next statement;
the test has to use stored procedures because with plain statements,
mysql_reset_thd_for_next_command() does the resetting (and thus
there is no problem); mysql_reset_thd_for_next_command() is not
called inside routines.
mysql-test/r/binlog_row_binlog.result:
result additions
mysql-test/r/binlog_statement_insert_delayed.result:
result additions
mysql-test/r/binlog_stm_binlog.result:
result additions
mysql-test/r/rpl_insert_id.result:
result additions
mysql-test/r/rpl_loaddata.result:
With the change to log.cc reverted, the result changes and is better:
the change to log.cc had caused some INSERT_ID events to disappear
though they were necessary (but testsuite could not catch that because
it's single-threaded).
mysql-test/r/rpl_ndb_insert_ignore.result:
NDB is now like other engines regarding INSERT IGNORE: autoincrement
values which caused a duplicate key are re-used for next row, not lost.
rpl_ndb_insert_ignore.result is now identical to rpl_insert_ignore.result.
sql/log.cc:
LOAD DATA INFILE is binlogged as several events, and the last of them must
have the auto_inc id. So it's wrong to reset the auto_inc id after every
binlog write (because then it's lost after the first event of LOAD
DATA INFILE and so missing for the last one)/
Another problem: MYSQL_LOG::write() is not always called (for example
if no row was updated), so we were missing reset in some cases.
sql/sp_head.cc:
SELECT func1(),func2() generates two binlog events, so needs to
clear auto_increment binlog variables after each binlog event
(it would be more natural to clear them in the log write code,
but LOAD DATA INFILE would suffer from this see the cset comment
for log.cc). Without the clearing, the problem is:
> exec func1()
>> call cleanup_after_query() (which does not clear our vars here)
>> binlog SELECT func1()
<
> exec func2()
and so SELECT func2() is binlogged with the auto_inc of SELECT func1().
sql/sql_class.cc:
after every statement we should clear auto_inc variables used for
binlogging, except if this was a function/trigger (in which case
it may be "INSERT SELECT func()", where the cleanup_after_query()
executed in func() should not reset the auto_inc binlog variables
as they'll be necessary when binlogging the INSERT SELECT later).
sql/sql_insert.cc:
- as INSERT DELAYED uses the same TABLE object as the delayed_insert
system thread, we should not call ha_release_auto_increment()
from INSERT DELAYED (and btw it's logical as we reserve nothing
as we don't perform the insert). Calling the function caused us to
release values being used by the delayed_insert thread.
So I do the call only if this is a non-DELAYED INSERT.
- Assuming two INSERT DELAYED which get grouped by the delayed_insert
thread, the second may use values reserved by the first, which is ok
per se, but is a problem in statement-based binlogging:
the 2nd INSERT gets binlogged with the "interval start" value
of the first INSERT (=> duplicate error in slave).
- no reason to ha_release_auto_increment() after every inserted row
in INSERT SELECT; more efficient to do it only when the statement ends
sql/sql_parse.cc:
a comment
|
||
|
unknown
|
930e542f44 |
Changes made according to HLD/LLD.
The following is an excerption from the WL.
1. Change so that MIXED is default format
1.1 to change the default for command line --binlog-format
1.2 to alter global_system_variables.binlog_format calculation
basing on command line --binlog-format parameter and
its default.
2. Change test suite so that more testing is done by MIXED format.
2.1 to check if there are test cases requiring --binlog-foramt=statement via
`source include/have_binlog_format_statement.inc' and affected by
altering the latter to be "mixed".
2.2 to check the content of such vulnerable cases to find if
extending to the mixed does not modify results. In that case simply
substitute source arguments as explained.
2.3 if a test in mixed mode deals with features triggering
row-binlogging then if necessary we can switch explicitly
to statement mode or create another test to run with
non-recommended STATEMENT mode
Particullarily, extracting INSERT DELAYED
binlogging subtest for statement mode is performed, and
the snippet is moved into a separate test file.
Note that since now all three modes verify this use case
through 3 different tests.
No changes in item 3 of HLD appeared to be needed.
mysql-test/extra/binlog_tests/binlog.test:
Moving INSERT DELAYED verification section into separate file. The latter is sourced
from two different files: the current one and a newly created for STATEMENT
mode check.
mysql-test/extra/rpl_tests/rpl_loaddata.test:
require mixed_or_statement
mysql-test/extra/rpl_tests/rpl_stm_000001.test:
require mixed_or_statement
mysql-test/extra/rpl_tests/rpl_stm_charset.test:
require mixed_or_statement
mysql-test/r/binlog_stm_binlog.result:
new result to correspond to MIXED mode.
mysql-test/r/rpl_rbr_to_sbr.result:
result changed
mysql-test/t/archive.test:
require mixed_or_statement
mysql-test/t/binlog_stm_binlog.test:
require exclusive mixed format because of INSERT DELAYED.
mysql-test/t/binlog_stm_blackhole.test:
require mixed_or_statement
mysql-test/t/binlog_stm_ctype_cp932.test:
require mixed_or_statement
mysql-test/t/binlog_stm_ctype_ucs.test:
require mixed_or_statement
mysql-test/t/binlog_stm_drop_tmp_tbl.test:
require mixed_or_statement
mysql-test/t/binlog_stm_innodb_stat.test:
require mixed_or_statement
mysql-test/t/binlog_stm_insert_select.test:
require mixed_or_statement
mysql-test/t/binlog_stm_mix_innodb_myisam.test:
require mixed_or_statement
mysql-test/t/create_select_tmp.test:
require mixed_or_statement
mysql-test/t/ctype_cp932_binlog_stm.test:
require mixed_or_statement
mysql-test/t/date_formats.test:
MIXED case appended to the replace instruction
mysql-test/t/mysqlbinlog.test:
require mixed_or_statement
mysql-test/t/mysqlbinlog2.test:
require mixed_or_statement
mysql-test/t/ndb_multi.test:
require mixed_or_statement
mysql-test/t/rpl000013.test:
require mixed_or_statement
mysql-test/t/rpl_heap.test:
require mixed_or_statement
mysql-test/t/rpl_loaddata_s.test:
require mixed_or_statement
mysql-test/t/rpl_mixed_ddl_dml.test:
require mixed_or_statement
mysql-test/t/rpl_rbr_to_sbr.test:
Rather meaningless line is discarded.
The test does not loose anything without it and without considering the WL.
mysql-test/t/rpl_rewrt_db.test:
require mixed_or_statement
mysql-test/t/rpl_rotate_logs.test:
require mixed_or_statement
mysql-test/t/rpl_stm_EE_err2.test:
require mixed_or_statement
mysql-test/t/rpl_stm_flsh_tbls.test:
require mixed_or_statement
mysql-test/t/rpl_stm_log.test:
require mixed_or_statement
mysql-test/t/rpl_stm_max_relay_size.test:
require mixed_or_statement
mysql-test/t/rpl_stm_multi_query.test:
require mixed_or_statement
mysql-test/t/rpl_stm_mystery22.test:
require mixed_or_statement
mysql-test/t/rpl_stm_no_op.test:
require mixed_or_statement
mysql-test/t/rpl_stm_reset_slave.test:
require mixed_or_statement
mysql-test/t/rpl_stm_until.test:
require mixed_or_statement
mysql-test/t/rpl_temp_table.test:
require mixed_or_statement
mysql-test/t/rpl_trigger.test:
require mixed_or_statement
mysql-test/t/rpl_trunc_temp.test:
require mixed_or_statement
mysql-test/t/user_var-binlog.test:
require mixed_or_statement
sql/mysqld.cc:
Implementation of making BINLOG_FORMAT_MIXED to be the default of
global_system_variables.binlog_format. Not in the case of embedded.
mysql-test/extra/binlog_tests/binlog_insert_delayed.test:
Snippend sourced from two tests to verify INSERT DELAYED in all three binlog formats.
mysql-test/include/have_binlog_format_mixed.inc:
Part of exclusive MIXED format requirement
mysql-test/include/have_binlog_format_mixed_or_statement.inc:
requirement to have mixed or statement. Most of the tests with STATEMENT format indeed
are tolerant to MIXED format to yield the same result files. There are few exception
because of features triggering RBR events when MIXED format.
mysql-test/r/binlog_statement_insert_delayed.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/5.1/wl3368_mixed_default/mysql-test/r/binlog_statement_insert_delayed.result
mysql-test/r/have_binlog_format_mixed.require:
Exclusive MIXED format
mysql-test/t/binlog_statement_insert_delayed.test:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/5.1/wl3368_mixed_default/mysql-test/t/binlog_statement_insert_delayed.test
|