技術分享 | InnoDB Cluster 如何高效加載數據

做者：洪斌
愛可生南區負責人兼技術服務總監，MySQL  ACE，擅長數據庫架構規劃、故障診斷、性能優化分析，實踐經驗豐富，幫助各行業客戶解決 MySQL 技術問題，爲金融、運營商、互聯網等行業客戶提供 MySQL 總體解決方案。
本文來源：轉載自公衆號-玩轉MySQL
*愛可生開源社區出品，原創內容未經受權不得隨意使用，轉載請聯繫小編並註明來源。

---

一行命令搞定 InnoDB Cluster 數據快速加載。

InnoDB Cluster 8.0 通過一系列的優化已足夠穩定，早期版本常因網絡延遲、閃斷等問題形成集羣不穩定，也曾遇到客戶因網絡緩解問題致使節點頻繁被踢，可用性得不到保障，不得不使用外圍運維手段保障集羣穩定性，也增長了運維工做的複雜性。如今經過參數優化已能獲得有效解決，可以容忍必定網絡波動。解決了網絡問題，另外一個使用 InnoDB Cluster 面臨問題就是大事務了，系統不免會遇到大的 DML，load data 操做。在數據同步機制上 group replication 與 async replication、semi-sync replication 有很大差別。它是參考 paxos 協議實現了獨立的組通信引擎 xcom 集成在 MySQL，xcom 負責節點間消息的發送與接收，並保證消息投遞的一致和有序，消息包括兩類事務寫集相關信息和心跳統計相關信息。xcom 是單線程實例，在處理大事務必然會影響其餘消息的處理，若是是來自其餘節點的心跳消息沒法迴應，5s 無響應節點會被踢出集羣。group_replication_transaction_size_limit 參數限制了事務大小，超出限制事務回滾不會廣播。事務消息就是 writeset，其大小是由事務變動行數、行長度、惟一索引數量等因素決定。爲了加強對大事務的處理能力，8.0.16 支持了消息分片機制，經過 group_replication_communication_max_message_size 參數控制消息分片大小，若消息超過該限制會自動分包廣播，到達其餘節點後自動合併起來，此參數不能大於 slave_max_allowed_packet 值，默認是 10MB，最大上限 1GB。

那有了消息分片機制是否是就完美支持大事務了？

我模擬了 load data 導入一個 185MB 的文件。在 group_replication_transaction_size_limit 默認 147MB 配置下是沒法導入的，超過限制事務被回滾。

將 group_replication_transaction_size_limit 設置爲 0 至關於取消限制，能夠成功導入，且集羣節點狀態所有正常，沒有節點被踢出集羣。

還能處理更大的事務嗎？

隨後測試中我將數據文件放大到 1G，group_replication_transaction_size_limit 保持爲 0 不作事務限制，會發生節點失聯導入失敗。由於超出了 xcom cache 限制，xcom cache 緩存了最近一段時間的消息信息，當節點失聯後加回集羣，失聯期間的消息要經過 xcom cache 來恢復，若是緩存空間不夠，缺失的消息被淘汰了，節點就沒法自動加回集羣，只能手動加回集羣經過異步複製通道恢復數據。8.0.16 以前 xcom cache 是固定配置 50000 個 slot 或 1G 內存，超出限制按 LRU 策略回收內存空間，8.0.16 新增了 group_replication_message_cache_size 參數取消了固定限制，用戶能夠結合實際狀況調整，配合 group_replication_member_expel_timeout 調整能容忍更長網絡延遲。xcom cache 使用狀況在 memory_summary_global_by_event_name 觀測

mysql> select * from  memory_summary_global_by_event_name where event_name like 'memory/group_rpl%'\G
*************************** 1\. row ***************************
EVENT_NAME: memory/group_rpl/GCS_XCom::xcom_cache
COUNT_ALLOC: 2362
COUNT_FREE: 2317
SUM_NUMBER_OF_BYTES_ALLOC: 5687428055
SUM_NUMBER_OF_BYTES_FREE: 3196560772
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 45
HIGH_COUNT_USED: 1176
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 2490867283
HIGH_NUMBER_OF_BYTES_USED: 3195280758
1 row in set (0.0030 sec)

• CURRENT_COUNT_USED  xcom cache 當前已使用 slot 數量
• CURRENT_NUMBER_OF_BYTES_USED  xcom cache 當前已使用內存空間

若是將 xcom cache 設置足夠大，能處理更大的事務嗎？

group_replication_message_cache_size 上限是 16EB，cb_xcom_receive_data 函數接收消息的限制是 4G，有興趣能夠試驗下加載一個 5G 數據文件會是什麼狀況。但大事務對內存和網絡的開銷，會影響集羣總體性能，仍是應儘可能避免大事務。

瞭解了組複製對大事務的處理方式，如何快速的導入數據？

正確作法是拆分紅小文件並行導入，mysql shell AdminAPI 早已集成了並行導入小工具，自動拆分並行處理，效率更高，開箱即用。

mysqlsh root@localhost:4000 --ssl-mode=DISABLED -- util import-table /Users/hongbin/mysql-sandboxes/4000/mysql-files/sbtest --schema=test --table=sbtest2 --bytes-per-chunk=10M

總結

1. 消息分片機制能在必定程度下降大事務形成節點被踢出集羣的機率，但集羣性能依然會受影響。
2. 大事務須要佔用更多 xcom cache 空間，xcom 要申請更多內存空間，也會有被 OOM 的風險。
3. 應儘可能避免大事務，調整 group_replication_transaction_size_limit、group_replication_message_cache_size、group_replication_communication_max_message_size、group_replication_member_expel_timeout 參數只能緩解部分問題。生產環境也不建議設置 group_replication_transaction_size_limit 爲 0。
4. 大文件數據加載應拆分後導入，推薦使用 mysql shell 的util.importTable。