New Features of MySQL 8.0.2 replication (translation), mysql8.0.2
Translator: zhishutang xingyao team
New Features of MySQL 8.0.2 Replication
MySQL 8 is becoming better and better, and this has caused a boom in our MySQL replication R & D team. We have been committed to comprehensively improving MySQL replication by introducing new and interesting features. We also listened to suggestions and feedback from the community. Therefore, we are honored to witness the milestone release of the latest version (MySQL 8.0.2) with you. For this reason, we have summarized some notable changes. Following our blog below, we will share some insights on these new features.
We have strengthened MySQL group replication in the following aspects:
- You cannot change the Member that leaves the group: when a group member leaves the group, the member that leaves the group will automatically set super_read_only, which can prevent DBAs from leaving the group, unexpected changes caused by users, routers, proxies, and Server Load balancer. In addition to the Member who leaves the group copy by default, the member cannot be modified. You can also disable the write operation from the beginning. You can also set the super_read_only parameter when the server is started and start the group copy plug-in. Once the group is successfully copied, the value of super_read_only is automatically adjusted. In multi-master mode, the super_read_only parameter is not set for all nodes. in single-master mode, super_read_only is set for all nodes except the master node. If, unfortunately, your group replication fails to start, the super_read_only parameter will not be set and no write operations will be performed. These latest changes also apply to MySQL 5.7.19 and MySQL 8.0.2. Most of these are because we have listened to feedback from the Community and then developed and strengthened them. -- Thanks to Kenny Gryp.
- You can view more information in Performance Schema: the readability of related statistical information is enhanced in the existing tables of Performance Schema. The "replication_group_members" and "replication_group_member_stats" tables are also extended. Now we can clearly see the role information, group member versions, and transaction counters (Local/remote) of the group members)
- Re-specify the primary database election by assigning permissions: You can control the election of the primary database by specifying the weight of the group members. When the existing primary node exits from the group replication, the node with the highest weight will be promoted to the primary node.
- The traffic control mechanism has added some fine-tuning items: users can now more precisely adjust the traffic control components. You can define the minimum quota for each member, the minimum submission quota for the entire group, and the process control window.
MySQL 8.0.1 has added many notable features in the MySQL replication core framework. MySQL 8.0.2 is greatly improved on this basis, mainly as follows:
- Enhance the management of receiver (IO) threads, even if the disk is full: This function improves the internal coordination efficiency between the receiver and other threads and reduces contention between each other. For end users, this means that when the disk is full and the receiver thread is blocked, it no longer blocks monitoring operations, such as show slave status. It also introduces a new thread state (the receiver thread is waiting for Disk Space Resources). In addition, when the disk is full, in addition, you cannot release the disk space so that the receiver thread can continue the unfinished work. In this case, you can manually stop it. Generally, there is no problem. However, if a write event is cleared and the relay log is not in the same status, when the receiver thread polls the relay log and waits for the disk space to be available, you need to pay special attention.
- More metadata information is recorded in binary log: the length of the transaction is added to the global transaction log event. This can be of great help to our future optimization work and improve the readability of binary logs.
If you are studying the internal mechanism and principle of MySQL replication, we will be glad to share with you that we have done some cleanup work and added an interesting service for our basic components:
- Group member events can be propagated to other internal components. With the new basic service architecture, the group replication plug-in can now notify other components on the server about Member-related events. For example, notifying members of a group of roles to change the role of the group is lost in arbitration. Other components can provide feedback on this information, and users can develop their own components to record and detect these events.
- Delete the redundant information on the node from the internal structure of XCom (Standard Paxos implementation, which can strictly ensure the correctness): we delete some redundant information in the XCom structure, this makes it easier, with fewer errors, and easier to monitor those nodes to join or leave the cluster, while retaining the previous information in the system.
- We have made several improvements to the XCom core and new encoding style: we have fixed several bugs in XCom and re-formatted the code to conform to Google's coding rules, if you happen to be a developer and look at the source code of our Paxos implementation, you will find that the revised Code will be easier to read and understand.
- The source code for binary log conversion in earlier versions is removed: in this cleanup, we cleared some codes that can be recognized by the new version of binary logs produced by My database (currently only MySQL and later versions are supported ).
Another interesting thing is that we have changed the following replication default values in MySQL 8.0.2:
- By default, the copied metadata is stored in the INNODB system table, which makes MySQL replication more powerful, when replication crashes and is automatically restored, INNODB Transaction features can be used to ensure the correctness of recovery to the specified location. In addition, the new feature requires that metadata be stored as tables (such as group replication and multi-source replication), which is consistent with the new data dictionary of MySQL 8.
- Hash scanning based on row data is enabled by default: this may not be widely recognized, but performance will improve when the slave database has tables without primary key constraints. In this case, when row-based replication is used, this change minimizes performance loss because it reduces the number of table scans required to update all rows (slave_rows_search_algorithms parameter TABLE_SCAN by default, INDEX_SCAN, HASH_SCAN ).
- The transaction-write-set-extraction parameter is enabled by default: write set extraction is used to start group replication for the user or trace the master on the master server using WRITESET-based dependency.
- Enable Binary log expiration time by default: expire-logs-days is set to 30 by default (30 days)
As you know, we have been very busy. In fact, MySQL 8.0.2 Milestone Release has been released. In terms of replication, we are very pleased to see that many interesting features have been added.
Next we will have a special blog to introduce these features. You can also download and test it by yourself (). We need to pay attention to the MySQL 8.0.2 or DMR version, but there is no GA. You need to take risks if you use it. Also, don't forget. We welcome and expect your feedback. You can give us feedback through the error report, function report, copy the email list, or comment only on this (or subsequent) blog. MySQL 8 will get better and better.
