WL#1062 "log charset info into all Query_log_event":
we store 7 bytes (1 + 2*3) in every Query_log_event. In the future if users want binlog optimized for small size and less safe, we could add --binlog-no-charset (and binlog-no-sql-mode etc): charset info is something by design optional (even if for now we don't offer possibility to disable it): it's not a binlog format change. We try to reduce the number of get_charset() calls in the slave SQL thread to a minimum by caching the charset read from the previous event (which will often be equal to the one of the current event). We don't use SET ONE_SHOT for charset-aware repl (we still do for timezones, will be fixed later). No more errors if one changes the global value of charset vars on master or slave (as we log charset info in all Query_log_event). Not fixing Load_log_event as it will be rewritten soon by Dmitri. Testing how mysqlbinlog behaves in rpl_charset.test. mysqlbinlog needs to know where charset file is (to be able to convert a charset number found in binlog (e.g. in User_var_log_event) to a charset name); mysql-test-run needs to pass the correct value for this option to mysqlbinlog. Many result udpates (adding charset info into every event shifts log_pos in SHOW BINLOG EVENTS). Roughly the same job is to be done for timezones :) client/mysqlbinlog.cc: mysqlbinlog needs charsets knowledge, to be able to convert a charset number found in binlog to a charset name (to be able to print things like this: SET @`a`:=_cp850 0x4DFC6C6C6572 COLLATE `cp850_general_ci`; mysql-test/mysql-test-run.sh: tell mysqlbinlog about charsets dir mysql-test/r/ctype_ucs.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/drop_temp_table.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/insert_select.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/mix_innodb_myisam_binlog.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/mysqlbinlog.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/mysqlbinlog2.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. The log_pos shift is why the SET INSERT_ID=4 event changes position in the result. mysql-test/r/rpl_charset.result: Running mysqlbinlog to check how it behaves on charset stuff. SET ONE_SHOT is now gone. Repl of LOAD DATA INFILE is not yet charset-aware (will soon be, when WL#874 is pushed) and, anyway result has a dependency on the temp filename (SQL-LOAD-*-[0-9] which is not constant). No more errors if one changes global character sets. mysql-test/r/rpl_error_ignored_table.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_flush_log_loop.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_flush_tables.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_loaddata.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_loaddata_rule_m.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_log.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_max_relay_size.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_relayrotate.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_replicate_do.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_rotate_logs.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_temporary.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_timezone.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/rpl_user_variables.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/r/user_var.result: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. mysql-test/t/rpl_charset.test: Running mysqlbinlog to check how it behaves on charset stuff (so, need fixed timestamp). SET ONE_SHOT is not printed to binlog anymore, so no need to test if ::exec_event() works ok. Repl of LOAD DATA INFILE is not yet charset-aware (will soon be, when WL#874 is pushed) and, anyway result has a dependency on the temp filename (SQL-LOAD-*-[0-9] which is not constant). No more errors if one changes global character sets. mysql-test/t/rpl_user_variables.test: different binlogging of charsets results in shifted log_pos and one added SET @@CHARACTER_SET... per mysqlbinlog run. sql/log.cc: No more SET ONE_SHOT for charsets (remains for TZ until solved with Dmitri). sql/log_event.cc: We now log charset info in each Query_log_event in binlog. It's 2*3 = 6 bytes: session character_set_client, session collation_connection, session collation_server. Now we would need only one byte per variable, but Bar said 2 is safer for the future. When slave or mysqlbinlog reads that info, it needs to get_charset() on these numbers (so, 3 get_charset() calls), as most of the time the 6-byte charset info will be equal to the previous event's, we cache the previous event's charset and if equal, no need to get_charset(). As "flags2", SQL_MODE, catalog, autoinc variables, charset info is not a permanent addition: in the future we can add options to the master to not log any of these, old 5.0 should be able to parse these. A little bit of cleanup on autoinc stuff in replication. Fixing a bug in Start_log_event_v3::exec_event() where we used rli->relay_log.description_event_for_exec->binlog_version while we should use binlog_version (if it's a 3.23 master, that's all that counts; not the fact that the relay log is in 5.0 format). sql/log_event.h: binlogging of charset info in each Query_log_event. sql/mysql_priv.h: comment sql/set_var.cc: checks to refuse change of global charset variables are removed: they were needed for 4.1->4.1 but not for 5.0.3->5.0.3. Yes this opens a breach if one does 4.1->5.0.3, where the checks would still be needed. But these checks would need reading relay_log.description_event_for_queue, which is currently an object used in many places by the I/O thread and only it. So, currently we don't take mutexes for this object, and if we read the object in set_var.cc (client thread) we need to add mutexes everywhere, but the replication code is already too broken with mutexes now (no consistent use of mutexes); mutex usage in replication should be fixed but preferrably during/after multimaster coding as it's going to shuffle mutexes already. sql/set_var.h: Since we don't forbid global change of charset vars for replication/binlogging, don't need specific ::check() methods anymore sql/slave.cc: Some little debug info which has nothing to do with charsets. Disabling master's charset check when slave I/O thread connects. Functions for charset caching/invalidating in the slave SQL thread. sql/slave.h: Cached charset in the slave SQL thread.
Showing
This diff is collapsed.
Please register or sign in to comment