Translator: The star Yiu Team of the Hall of Knowledge
MySQL 8.0.2 Copy new features
MySQL 8 is getting better, and it's also causing a boom in our MySQL replication development team. We have been committed to comprehensively upgrading MySQL replication by introducing new and some interesting features. In addition, we have listened to community suggestions and feedback. Therefore, we are honored to be with you to witness the latest version (MySQL 8.0.2) milestone release, for which we summarized some noteworthy changes. Follow our blog below and we'll share some insights into these new features.
We have strengthened the MySQL group replication, mainly in the following aspects:
- Changes to members leaving the group are not allowed: whenever a group member leaves a group, the member leaving will automatically set super_read_only, which prevents the unexpected changes caused by the DBA, user or router/agent/load balancing. In addition to the default leave group replication members are not able to make changes, you can also start from the beginning of the prohibition of writing, we can also set the Super_read_only parameter on the server startup and start the group replication plug-in. Once the group is copied successfully, he will automatically adjust the value of the super_read_only. In multi-master mode, all nodes will not set the Super_read_only parameter, and in single-master mode, all nodes except the primary node will be set Super_read_only to ON. If it is unfortunate that your group replication fails to start, the Super_read_only parameter will not be set and no write operation will be possible. These latest changes also apply to MySQL 5.7.19 and MySQL 8.0.2. All of this is largely because we listened to the feedback from the community and then developed and strengthened it. --thank Kenny Gryp here
- More information can be found in the performance schema: in the existing table of the performance schema, the readability of the relevant statistical information is enhanced. The "Replication_group_members" and "replication_group_member_stats" tables have also been expanded, and it is now clear to see the role information of group members, the member version and the thing counter (local/remote)
- Specify the main library's election by assigning it: The user can control the election of the main library by assigning the weight of the group members, and when the existing master node exits the set replication, the node with the highest weight is promoted to the primary node.
- The flow control mechanism adds a few tweaks: the user can now adjust the flow control components more finely. You can define the minimum quota for each member, the minimum submission quota for the entire group, the Process Control window, and so on.
MySQL 8.0.1 has added a lot of compelling features to the MySQL replication core framework. and MySQL 8.0.2 on this basis and there is a great improvement, mainly as follows:
- Enhanced management of the receiver (IO) thread, even when the disk is full: This feature improves the efficiency of internal coordination between the receiver and other threads, reducing contention between the receivers and others. For end users, this means that when the disk is full and the sink 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, and you do not have to free up disk space to allow the receiver thread to continue the unfinished work, this time you can manually stop it, generally there is no problem. But if a written thing is erased, and relay log is not in a consistent state, you should pay special attention when the receiver thread polls the relay log and waits for disk space to be available.
- More metadata information is recorded in binary log: Adds a thing length to the global transaction log event. This can be of great help to our future optimization work, but also improve the readability of binary log.
If you are studying the internal mechanisms and principles of MySQL replication, we will be happy to share with you that we have done some cleanup work and added an interesting service to our base components:
- Group member events can be propagated to other internal components. By leveraging the new underlying service architecture, the group replication plug-in can now notify other components in the server about the events associated with the member. For example, the role of the notification group member changes quorum loss, and so on. Other components can provide feedback on this information, and users can develop their own components to record and detect these events.
- Remove redundant information on the node from the internal structure of the xcom (standard Paxos implementation, which is strictly guaranteed to be correct): we removed some redundant information in the xcom structure, which made it simpler, less error-prone, easier to monitor those nodes join or leave the cluster, It also retains the previous information in the system.
- Several improvements have been made to the xcom core and the new coding style: We have fixed several bugs in xcom, reformatted the code, and made it conform to Google's coding guidelines, if you happen to be a developer and look at the source code we Paxos implement, You will find that the revised code will be easier to read and understand.
- Removed some old version of binary log conversion source code: This cleanup work we cleared some old versions of binary logs from my database into some code that could be identified by the new version (now supports only MySQL5.0 and above).
Another interesting thing that we have changed in MySQL 8.0.2 is the following replication defaults:
- The copied metadata information is stored by default in the InnoDB system table: This will make the MySQL replication feature more powerful, when replication crashes and automatic recovery can use the characteristics of the innodb thing to ensure the correct recovery to the specified location. In addition, the new feature requires metadata to be stored as a table (such as group replication and multi-source replication), which is consistent with the new data dictionary for MySQL 8.
- Hash scan based on row data is turned on by default: This may not be a widely accepted practice, but performance can be improved when there are tables with no primary key constraints from the library. In this case, when you use row-based replication, this change minimizes the performance penalty because it reduces the number of table scans required to update all rows (the SLAVE_ROWS_SEARCH_ALGORITHMS parameter defaults to Table_scan,index_scan,hash_ SCAN).
- The transaction-write-set-extraction parameter is turned on by default: Use write set extraction to initiate group replication for users or to track master using Writeset-based dependencies on the primary server.
- Binary log expires by default: expire-logs-days default setting is 30 (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 delighted to see many interesting features being added.
Next, there will be a dedicated blog to explain these features. You can also download it yourself for testing (), we need to be aware of MySQL 8.0.2 or DMR version, and there is no GA, use it to take risks. And don't forget, we welcome and look forward to receiving your feedback. You can give us feedback through bug reports, feature reports, copy mailing lists, or just comment on this (or later) blog post. MySQL 8 will be getting better and more exciting.
MySQL 8.0.2 Copy new features (translation)
