You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MDEV-15990 Refactor write_record and fix idempotent replication
See also MDEV-30046.
Idempotent write_row works same as REPLACE: if there is a duplicating
record in the table, then it will be deleted and re-inserted, with the
same update optimization.
The code in Rows:log_event::write_row was basically copy-pasted from
write_record.
What's done:
REPLACE operation was unified across replication and sql. It is now
representred as a Write_record class, that holds the whole state, and allows
re-using some resources in between the row writes.
Replace, IODKU and single insert implementations are split across different
methods, reluting in a much cleaner code.
The entry point is preserved as a single Write_record::write_record() call.
The implementation to call is chosen on the constructor stage.
This allowed several optimizations to be done:
1. The table key list is not iterated for every row. We find last unique key in
the order of checking once and preserve it across the rows. See last_uniq_key().
2. ib_handler::referenced_by_foreign_key acquires a global lock. This call was
done per row as well. Not all the table config that allows optimized replace is
folded into a single boolean field can_optimize. All the fields to check are
even stored in a single register on a 64-bit platform.
3. DUP_REPLACE and DUP_UPDATE cases now have one less level of indirection
4. modified_non_trans_tables is checked and set only when it's really needed.
5. Obsolete bitmap manipulations are removed.
Also:
* Unify replace initialization step across implementations:
add prepare_for_replace and finalize_replace
* alloca is removed in favor of mem_root allocation. This memory is reused
across the rows.
* An rpl-related callback is added to the replace branch, meaning that an extra
check is made per row replace even for the common case. It can be avoided with
templates if considered a problem.
Copy file name to clipboardExpand all lines: mysql-test/main/long_unique_bugs_replication.result
+46-2Lines changed: 46 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -9,20 +9,64 @@ insert into t1 values (2,2);
9
9
update t1 set a1 = 'd' limit 1;
10
10
update t1 set a1 = 'd2' where i1= 2;
11
11
connection slave;
12
+
connection slave;
13
+
select * from t1;
14
+
i1 a1
15
+
1 d
16
+
2 d2
12
17
connection master;
13
18
drop table t1;
19
+
connection slave;
20
+
connection master;
14
21
#
15
22
# MDEV-32093 long uniques break old->new replication
16
23
#
17
-
connection slave;
18
24
create table t1 (id int not null, b1 varchar(255) not null, b2 varchar(2550) not null, unique (id), unique key (b1,b2) using hash) default charset utf8mb3;
--echo # MDEV-32093 long uniques break old->new replication
25
30
--echo #
26
31
27
32
# this is techically a bug in replication, but it needs an old master
28
33
# so we'll run it as a non-replicated test with BINLOG command
29
-
sync_slave_with_master;
30
34
create table t1 (id int not null, b1 varchar(255) not null, b2 varchar(2550) not null, unique (id), unique key (b1,b2) using hash) default charset utf8mb3;
0 commit comments