mariadb

Commit Graph

Author	SHA1	Message	Date
Kent Boortz	e5ce023f57	Updated/added copyright headers	15 years ago
	16ca2deb90	Bug #56662 Assertion failed: next_insert_id == 0, file .\handler.cc Normally, auto_increment value is generated for the column by inserting either NULL or 0 into it. NO_AUTO_VALUE_ON_ZERO suppresses this behavior for 0 so that only NULL generates the auto_increment value. This behavior is also followed by a slave, specifically by the SQL Thread, when applying events in the statement format from a master. However, when applying events in the row format, the flag was ignored thus causing an assertion failure: "Assertion failed: next_insert_id == 0, file .\handler.cc" In fact, we never need to generate a auto_increment value for the column when applying events in row format on slave. So we don't allow it to happen by using 'MODE_NO_AUTO_VALUE_ON_ZERO'. Refactoring: Get rid of all the sql_mode checks to rows_log_event when applying it for avoiding problems caused by the inconsistency of the sql_mode on slave and master as the sql_mode is not set for Rows_log_event.	15 years ago
Davi Arnaut	39e9bde2c0	Bug#45288: pb2 returns a lot of compilation warnings Tag or remove unused arguments and variables.	15 years ago
Luis Soares	5109d5401e	BUG#38718: slave sql thread crashes when reading relay log Suprisingly, a Slave_log_event would show up in the binary log. This event is never used and should not appear in the logs. As such, when the slave (or the mysqlbinlog tool) reads the event, it will hit an invalid pointer (reference to the descriptor event when deserializing the Slave_log_event was purposodely set to NULL). The presence of the Slave_log_event denotes a corrupted log, but we cannot tell how the log got corrupted in the first place. However, we can make the server cope with such events when it reads them - in case of log corruption - and fail gracefully. This patch makes the server/mysqlbinlog to report that it has found an invalid log event when Slave_log_event is read.	15 years ago
Davi Arnaut	1b504ab0b1	Revert Bug#48321 due to build breakage and failing tests.	16 years ago
	899a1d694f	The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, session's user will be written into query log events if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.	16 years ago
	42eecc539a	The following statements support the CURRENT_USER() where a user is needed. DROP USER RENAME USER CURRENT_USER() ... GRANT ... TO CURRENT_USER() REVOKE ... FROM CURRENT_USER() ALTER DEFINER = CURRENT_USER() EVENTbut, When these statements are binlogged, CURRENT_USER() just is binlogged as 'CURRENT_USER()', it is not expanded to the real user name. When slave executes the log event, 'CURRENT_USER()' is expand to the user of slave SQL thread, but SQL thread's user name always NULL. This breaks the replication. After this patch, session's user will be written into query log events if these statements call CURREN_USER() or 'ALTER EVENT' does not assign a definer.	16 years ago
He Zhenxing	455f754e6b	Bug#53189 Table map version unused and can be removed MYSQL_BIN_LOG m_table_map_version member and it's associated functions were not used in the logic of binlogging and replication, this patch removed all related code.	16 years ago
	2049d1afc0	Bug #50407 mysqlbinlog --database=X produces bad output for SAVEPOINTs When mysqlbinlog was given the --database=X flag, it always printed 'ROLLBACK TO', but the corresponding 'SAVEPOINT' statement was not printed. The replicated filter(replicated-do/ignore-db) and binlog filter (binlog-do/ignore-db) has the same problem. They are solved in this patch together. After this patch, We always check whether the query is 'SAVEPOINT' statement or not. Because this is a literal check, 'SAVEPOINT' and 'ROLLBACK TO' statements are also binlogged in uppercase with no any comments. The binlog before this patch can be handled correctly except one case that any comments are in front of the keywords. for example: /* bla bla / SAVEPOINT a; / bla bla */ ROLLBACK TO a;	16 years ago
