859      阿裏雲  技術社區[雲棲]

MySQL 8.0.2複製新特性搶鮮看

MySQL 8 正在變得原來越好，而且這也在我們MySQL複製研發團隊引起了一陣熱潮。我們一直致力於全麵提升MySQL複製，通過引入新的和一些有趣的功能。此外，我們還聽取了社區的建議和反饋。因此，我們很榮幸能夠與你一同見證最新版本（MySQL 8.0.2）的裏程碑式的發布，為此我們總結了其中的一些值得注意的變化。跟隨我們下麵的博客，我們將會分享這些新功能的一些見解。

MySQL 8 is shaping up quite nicely. And we are having a blast in the MySQL replication team while this is happening. We are continuously improving all-things-replication by introducing new and interesting features. In addition, we have been listening to our community and addressing their feedback. As such, we would like to celebrate with you all the latest development milestone release, MySQL 8.0.2, by summarizing the noteworthy changes that are in it. Follow up blog posts shall provide insights on these new enhancements.

我們對MySQL 組複製進行了加強，主要有以下幾個方麵：

不允許對離開組的成員進行更改：

每當組成員離開群組，離開的成員將會自動設置super_read_only，這可以防止DBA，用戶或路由層/代理中間件/負載均衡端等帶來的的意外更改。除了默認離開組複製的成員不能夠進行修改以外，也可以從剛加入開始就開始禁止寫入，我們也可以在服務器啟動時設置super_read_only參數並啟動組複製插件。

一旦組複製啟動成功，他會自動調整super_read_only的值。在多主模式下，所有的節點都將不會設置super_read_only參數 ；在單主的模式下，除了主節點以外，其他的節點都會設置super_read_only為ON 。

