MySQL 5.7Group Replication error summary (R11 note day 84) 01/18 Update SLTechnology News&Howtos

MySQL 5.7Group Replication error summary (R11 note day 84)

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Shulou(Shulou.com)06/01 Report--

Today, I would like to summarize some of the problem handling in MySQL 5.7. it is relatively conventional. I don't need to say much about the construction process. I can see a basic way in yesterday's article, which can be easily simulated in the test environment. Is it the same if it is built in a multi-physical machine environment? the answer is yes. I've tried it myself.

Because the official recommendation for building an environment is also the way of single_primary, that is, one primary write and the other read, that is, the separation of read and write, of course, it is theoretically feasible to support multi_primary, but there are still some minor problems. Let's take single_primary as an example.

Question 1:

When the reader node joined the group, start group_replication threw the following error. Basically encounter this mistake, you are not far from the success of the building.

2017-02-20T07:56:30.064556Z 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 89328c79-f730-11e6-ab63-782bcb377193:1-2 > Group transactions: 7c744904-f730-11e6-a72d-782bcb377193:1-4'

2017-02-20T07:56:30.064580Z 0 [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

2017-02-20T07:56:30.064587Z 0 [Note] Plugin group_replication reported:'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'

You can clearly see that it has been prompted in the log that you need to set parameters, that is, to be compatible with joining the group. Run start group_replication after the group_replication_allow_local_disjoint_gtids_join setting is complete.

Question 2:

If you encounter this error, don't worry too much, you can see from the log that it is due to parameter incompatibility. For example, the main writer is set to multi-primary, the read node is set to single-primary, and it can be unified.

2017-02-21T10:20:56.324890+08:00 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 87b9c8fe-f352-11e6-bb33-0026b935eb76:1-5

B79d42f4-f351-11e6-9891-0026b935eb76:1

F7c7b9f8-f352-11e6-b1de-a4badb1b524e:1 > Group transactions: 87b9c8fe-f352-11e6-bb33-0026b935eb76:1-5

B79d42f4-f351-11e6-9891-0026b935eb76purl'

2017-02-21T10:20:56.324971+08:00 0 [ERROR] Plugin group_replication reported: 'The member configuration is not compatible with the group configuration. Variables such as single_primary_mode or enforce_update_everywhere_checks must have the same value on every server in the group. (member configuration option: [], group configuration option: [group_replication_single_primary_mode]).

2017-02-21T10:20:56.325052+08:00 19 [Note] Plugin group_replication reported: 'Going to wait for view modification'

2017-02-21T10:20:56.325594+08:00 0 [Note] Plugin group_replication reported: 'getstart group_id 53d187f2'

Question 3:

This problem has perplexed me for a long time, in fact, it is essentially the setting of the node, in which there is a group_name, this name can not be set to the uuid of each node, such as node 1, 2, 2, 3, these nodes, group_replication_group_name needs to be consistent. Every time I failed before, I would seriously copy uuid and found that it was counterproductive.

2017-02-22T14:46:35.819072Z 0 [Warning] Plugin group_replication reported: 'read failed'

2017-02-22T14:46:35.851829Z 0 [ERROR] Plugin group_replication reported:'[GCS] The member was unable to join the group. Local port: 24902'

2017-02-22T14:47:05.814080Z 30 [ERROR] Plugin group_replication reported: 'Timeout on wait for view after joining group'

2017-02-22T14:47:05.814183Z 30 [Note] Plugin group_replication reported: 'Requesting to leave the group despite of not being a member'

2017-02-22T14:47:05.814213Z 30 [ERROR] Plugin group_replication reported:'[GCS] The member is leaving a group without being on one.'

2017-02-22T14:47:05.814567Z 30 [Note] Plugin group_replication reported: 'auto_increment_increment is reset to 1'

2017-02-22T14:47:05.814583Z 30 [Note] Plugin group_replication reported: 'auto_increment_offset is reset to 1'

2017-02-22T14:47:05.814859Z 36 [Note] Error reading relay log event for channel 'group_replication_applier': slave SQL thread was killed

2017-02-22T14:47:05.815720Z 33 [Note] Plugin group_replication reported: 'after The group replication applier thread was killed' is unified, the startup process is actually very fast.

Mysql > start group_replication

Query OK, 0 rows affected (1.52 sec)

Basically, there are these kinds of problems in the building process, as well as the hostname class, and there are some small bug in this respect. If you need special settings, you can also specify report_host to complete.

Question 4:

After the environment is set up, let's create a normal table, and sometimes good habits and specifications are especially important at such times.

Create table test_tab

Create table test_tab (id int,name varchar (30)); then insert a piece of data, which seems to be a perfectly normal operation, but there will be errors in MGR, because a basic requirement is that the table contains a primary key.

Mysql > insert into test_tab values (1)

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin. The way to fix it is to add a primary key:

Mysql > alter table test_tab add primary key (id)

Query OK, 0 rows affected (0.01 sec)

Records: 0 Duplicates: 0 Warnings: 0

Question 5 (simulated disaster):

What we are currently building is the single-primary model. If the main writer node fails, how to deal with the whole group, the second node S2 provincial discipline inspection commission will be given priority.

It's easy to test. Let's kill the service of Node 1 directly. See where the primary node drifts.

First of all, the basic situation of group replication, there are currently 5 nodes, we directly kill node 1, that is, port 24801.

+-+

+-+

+-+

Node 2 will output the following log, which means that the node is officially on duty.

2017-02-22T14:59:45.157989Z 0 [Note] Plugin group_replication reported: 'getstart group_id 98e4de29'

2017-02-22T14:59:45.434062Z 0 [Note] Plugin group_replication reported: 'Unsetting super_read_only.'

2017-02-22T14:59:45.434130Z 40 [Note] Plugin group_replication reported:'A new primary was elected, enabled conflict detection until the new primary applies all relay logs' will then see that the group replication becomes the following situation, and there is no doubt that the first node has been removed.

+-+

+-+

+-+

From the log we can see that the second node is promoted to write mainly, then the problem comes.

Question 6:

How to determine which of a replication group is the master node cannot be judged entirely by guessing or flipping through the log.

We use the following statement to filter to get.

Mysql > select * from performance_schema.replication_group_members where member_id = (select variable_value from performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member')

+-+

+-+

+-+

1 row in set (0.00 sec)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.