Mats Kindahl	2773758986	BUG#49618: Field length stored incorrectly in binary log for InnoDB The class Field_bit_as_char stores the metadata for the field incorrecly because bytes_in_rec and bit_len are set to (field_length + 7 ) / 8 and 0 respectively, while Field_bit has the correct values field_length / 8 and field_length % 8. Solved the problem by re-computing the values for the metadata based on the field_length instead of using the bytes_in_rec and bit_len variables. To handle compatibility with old server, a table map flag was added to indicate that the bit computation is exact. If the flag is clear, the slave computes the number of bytes required to store the bit field and compares that instead, effectively allowing replication without conversion from any field length that require the same number of bytes to store.	16 years ago
Andrei Elkin	f13ebe1252	bug#47142 improving comments	16 years ago
Andrei Elkin	1c0056b3ba	Bug #47142 "slave start until" stops 1 event too late in 4.1 to 5.0 replication When replicating from 4.1 master to 5.0 slave START SLAVE UNTIL can stop too late. The necessary in calculating of the beginning of an event the event's length did not correspond to the master's genuine information at the event's execution time. That piece of info was changed at the event's relay-logging due to binlog_version<4 event conversion by IO thread. Fixed with storing the master genuine Query_log_event size into a new status variable at relay-logging of the event. The stored info is extacted at the event execution and participate further to caclulate the correct start position of the event in the until-pos stopping routine. The new status variable's algorithm will be only active when the event comes from the master of version < 5.0 (binlog_version < 4).	16 years ago
	aa38825287	Bug #34628 LOAD DATA CONCURRENT INFILE drops CONCURRENT in binary log 'LOAD DATA CONCURRENT [LOCAL] INFILE ...' statment only is binlogged as 'LOAD DATA [LOCAL] INFILE ...' in SBR and MBR. As a result, if replication is on, queries on slaves will be blocked by the replication SQL thread. This patch write code to write 'CONCURRENT' into the log event if 'CONCURRENT' option is in the original statement in SBR and MBR.	16 years ago