如果很不幸，你的組複製啟動失敗了的話，super_read_only =1 設置會繼續保持，將不能進行任何寫入操作。這些最新的變化同樣適用於MySQL 5.7.19和MySQL 8.0.2。所有的這些，有很大部分是因為我們聽取了社區的反饋(BUG#84728, BUG#84795, BUG#84733)然後進行開發和加強。

--在此 感謝Kenny Gryp！

Disallow changes to members that have left the group. Whenever a member leaves the group voluntarily, it will automatically set super_read_only. This prevents accidental changes from the DBA, user, or router/proxy/load balancers. In addition to disallowing changes on members that have left the group by default, it is also possible to protect the writes from the beginning. I.e., it is possible to set super_read_only and start the group replication plugin while the server starts.

Once Group Replication starts successfully, it will adjust super_read_only’s value properly. On multi-primary mode, the super_read_only will be unset on all joining members; On single-primary, only the primary will have super_read_only unset.

In the unlikely event that Group Replication fails to start, the super_read_only is preserved, thence no writes are allowed. This last change is actually in both, MySQL 5.7.19 and MySQL 8.0.2. All of these were highly influenced by feedback we got from our community (BUG#84728, BUG#84795, BUG#84733)

– Thank you Kenny Gryp!

可以在Performance Schema 中查看更多信息：

在Performance Schema現存的表中，對相關的統計信息的可讀性進行了加強。“replication_group_members” 和 “replication_group_member_stats” 表也做了相關拓展，現在可以清楚的看到組成員的角色信息，組成員版本和事物計數器（本地/遠程）。

More information on Performance Schema tables.

More observability enhancements were added to existing performance schema tables. “replication_group_members” and “replication_group_member_stats” tables have been extended and now display information such as members roles, members versions and counters for the different types of transactions (local/remote).

通過分配權重來指定主庫的選舉：

用戶可以通過指定組成員的權重來控製主庫的選舉，當現有的主節點退出組複製，權重最高的節點就會被提升為主節點。

Influence primary election by assigning promotion weights. The user is able to influence the primary election by determining member weights. When the existing primary goes away, the member with the highest weight is the one to be elected on fail-over.

流量控製機製加了一些微調項：

用戶現在可以更精細的調節流量控製組件。可以定義每個成員的最小配額，整個組的最小提交配額，流程控製窗口等等。

Fine tuning options for the flow control mechanism.

Users can now do more fine tuning of the flow control component. They can define the minimum quota per member, minimum commit quota for the entire group, the flow control window, and more!

MySQL 8.0.1 已經在MySQL複製核心框架添加了很多引人注目的功能。而MySQL 8.0.2在此基礎上又有很大的提升，主要如下：

增強對接收（IO）線程的管理，即使磁盤已滿：

此功能提高了接收線程和其他線程之間的內部協調效率，減少彼此的爭用。對於終端用戶來說，這意味著在磁盤變滿並且接收線程阻塞的情況下，它不再阻塞監視操作，例如SHOW SLAVE STATUS。它還引入了一個新的線程狀態，即接收線程正在等待磁盤空間資源狀態。

此外，當磁盤已滿，且不能通過釋放磁盤空間使接收線程繼續沒有完成的工作時，可以手動強製停止，一般情況下不會有什麼問題。如果一個event隻寫了部分，那它會被清掉以確保relay的一致性。當接收線程輪轉刷新relay log且需等待磁盤空間釋放時，這種情況下可能就要當心了。

Enhanced management of the receiver (IO) thread even when disk is full. This feature improves the internal coordination between receiver and other threads, removing some contention. To the end user, this means that in the event that the disk becomes full and the receiver thread blocks, it no longer blocks monitoring operations, such as SHOW SLAVE STATUS. A new thread state is also introduced stating that the receiver thread is waiting for disk space.

Moreover, when the disk is full and you cannot free disk space up to allow the receiver thread to continue its activity, you can forcefully stop it, generally without side effects. If there is an event that is partially written this is cleared and relay log is left in a consistent state. Some extra care needs to be taken when receiver thread is rotating the relay log and is waiting for disk space to become available.

binary log中記錄更多的元數據信息：

將事物長度添加到全局事務日誌事件。這可以對我們未來的優化工作有很大的幫助，而且也提高了binary log的可讀性。

More metadata into the binary log.

Added the length of the transaction to the global transaction log event. This enables potential future optimizations to be implemented as well as better observability support into the binary log.

如果你在研究MySQL複製的內部機製與原理，我們將很高興與你一起分享我們做了一些清理工作，並為我們的基礎組件添加了一個有趣的服務：

If you are into MySQL replication internals, we are happy to let you know that we have done some clean ups and added one interesting service to our components infrastructure:

組成員事件可以傳播到內部其他組件。

通過利用新的基礎服務架構，組複製插件現在可以通知服務器中的其他組件關於成員關聯的事件。例如，告知某個組成員角色改變導致仲裁節點丟失等。其他的組件可以對這個信息作出反饋，並且用戶也可以自己開發組件用來注冊和監聽這些事件。

Group membership events are propagated to other components internally.

By taking advantage of the new services infrastructure, the group replication plugin can now notify other components in the server about membership related events. For instance, notify that membership has changed and that quorum was lost. Other components can react to this information. Users can write their own components that register and listen to these events.

從XCom（標準的Paxos實現，能嚴格保證正確性）的內部結構中刪除節點上的冗餘信息。

我們在XCom的結構中刪除了一些冗餘信息，這使它變得更加簡單、減少錯誤信息，更容易監控那些節點加入或者離開集群，同時它會在係統中保留以前的信息。

Removed redundant information on nodes from internal structures in XCom.

This work removed a bit of redundant information in XCom’s structures, making it simpler and less error prone to track which servers have left and rejoined, while there is still stale information in the system about previous views.

對XCom核心和新編碼風格進行了幾項改進：

我們已經修複了XCom的幾個BUG，重新格式化了代碼，使它符合Google的編碼準則，如果你恰巧是一個開發人員，並且再看我們Paxos實現的源代碼，你會發現改版後的代碼將會更加容易閱讀和理解。

Several enhancements to XCom core and new coding style.

XCom has had several bug fixes and its code was reformatted to meet the google coding guidelines. If you are a developer and enjoy looking at our Paxos implementation, this will make it easier for you to read and understand the code.

移除了一些老舊版本binary log轉換的源代碼：

這個清理工作我們清除了一些老版本MySQL數據庫產的的binary logs轉化為新版本能夠識別的一些代碼（現在僅支持MySQL 5.0以及以上版本）。

Removed cross version conversion code for very old binary log formats.

This is a clean up that removes code converting binary logs generated by very old versions of MySQL to a newer format as understood by newer versions of MySQL (versions 5.0 and higher).

還有一件有意思的事情，我們已經在MySQL 8.0.2中更改了以下複製默認值：

複製的元數據信息默認存儲在InnoDB係統表中。

這將使MySQL複製功能變得更加強大，在複製崩潰並且自動恢複時候能夠使用InnoDB事物的特性來保證恢複到指定位置的正確性。此外，新功能還要求將元數據以表的形式存儲（比如組複製和多源複製），它與MySQL 8的新的數據字典保持一致。

Replication metadata is stored in (InnoDB) system tables by default.

This makes replication more robust by default when it comes to crashing and recovering automatically the replication positions. Also, newer features require the metadata information to be stored in tables (e.g., group replication, mutli-source replication). It aligns with the overall direction of MySQL 8 and the new data dictionary in it.

基於RBR時SLAVE的SQL線程的哈希掃描被默認開啟：

這也許並不是一個被廣泛認同的做法，但是當從庫有一些沒有主鍵約束的表的時候性能會有提高。在這種情況下，使用基於RBR的複製時，此更改會最大程度降低性能損失，因為它會減少更新行數，而非像以前那樣可能要全表掃描更新（slave_rows_search_algorithms參數默認TABLE_SCAN,INDEX_SCAN，HASH_SCAN）。

hash scans for row-based applier are enabled default. Perhaps not a popular knob, but one that helps when slaves do not have tables with primary keys. This change will minimize the performance penalty in that case, when using row-based replication, since it reduces the number of table scans required to update all rows.

transaction-write-set-extraction參數會默認開啟：

使用寫集提取，為用戶啟動組複製或在主服務器上使用基於WRITESET的依賴關係對master進行跟蹤。

Write set extraction is enabled by default.

With write set extraction, it is one less configuration step for the user to start group replication or use WRITESET based dependency tracking on the master.

默認開啟Binary log 過期時間：expire-logs-days默認設置為30（30天）

Binary log expiration is enabled by default. The binary logs are expired after 30 days by default (expire-logs-days=30).

如你所知，我們一直很忙。事實上，MySQL 8.0.2 Milestone Release已經發布了。在複製方麵，我們非常高興看到許多有趣的功能被加入進來。

As you can see, we have been busy. :) In fact, MySQL 8.0.2 is showing a great feature set across the board. On the replication side, we are very happy to see so many interesting features getting released.

接下來將會有專門的博客來介紹說明這些功能。你也可以自己下載進行測試（下載地址）,我們需要留意的是MySQL 8.0.2還是DMR版本，並沒有GA，使用它需要自己承擔風險。另外不要忘記，我們歡迎而且很期望得到你們的反饋。您可以通過錯誤報告，功能報告，複製郵件列表或僅對這個（或後續的）博文發表評論來給予我們反饋。MySQL 8將會越來越好，越來越精彩。

Stick around as there will be blog posts detailing further the features mentioned above. Actually, go and try them yourself, as you can download a MySQL 8.0.2 packages here. Note that MySQL 8.0.2 is a development milestone release (DMR), thence not declared generally available yet. Use it at your own risk. Don’t forget, feedback is always welcome and highly appreciated. You can send it to us through bug reports, feature reports, the replication mailing list or by just leaving a comment on this (or subsequent) blog posts. MySQL 8 looks rather nice! Exciting!

原文發布時間為：2017-09-19
翻譯團隊：知數堂藏經閣項目 - 星耀隊
團隊成員：星耀隊-M哥、 星耀隊-芬達 、星耀隊-順子
譯文校稿：葉師傅
原文出處：https://mysqlhighavailability.com/replication-features-in-mysql-8-0-2/
原文作者：Luis Soares
本文來自雲棲社區合作夥伴“老葉茶館”，了解相關信息可以關注“老葉茶館”微信公眾號

最後更新：2017-09-20 12:02:59

  上一篇：  MySQL 5.7怎麼爬出臨時表空間的坑

  下一篇：  吳恩達導師Michael I. Jordan剛去清華手寫版書講了三天課，這有一份他的課程筆記