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
Bug#36313793 --ndb-log-apply-status fails to work with no replica changes [3/3]
Problem:
The NDB table, ndb_apply_status, tracks the replica applier state. If
replicated changes were applied but are not visible in the Binlog
Injector (log-replica-updates=OFF) - because NDB data nodes filtered
those - then the epoch, from the Binlog Injector point-of-view, is
deemed to be empty. But, ndb_apply_status did have an update because
those changes were replicated in the cluster. This breaks the flow of
apply status information in a chain/circular replication deployment.
Analysis:
Running some chain/circular replication scenarios, it is possible to
observe, in the binlog injector handling of data events, that the
ndb_apply_status table updates are written into the binlog
transaction, thus not filtered (system tables do not have
skip-log-replica-updates data node filter).
If only ndb_apply_status updates are written, then it's considered an
empty epoch, as there's no actual table data to write to the
binlog. Therefore, the binlog transaction will be rolled back, in case
logging of empty epochs is off. But, due to the nature of the
`skip-log-replica-updates` filter in the NDB data nodes, some data
might have been replicated even if not received by the binlog thread.
Solution:
The usage of ndb-log-apply-status=ON with circular replication is a
complex case. Requires the understanding that even for a server that
has skip-log-replica-updates, ndb_apply_status updates are still
logged (and thus continue to propagate through the chain).
With the above, this patch does not enable the replica updates filter
in the NDB data nodes for the cases that ndb-log-apply-status or
ndb-log-orig are ON. If log-replica-updates is OFF (filter might be
enabled and in operation) then ndb-log-apply-status and ndb-log-orig
cannot be toggled.
Tests adapted to this new behavior.
Change-Id: I48944c536142b87d361e73eacf0f7a699616fa66
Copy file name to clipboardExpand all lines: mysql-test/suite/ndb_rpl/r/ndb_rpl_circular.result
+2-66Lines changed: 2 additions & 66 deletions
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,9 @@ Note #### Sending passwords in plain text without SSL/TLS is extremely insecure.
7
7
Note #### Storing MySQL user name or password information in the connection metadata repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START REPLICA; see the 'START REPLICA Syntax' in the MySQL Manual for more information.
8
8
include/rpl/connect.inc [creating master]
9
9
include/rpl/connect.inc [creating slave]
10
+
# create the table on the "slave"
10
11
CREATE TABLE t1 (a int key, b int) ENGINE=ndb;
12
+
# now we should have a table on the master as well
Note #### Sending passwords in plain text without SSL/TLS is extremely insecure.
4
+
Note #### Storing MySQL user name or password information in the connection metadata repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START REPLICA; see the 'START REPLICA Syntax' in the MySQL Manual for more information.
5
+
Warnings:
6
+
Note #### Sending passwords in plain text without SSL/TLS is extremely insecure.
7
+
Note #### Storing MySQL user name or password information in the connection metadata repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START REPLICA; see the 'START REPLICA Syntax' in the MySQL Manual for more information.
8
+
include/rpl/connect.inc [creating source]
9
+
include/rpl/connect.inc [creating replica]
10
+
# Validating servers setup
11
+
[connection source]
12
+
SELECT @@log_replica_updates;
13
+
@@log_replica_updates
14
+
0
15
+
SELECT @@ndb_log_orig;
16
+
@@ndb_log_orig
17
+
1
18
+
SELECT @@ndb_log_apply_status;
19
+
@@ndb_log_apply_status
20
+
1
21
+
# Since server has log-replica-updates=OFF, it cannot set following variables
22
+
SET GLOBAL ndb_log_orig=ON;
23
+
SHOW WARNINGS;
24
+
Level Code Message
25
+
Warning 1231 Variable 'ndb_log_orig' can't be changed when 'log_replica_updates' is OFF
26
+
Error 1231 Variable 'ndb_log_orig' can't be set to the value of 'ON'
27
+
SET GLOBAL ndb_log_orig=OFF;
28
+
SHOW WARNINGS;
29
+
Level Code Message
30
+
Warning 1231 Variable 'ndb_log_orig' can't be changed when 'log_replica_updates' is OFF
31
+
Error 1231 Variable 'ndb_log_orig' can't be set to the value of 'OFF'
32
+
SET GLOBAL ndb_log_apply_status=ON;
33
+
SHOW WARNINGS;
34
+
Level Code Message
35
+
Warning 1231 Variable 'ndb_log_apply_status' can't be changed when 'log_replica_updates' is OFF
36
+
Error 1231 Variable 'ndb_log_apply_status' can't be set to the value of 'ON'
37
+
SET GLOBAL ndb_log_apply_status=OFF;
38
+
SHOW WARNINGS;
39
+
Level Code Message
40
+
Warning 1231 Variable 'ndb_log_apply_status' can't be changed when 'log_replica_updates' is OFF
41
+
Error 1231 Variable 'ndb_log_apply_status' can't be set to the value of 'OFF'
42
+
[connection replica]
43
+
SELECT @@log_replica_updates;
44
+
@@log_replica_updates
45
+
1
46
+
SELECT @@ndb_log_orig;
47
+
@@ndb_log_orig
48
+
1
49
+
SELECT @@ndb_log_apply_status;
50
+
@@ndb_log_apply_status
51
+
1
52
+
# Since server has log-replica-updates=ON, it can toggle following variables
53
+
SET GLOBAL ndb_log_orig=OFF;
54
+
SET GLOBAL ndb_log_orig=ON;
55
+
SET GLOBAL ndb_log_apply_status=OFF;
56
+
SET GLOBAL ndb_log_apply_status=ON;
57
+
# Now create table
58
+
[connection source]
59
+
CREATE TABLE t1 (a INT PRIMARY KEY, b INT) ENGINE = NDB;
60
+
include/rpl/stop_replica.inc
61
+
INSERT INTO t1 VALUES (1,1);
62
+
[connection replica]
63
+
# Replica has only source's serverid entry
64
+
select server_id, log_name from mysql.ndb_apply_status order by server_id;
65
+
server_id log_name
66
+
1 master-bin.000001
67
+
# Replica has following ndb_binlog_index entries
68
+
select inserts, updates, deletes, schemaops, orig_server_id from mysql.ndb_binlog_index order by position,orig_epoch;
69
+
inserts updates deletes schemaops orig_server_id
70
+
0 0 0 0 2
71
+
1 0 0 0 1
72
+
[connection source]
73
+
include/rpl/start_replica.inc
74
+
# Source now has own serverid entry as well
75
+
select server_id, log_name from mysql.ndb_apply_status order by server_id;
76
+
server_id log_name
77
+
1 master-bin.000001
78
+
2 slave-bin.000001
79
+
[connection replica]
80
+
# Replica still only has source's serverid entry
81
+
select server_id, log_name from mysql.ndb_apply_status order by server_id;
82
+
server_id log_name
83
+
1 master-bin.000001
84
+
# Now create event originating at replica
85
+
INSERT INTO t1 VALUES (2,2);
86
+
# Replica now also has its own serverid entry
87
+
select server_id, log_name from mysql.ndb_apply_status order by server_id;
0 commit comments