Detailed introduction to the new replication features of MySQL 8.0.2

Translator: Zhishutang Xingyao Team

MySQL 8.0.2 Replication New Features

MySQL 8 is getting better and better, and this is also caused by our MySQL replication R&D team There was an upsurge. We've been working hard to improve MySQL replication across the board, by introducing new and interesting features. Additionally, we 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, and we have summarized some of the noteworthy changes. Follow our blog below as we share some insights into these new features.

We have strengthened MySQL group replication, mainly in the following aspects:

• Do not allow changes to members who leave the group: Whenever a group member leaves the group Group, leaving members will automatically set super_read_only, this can prevent unexpected changes caused by DBA, users or routers/agents/load balancers, etc. In addition to the default that members who leave group replication cannot be modified, writing can also be prohibited from the moment they join. We can also set the super_read_only parameter when the server starts and start the group replication plug-in. Once the group replication operation is successful, it will automatically adjust the value of super_read_only. In multi-master mode, all nodes will not set the super_read_only parameter; in single-master mode, except the master node, all other nodes will set super_read_only to ON. If unfortunately your group replication fails to start, the super_read_only parameter will not be set and no write operations will be possible. These latest changes also apply to MySQL 5.7.19 and MySQL 8.0.2. A large part of all of this is because we listened to community feedback and then developed and enhanced it. --Here thanks to Kenny Gryp

• You can view more information in Performance Schema: In the existing tables of Performance Schema, the readability of related statistical information has been enhanced. The "replication_group_members" and "replication_group_member_stats" tables have also been expanded. Now you can clearly see the role information of group members, group member versions and transaction counters (local/remote)

• Pass Assign weights to specify the election of the master database: Users can control the election of the master database by specifying the weights of group members. When the existing master node exits group replication, the node with the highest weight will be promoted to the master node.

• Some fine-tuning items have been added to the flow control mechanism: users can now fine-tune the flow control components. You can define minimum quotas for each member, minimum commit quotas for the entire group, process control windows, and more.

MySQL 8.0.1 has added many compelling features to the MySQL replication core framework. MySQL 8.0.2 has made great improvements on this basis, mainly as follows:

• Enhanced management of the receiver (IO) thread, even if the disk is full: This feature has been improved Improves the efficiency of internal coordination between the receiver and other threads and reduces contention with each other. For end users, this means that in the event the disk becomes full and the receiver thread blocks, it no longer blocks watch 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, and you cannot release the disk space to allow the receiver thread to continue unfinished work, this time you You can stop it manually, and generally there will be no problem. But if a write transaction is cleared at that time, and the relay log is not in a consistent state, you need to pay special attention when the receiver thread polls the relay log and waits for disk space to become available.

• Record more metadata information in the binary log: add transaction length to global transaction log events. This can be of great help to our future optimization work, and also improves the readability of the binary log.

If you're looking into the inner workings of MySQL replication, we'd be happy to share that we've done some cleanup work and added an interesting addition to our base component Services:

• Group membership events can be propagated to other components internally. By leveraging the new underlying service architecture, the Group Replication plug-in can now notify other components in the server about member-associated events. For example, notifying group members of a role change, arbitration loss, etc. Other components can respond to this information, and users can also develop their own components to record and detect these events.

• Remove redundant information on nodes from the internal structure of XCom (a standard Paxos implementation that can strictly guarantee correctness): We have removed some redundant information from the structure of XCom , which makes it simpler, less error-prone, and easier to monitor which nodes join or leave the cluster, while it retains previous information in the system.

• Several improvements to XCom core and new coding style: We have fixed several bugs in XCom and reformatted the code to make it comply with Google's coding guidelines. As a developer, and looking at the source code of our Paxos implementation, you will find that the revised code will be easier to read and understand.

• Removed some source codes for binary log conversion of old versions: In this cleaning work, we cleared some binary logs produced by the old version of My database and converted them into ones that can be recognized by the new version. Code (currently only supports MySQL5.0 and above).

One more interesting thing, we have changed the following replication defaults in MySQL 8.0.2:

• Replicated Metadata Information is stored in INNODB system tables by default: This will make the MySQL replication function more powerful. When replication crashes and automatically recovers, the characteristics of INNODB transactions can be used to ensure the correctness of recovery to the specified location. In addition, new features also require metadata to be stored in the form of tables (such as group replication and multi-source replication), which is consistent with MySQL 8's new data dictionary.

• Hash scan based on row data is enabled by default: This may not be a widely recognized approach, but when the slave database has some tables without primary key constraints, the performance will be improved improve. In this case, this change will minimize the performance penalty when using row-based replication, because it will reduce the number of table scans required to update all rows (slave_rows_search_algorithms parameter defaults to TABLE_SCAN, INDEX_SCAN, HASH_SCAN).

• The transaction-write-set-extraction parameter is enabled by default: use write set extraction, start group replication for users or track the master using WRITESET-based dependencies on the master server.

• Binary log is enabled by default. Expiration time: expire-logs-days is set to 30 by default (30 days)

As you know, we Been very busy. In fact, MySQL 8.0.2 Milestone Release has been released. On the replication side, we're really excited to see a lot of interesting features being added.

There will be a dedicated blog to introduce and explain these functions. You can also download it yourself for testing (download address). What we need to pay attention to is MySQL 8.0.2 or DMR version. There is no GA. Use it at your own risk. And don’t forget, we welcome and appreciate your feedback. You can give us feedback via bug reports, feature reports, copy the mailing list or just leave a comment on this (or subsequent) blog post. MySQL 8 will get better and better and more exciting.

The above is the detailed content of Detailed introduction to the new replication features of MySQL 8.0.2. For more information, please follow other related articles on the PHP Chinese website!