1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
################################################################################
#
# Bug#25674926 VIEW CHANGE LOG EVENTS GENERATE NEW GTIDS
#
# Problem: When there is replication (async) between two groups,
# group nodes are confused when it receives view_change_log_event
# that is generated on the other group and the event is making
# infinite round trips between the groups in case if the async
# replication is circular replication.
#
# Scenario: Verify Group Replication behavior when we establish a
# circular replication connection from a server in a group
# to another server in the other group.
# Steps to reproduce:
# 0. The test requires six servers: M1, M2, M3, M4, M5 and M6.
# 1. Bootstrap start a group, GR1, on M1. Start GR on M2 and add it GR1.
# 2. Bootstrap start a group, GR2, on M3. Start GR on M4 and add it GR2.
# 3. Setup a asynchronous replication connection from M3(GR2) into M1(GR1)
# i.e. M3 -> M1.
# 4. Setup a asynchronous replication connection from M1(GR1) into M3(GR2)
# i.e. M1 -> M3.
# 5. Test view change event issue by adding/dropping nodes from the groups.
# Add node M5 to group GR1, and add node M6 to group GR2 and immediately
# drop the node from group (GR2). (This step is just to generate more
# VIEW_EVENTs)
# 6. Execute some transactions on M3.
# 7. Wait until transactions executed on M3 are applied on all nodes of GR1
# and GR2.
# 8. Execute some transactions on M1.
# 9. Wait until transactions executed on M1 are applied on all nodes of GR1
# and GR2.
# 10. Validate data on all nodes (M1, M2, M3, M4 and M5).
# 11. Check that GTID_EXECUTED on all servers are as expected.
# 12. Clean data.
# 13. Stop circular replication between groups.
# 14. Stop Group Replication on all nodes (M1, M2, M3, M4 and M5).
################################################################################
--source ../include/gr_replicate_group_to_group.inc
|