Alfranio Correia	4f164c4c5a	BUG#48091 valgrind errors when slave has double not null and master has double null Backporting BUG#43789 to mysql-5.1-bugteam The replication was generating corrupted data, warning messages on Valgrind and aborting on debug mode while replicating a "null" to "not null" field. Specifically the unpack_row routine, was considering the slave's table definition and trying to retrieve a field value, where there was nothing to be retrieved, ignoring the fact that the value was defined as "null" by the master. To fix the problem, we proceed as follows: 1 - If it is not STRICT sql_mode, implicit default values are used, regardless if it is multi-row or single-row statement. 2 - However, if it is STRICT mode, then a we do what follows: 2.1 If it is a transactional engine, we do a rollback on the first NULL that is to be set into a NOT NULL column and return an error. 2.2 If it is a non-transactional engine and it is the first row to be inserted with multi-row, we also return the error. Otherwise, we proceed with the execution, use implicit default values and print out warning messages. Unfortunately, the current patch cannot mimic the behavior showed by the master for updates on multi-tables and multi-row inserts. This happens because such statements are unfolded in different row events. For instance, considering the following updates and strict mode: (master) create table t1 (a int); create table t2 (a int not null); insert into t1 values (1); insert into t2 values (2); update t1, t2 SET t1.a=10, t2.a=NULL; t1 would have (10) and t2 would have (0) as this would be handled as a multi-row update. On the other hand, if we had the following updates: (master) create table t1 (a int); create table t2 (a int); (slave) create table t1 (a int); create table t2 (a int not null); (master) insert into t1 values (1); insert into t2 values (2); update t1, t2 SET t1.a=10, t2.a=NULL; On the master t1 would have (10) and t2 would have (NULL). On the slave, t1 would have (10) but the update on t1 would fail.	16 years ago
Tatiana A. Nurnberg	197182d749	Bug#43746: YACC return wrong query string when parse 'load data infile' sql statement "load data" statements were written to the binlog as a mix of the original statement and bits recreated from parse-info. This relied on implementation details and broke with IGNORE_SPACES and versioned comments. We now completely resynthesize the query for LOAD DATA for binlog (which among other things normalizes them somewhat with regard to case, spaces, etc.). We have already parsed the query properly, so we make use of that rather than mix-and-match string literals and parsed items. This should make us safe with regard to versioned comments, even those spanning multiple tokens. Also no longer affected by IGNORE_SPACES.	16 years ago
Luis Soares	1d3daee450	BUG#42941: --database paramater to mysqlbinlog fails with RBR mysqlbinlog --database parameter was being ignored when processing row events. As such no event filtering would take place. This patch addresses this by deploying a call to shall_skip_database when table_map_events are handled (as these contain also the name of the database). All other rows events referencing the table id for the filtered map event, will also be skipped.	17 years ago
He Zhenxing	0793eec018	BUG#41948 Query_log_event constructor needlessly contorted Make the caller of Query_log_event, Execute_load_log_event constructors and THD::binlog_query to provide the error code instead of having the constructors to figure out the error code.	17 years ago
He Zhenxing	9530126822	BUG#37145 Killing a statement doing DDL may log binlog event with error code 1053 When the thread executing a DDL was killed after finished its execution but before writing the binlog event, the error code in the binlog event could be set wrongly to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED. This patch fixed the problem by ignoring the kill status when constructing the event for DDL statements. This patch also included the following changes in order to provide the test case. 1) modified mysqltest to support variable for connection command 2) modified mysql-test-run.pl, add new variable MYSQL_SLAVE to run mysql client against the slave mysqld.	17 years ago
He Zhenxing	52a07e9b74	BUG#37051 Replication rules not evaluated correctly Backporting patch to 5.0.	17 years ago
Alfranio Correia	4447ce614f	BUG#38174 secure-file-priv breaks LOAD DATA INFILE replication in statement mode If secure-file-priv was set on slave, it became unable to execute LOAD DATA INFILE statements sent from master using mixed or statement-based replication. This patch fixes the issue by ignoring this security restriction and checking if the files are created and read by the slave in the --slave-load-tmpdir while executing the SQL Thread.	17 years ago
Sven Sandberg	a24862ed46	BUG#41924: high-level replication functions are not commented Adding comments to some of the high-level functions in replication.	17 years ago
Sven Sandberg	56b7d87f73	BUG#41961: Some log_event types do not skip post-header when reading Problem: when the server reads a log_event from file, it should read the post-header lengths from the format_description_log_event. Some event types which currently have post-header length 0 did not do this, and instead had a hard-coded zero length for the post-header. That means the current server version will not be able to read future versions of these events. Fix: make the reader functions read the post-header.	17 years ago
Sven Sandberg	05d7673340	BUG#40482: server/mysqlbinlog crashes when reading invalid Incident_log_event Problem: When an Incident_log_event contains a bad incident number on disk, the server crashes with an assertion. Fix: Don't validate input with assertions. Use errors.	17 years ago
He Zhenxing	0d2025e1d4	BUG#38734 rpl_server_id2 sync_with_master failed Rotate event is automatically generated and written when rotating binary log or relay log. Rotate events for relay logs are usually ignored by slave SQL thread becuase they have the same server id as that of the slave. However, if --replicate-same-server-id is enabled, rotate event for relay log would be treated as if it's a rotate event from master, and would be executed by slave to update the rli->group_master_log_name and rli->group_master_log_pos to a wrong value and cause the MASTER_POS_WAIT function to fail and return NULL. This patch fixed this problem by setting a flag bit (LOG_EVENT_RELAY_LOG_F) in the event to tell the SQL thread to ignore these Rotate events generated for relay logs. This patch also added another binlog event flag bit (LOG_EVENT_ARTIFICIAL_F) to distinquish faked events, the method used before this was by checking if log_pos was zero.	17 years ago
He Zhenxing	78e1f5d523	Cherry picking patch for BUG#37051	18 years ago
Alexander Barkov	b25b2b2411	Additional fix for bug#31455 (rpl decoder) - Implementing --base64-format=decode-rows, to display SQL-alike decoded row events without their BINLOG statements. - Adding --base64-format=decode-rows into tests when calling mysqlbinlog to avoid non-deterministic results - Removing resetting of last_table_id in "RESET MASTER", which appeared to be dangerous.	18 years ago
Alexander Barkov	a57aa6bb75	Bug#31455 mysqlbinlog don't print user readable info about RBR events Implementing -v command line parameter to mysqlbinlog to decode and print row events. mysql-test/include/mysqlbinlog_row_engine.inc mysql-test/r/mysqlbinlog_row.result mysql-test/r/mysqlbinlog_row_big.result mysql-test/r/mysqlbinlog_row_innodb.result mysql-test/r/mysqlbinlog_row_myisam.result mysql-test/r/mysqlbinlog_row_trans.result mysql-test/t/mysqlbinlog_row.test mysql-test/t/mysqlbinlog_row_big.test mysql-test/t/mysqlbinlog_row_innodb.test mysql-test/t/mysqlbinlog_row_myisam.test mysql-test/t/mysqlbinlog_row_trans.test Adding tests client/Makefile.am Adding new files to symlink client/mysqlbinlog.cc Adding -v option sql/log_event.cc Impelentations of the new methods sql/log_event.h Declaration of the new methods and member sql/mysql_priv.h Adding new function prototype sql/rpl_tblmap.cc Adding pre-processor conditions sql/rpl_tblmap.h Adding pre-processor conditions sql/rpl_utility.h Adding pre-processor conditions sql/sql_base.cc Adding reset_table_id_sequence() function. sql/sql_repl.cc Resetting table_id on "RESET MASTER" .bzrignore Ignoring new symlinked files	18 years ago
He Zhenxing	e6ac8830a4	BUG#37051 Replication rules not evaluated correctly The problem of this bug is that we need to get the list of tables to be updated for a multi-table update statement, which requires to open all the tables referenced by the statement and resolve all the fields involved in update in order to figure out the list of tables for update. However if there are replicate filter rules, some tables might not exist on slave and result in a failure before we could examine the filter rules. I think the whole problem can not be solved on slave alone, the master must record and send the information of tables involved for update to slave, so that the slave do not need to open all the tables referenced by the multi-table update statement to figure out which tables are involved for update. So a status variable is added to Query_log event to store the value of table map for update on master. And on slave, it will try to get the value of this variable and use it to examine filter rules without opening any tables on slave, if this values is not available, the old approach is used and thus the bug will still occur for when replicating from old masters.	18 years ago
mats@mats-laptop.(none)	c8c4500a98	BUG#29020 (Event results not correctly replicated to slave in RBR): The bug allow multiple executing transactions working with non-transactional to interfere with each others by interleaving the events of different trans- actions. Bug is fixed by writing non-transactional events to the transaction cache and flushing the cache to the binary log at statement commit. To mimic the behavior of normal statement-based replication, we flush the transaction cache in row- based mode when there is no committed statements in the transaction cache, which means we are committing the first one. This means that it will be written to the binary log as a "mini-transaction" with just the rows for the statement. Note that the changes here does not take effect when building the server with HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before this patch either. For row-based logging, we also have that when AUTOCOMMIT=1, the code now always generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the case of non-transactional changes in a statement that was rolled back. Note that for the case where changes to a non-transactional table causes a rollback due to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even though some changes has been committed to the non-transactional table.	18 years ago
sven@riska.(none)	81b1d712bf	BUG#31168: @@hostname does not replicate Problem: in mixed and statement mode, a query that refers to a system variable will use the slave's value when replayed on slave. So if the value of a system variable is inserted into a table, the slave will differ from the master. Fix: mark statements that refer to a system variable as "unsafe", meaning they will be replicated by row in mixed mode and produce a warning in statement mode. There are some exceptions: some variables are actually replicated. Those should not be marked as unsafe. BUG#34732: mysqlbinlog does not print default values for auto_increment variables Problem: mysqlbinlog does not print default values for some variables, including auto_increment_increment and others. So if a client executing the output of mysqlbinlog has different default values, replication will be wrong. Fix: Always print default values for all variables that are replicated. I need to fix the two bugs at the same time, because the test cases would fail if I only fixed one of them.	18 years ago
sven@riska.(none)	444da164df	WL#4078: Document binary format of binlog entries Minor update with corrections and notes on the binlog format. This only affects comments, not code.	18 years ago
sven@riska.(none)	c33fc69253	WL#4078: Document binary format of binlog entries Documented Table_map_log_event and packed integer format. Improved other documentation. No change outside comments.	18 years ago
aelkin/elkin@koti.dsl.inet.fi	c9461608e7	Bug #32971 No user level error message from slave sql thread when ER_NO_DEFAULT_FOR_FIELD The error message due to lack of the default value for an extra field was not as informative as it should be. Fixed with improving the scheme of gathering, propagating and reporting errors in applying rows events. The scheme is in the following. Any kind of error of processing of a row event incidents are to be registered with my_error(). In the end Rows_log_event::do_apply_event() invokes rli->report() with the message to display consisting of all the errors. This mimics `show warnings' displaying. A simple test checks three errors in processing an event. Two hunks - a user level error and pushing it into the list - have been devoted to already fixed Bug@31702. Some open issues relating to this artifact listed on BUG@21842 page and on WL@3679. Todo: to synchronize the statement in the tests comments on Update and Delete events may not stop when an extra field does not have a default with wl@3228 spec.	18 years ago
mkindahl@dl145h.mysql.com	219a75056a	Post-merge changes.	18 years ago
sven@riska.(none)	30cd549e3b	BUG#34141: mysqlbinlog cannot read 4.1 binlogs containing load data infile Main problem: mysql 5.1 cannot read binlogs from 4.1. Subproblem 1: There is a mistake in sql_ex_info::init. The read_str() function updates its first argument to point to the next character to read. However, it is applied only to a copy of the buffer pointer, so the real buffer pointer is not updated. Fix 1: do not take a copy of the buffer pointer. The copy was needed because sql_ex_info::init does not use the const attribute on some of its arguments. So we add the const attribute, too. Subproblem 2: The first BINLOG statement is asserted to be a FORMAT_DESCRIPTION_LOG_EVENT, but 4.1 binlogs begin with START_EVENT_V3. Fix 2: allow START_EVENT_V3 too.	18 years ago
sven@riska.(none)	617ea4d631	BUG#27779: Slave cannot read old rows log events. Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and slave is mysql-5.1-new-rpl. The reason is that, in mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in mysql-5.1-new-rpl. Fix (in mysql-5.1-new-rpl): (1) detect that the server that generated the events uses the old format, by checking the server version of the format_description_log_event This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha, mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd. (2) if the generating server is old, map old event types to new event types using a permutation array. I've also added a test case which reads binlogs for four different versions.	18 years ago
sven@riska.(none)	5cc348a6a6	BUG#32407: Impossible to do point-in-time recovery from older binlog Problem: it is unsafe to read base64-printed events without first reading the Format_description_log_event (FD). Currently, mysqlbinlog cannot print the FD. As a side effect, another bug has also been fixed: When mysqlbinlog --start-position=X was specified, no ROLLBACK was printed. I changed this, so that ROLLBACK is always printed. This patch does several things: - Format_description_log_event (FD) now print themselves in base64 format. - mysqlbinlog is now able to print FD events. It has three modes: --base64-output=auto Print row events in base64 output, and print FD event. The FD event is printed even if it is outside the range specified with --start-position, because it would not be safe to read row events otherwise. This is the default. --base64-output=always Like --base64-output=auto, but also print base64 output for query events. This is like the old --base64-output flag, which is also a shorthand for --base64-output=always --base64-output=never Never print base64 output, generate error if row events occur in binlog. This is useful to suppress the FD event in binlogs known not to contain row events (e.g., because BINLOG statement is unsafe, requires root privileges, is not SQL, etc) - the BINLOG statement now handles FD events correctly, by setting the thread's rli's relay log's description_event_for_exec to the loaded event. In fact, executing a BINLOG statement is almost the same as reading an event from a relay log. Before my patch, the code for this was separated (exec_relay_log_event in slave.cc executes events from the relay log, mysql_client_binlog_statement in sql_binlog.cc executes BINLOG statements). I needed to augment mysql_client_binlog_statement to do parts of what exec_relay_log_event does. Hence, I did a small refactoring and moved parts of exec_relay_log_event to a new function, which I named apply_event_and_update_pos. apply_event_and_update_pos is called both from exec_relay_log_event and from mysql_client_binlog_statement. - When a non-FD event is executed in a BINLOG statement, without previously executing a FD event in a BINLOG statement, it generates an error, because that's unsafe. I took a new error code for that: ER_NO_FORMAT_DESCRIPTION_EVENT_BEFORE_BINLOG_STATEMENTS. In order to get a decent error message containing the name of the event, I added the class method char* Log_event::get_type_str(Log_event_type type), which returns a string name for the given Log_event_type. This is just like the existing char* Log_event::get_type_str(), except it is a class method that takes the log event type as parameter. I also added PRE_GA_*_ROWS_LOG_EVENT to Log_event::get_type_str(), so that names of old rows event are properly printed. - When reading an event, I added a check that the event type is known by the current Format_description_log_event. Without this, it may crash on bad input (and I was struck by this several times). - I patched the following test cases, which all contain BINLOG statements for row events which must be preceded by BINLOG statements for FD events: - rpl_bug31076 While I was here, I fixed some small things in log_event.cc: - replaced hard-coded 4 by EVENT_TYPE_OFFSET in 3 places - replaced return by DBUG_VOID_RETURN in one place - The name of the logfile can be '-' to indicate stdin. Before my patch, the code just checked if the first character is '-'; now it does a full strcmp(). Probably, all arguments that begin with a - are already handled somewhere else as flags, but I still think it is better that the code reflects what it is supposed to do, with as little dependencies as possible on other parts of the code. If we one day implement that all command line arguments after -- are files (as most unix tools do), then we need this. I also fixed the following in slave.cc: - next_event() was declared twice, and queue_event was not static but should be static (not used outside the file).	18 years ago
aelkin/elkin@koti.dsl.inet.fi	d8d6db6f78	Bug#31552 Replication breaks when deleting rows from out-of-sync table without PK Bug#31609 Not all RBR slave errors reported as errors bug#32468 delete rows event on a table with foreign key constraint fails The first two bugs comprise idempotency issues. First, there was no error code reported under conditions of the bug description although the slave sql thread halted. Second, executions were different with and without presence of prim key in the table. Third, there was no way to instruct the slave whether to ignore an error and skip to the following event or to halt. Fourth, there are handler errors which might happen due to idempotent applying of binlog but those were not listed among the "idempotent" error list. All the named issues are addressed. Wrt to the 3rd, there is the new global system variable, changeble at run time, which controls the slave sql thread behaviour. The new variable allows further extensions to mimic the sql_mode session/global variable. To address the 4th, the new bug#32468 had to be fixed as it was staying in the way.	18 years ago
aelkin/elkin@koti.dsl.inet.fi	27436f0ba3	Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing.	18 years ago
sven@murkla.(none)	af7da8cd64	WL#4078: Document binary format of binlog entries Documented some binlog events using doxygen. More will be done later. Also fixed typos in other comments and added remarks about dubious code. Only comments are affected, there is no change to the actual code.	18 years ago
mats@kindahl-laptop.dnsalias.net	24ea15a24d	Bug#31702 (Missing row on slave causes assertion failure under row-based replication): When replicating an update pair (before image, after image) under row-based replication, and the before image is not found on the slave, the after image was not discared, and was hence read as a before image for the next row. Eventually, this lead to an after image being read outside the block of rows in the event, causing an assertion to fire. This patch fixes this by reading the after image in the event that the row was not found on the slave, adds some extra debug assertion to catch future errors earlier, and also adds a few non-debug checks to prevent reading outside the block of the event.	18 years ago
mats@kindahl-laptop.dnsalias.net	f2ba11c327	BUG#28618 (Skipping into the middle of a group with SQL_SLAVE_SKIP_COUNTER is possible): When skipping the beginning of a transaction starting with BEGIN, the OPTION_BEGIN flag was not set correctly, which caused the slave to not recognize that it was inside a group. This patch sets the OPTION_BEGIN flag for BEGIN, COMMIT, ROLLBACK, and XID events. It also adds checks if inside a group before decreasing the slave skip counter to zero. Begin_query_log_event was not marked that it could not end a group, which is now corrected.	18 years ago
rafal@quant.(none)	c55627e9e2	BUG#21842: Exclude Rows_log_event members used in event application if not compiled as a replication server - a fix from rpl clone now applied to 5.1.22 tree.	19 years ago
rafal@quant.(none)	4581efe931	Post merge fixes.	19 years ago
rafal@quant.(none)	f8b64e17f9	BUG#21842 (Cluster fails to replicate to innodb or myisam with err 134 using TPC-B): Problem: A RBR event can contain incomplete row data (only key value and fields which have been changed). In that case, when the row is unpacked into record and written to a table, the missing fields get incorrect NULL values leading to master-slave inconsistency. Solution: Use values found in slave's table for columns which are not given in the rows event. The code for writing a single row uses the following algorithm: 1. unpack row_data into table->record[0], 2. try to insert record, 3. if duplicate record found, fetch it into table->record[0], 4. unpack row_data into table->record[0], 5. write table->record[0] into the table. Where row_data is the row as stored in the data area of a rows event. Thus: a) unpacking of row_data happens at the time when row is written into a table, b) when unpacking (in step 4), only columns present in row_data are overwritten - all other columns remain as they were found in the table. Since all data needed for the above algorithm is stored inside Rows_log_event class, functions which locate and write rows are turned into methods of that class. replace_record() -> Rows_log_event::write_row() find_and_fetch_row() -> Rows_log_event::find_row() Both methods take row data from event's data buffer - the row being processed is pointed by m_curr_row. They unpack the data as needed into table's record buffers record[0] or record[1]. When row is unpacked, m_curr_row_end is set to point at next row in the data buffer. Other changes introduced in this changeset: - Change signature of unpack_row(): don't report errors and don't setup table's rw_set here. Errors can happen only when setting default values in prepare_record() function and are detected there. - In Rows_log_event and derived classes, don't pass arguments to the execution primitives (do_...() member functions) but use class members instead. - Move old row handling code into log_event_old.cc to be used by *_rows_log_event_old classes. Also, a new test rpl_ndb_2other is added which tests basic replication from master using ndb tables to slave storing the same tables using (possibly) different engine (myisam,innodb). Test is based on existing tests rpl_ndb_2myisam and rpl_ndb_2innodb. However, these tests doesn't work for various reasons and currently are disabled (see BUG#19227). The new test differs from the ones it is based on as follows: 1. Single test tests replication with different storage engines on slave (myisam, innodb, ndb). 2. Include file extra/rpl_tests/rpl_ndb_2multi_eng.test containing original tests is replaced by extra/rpl_tests/rpl_ndb_2multi_basic.test which doesn't contain tests using partitioned tables as these don't work currently. Instead, it tests replication to a slave which has more or less columns than master. 3. Include file include/rpl_multi_engine3.inc is replaced with include/rpl_multi_engine2.inc. The later differs by performing slightly different operations (updating more than one row in the table) and clearing table with "TRUNCATE TABLE" statement instead of "DELETE FROM" as replication of "DELETE" doesn't work well in this setting. 4. Slave must use option --log-slave-updates=0 as otherwise execution of replication events generated by ndb fails if table uses a different storage engine on slave (see BUG#29569).	19 years ago
kostja@bodhi.(none)	b9fd0eeb5e	Last tweak for doxygen cleanup. The number of doxygen warnings is 0 now.	19 years ago
kostja@bodhi.(none)	beb61609a1	Fix doxygen warnings.	19 years ago
kostja@bodhi.(none)	b2716c0dad	Doxygen warnings.	19 years ago
monty@mysql.com/narttu.mysql.fi	9b6b53f0d0	Fixed errors found by pushbuild: Fixed failing func_misc test for embedded server Added casts to avoid compiler warnings Removed Table_locks_immediate as it's depending on log file cacheing Changed type of get_time() to avoid warnings Removed testing if purger master logs succeded as this is not deterministic	19 years ago
mats@kindahl-laptop.dnsalias.net	9c4ef25c55	Renaming RELAY_LOG_INFO and st_relay_log_info to follow coding standards (and be more friendly to Doxygen by removing unnecessary typedefs).	19 years ago

1 2 3 4 5 ...

319 Commits (42282c10ce0e2c808d1818e77a6a72eadc3a560d)