軟上個月開始推出Windows 11的22H2版本。正如人們所習慣的那樣，它并沒有完全一帆風順。首先許多用戶報告說更新失敗，錯誤代碼是"0x800f0806"。還有一些常見的問題，如打印機問題導致2022年更新安裝后無法檢測到打印機，一系列問題導致微軟在受影響的設備上完全阻止更新。在此之后，微軟向IT管理員發出警告，因為它發現Windows 11 22H2的配置目前已經損壞。

與此同時微軟重新審視了另一個問題，該問題導致在Windows11 22H2系統上遠程進行大文件復制時速度大幅下降。該公司說，正在觀察到的速度降低了約40%。然而，用戶正在報告更糟糕的性能打擊。

ivicask是微軟技術社區論壇上的常客，他聲稱他看到了超過100%的性能影響。

我只想糾正Ned的40%慢的說法，我看到在10Gbps網卡（5Gbps與2Gbps）的配置上，或者在有多個千兆網卡的SMB多通道設置上，表現的差異甚至超過100%。

雖然這個bug最初被認為主要影響了服務器信息塊（SMB）協議，但微軟的Ned Pyle現在已經證實，他們最初的猜測有點偏差。顯然，這個問題存在于其他地方。

目前微軟方面并沒有分享太多細節，但我們確切地知道它是在操作系統內核中變慢的，與SMB或壓縮無關。

如果你正遭遇這個問題，微軟已經提供了一個詳細的解決方法，翻譯如下：

問題：

在Windows 11 22H2版本上復制大型多GB文件的時間可能比預期的要長。你更有可能遇到這個問題，通過服務器信息塊（SMB）從網絡共享復制文件到Windows 11 22H2版本，但本地文件復制也可能受到影響。消費者在家中或小型辦公室使用的Windows設備不可能受到這個問題的影響。

解決方案：

為了緩解這個問題，你可以使用不使用緩存管理器（緩沖I/O）的文件復制工具來暫時按照正常速度復制文件，這可以通過使用下面列出的內置命令行工具來實現。

robocopy\someserver\someshare c:\somefolder somefile.img /J

或

xcopy\someserver\someshare c:\somefolder /J

我們正在努力解決這個問題，并將在即將發布的版本中提供一個更新。

mysql主從同步延遲原因

導致備庫延遲的原因主要有如下幾種：

1. 通常備庫所在機器的性能要比主庫所在的機器性能差，執行備份自然會更慢。
2. 備庫的讀壓力大。在備庫過多的執行繁重的查詢任務。
3. 大事務。因為主庫上必須等事務執行完成才會寫入 binlog，再傳給備庫。一次性地用 delete 語句刪除太多數據、表 DDL都可能造成延遲。
4. 主庫是多線程操作，而從庫卻只有一個線程在執行復制。

主從同步延遲解決方案

解決方案：

1. 提升從庫物理機的配置，性能差異不要太大。
2. 業務的持久化層的實現采用分庫架構，mysql服務可平行擴展，分散壓力。
3. 采用讀寫分離，分散主庫壓力。
4. 加入緩存如Redis等，降低mysql的讀壓力。
5. 避免執行大事務等費時的操作，可以將事務內容拆開執行。
6. 使用同步并行復制方案MTS

并行復制

從MySQL5.6開始支持并行復制，這就解決了之前復制速度緩慢的問題。coordinator 就是原來的 sql_thread, 他負責讀取中轉日志和分發事務。真正更新日志的，變成了 worker 線程。work 線程的個數由參數 slave_parallel_workers 決定的。既然是并行就一定會有數據一致性的問題，兩個不同的事務如果在不同的work中同時執行，順序的影響也會造成結果不同。

所以在 coordinator 分發任務的時候，要滿足以下這兩個基本要求：

1. 不能造成更新覆蓋。這就要求更新同一行的兩個事務，必須被分發到同一個 worker 中。
2. 同一個事務不能被拆開，必須放到同一個 worker 中。

各個版本的多線程復制，都遵循了這兩條基本原則。

MySQL 5.6版本策略

官方 MySQL5.6 版本，支持了并行復制，只是支持的粒度是按庫并行。用于決定分發策略的 hash 表里，key 就是數據庫名，同一個數據庫需要在同一個worker中串行執行，這就避免了事務之間相互影響的問題。

MariaDB 策略

MariaDB 的并行復制策略利用redo log 組提交 (group commit) 優化的特性：能夠在同一組里提交的事務，一定不會修改同一行。所以可以按照食物的 commit—_id來分組。

在實現上，MariaDB 是這么做的：

• 在一組里面一起提交的事務，有一個相同的 commit_id，下一組就是 commit_id+1；
• commit_id 直接寫到 binlog 里面；傳到備庫應用的時候，相同 commit_id 的事務分發到多個 worker 執行；
• 這一組全部執行完成后，coordinator 再去取下一批。

MySQL 5.7策略

MySQL5.7中對 MariaDB 多策略進行了優化。因為同時處于 prepare 狀態的事務，在備庫執行時是可以并行的，此時的redolog已經經過了并行驗證，所以從庫也可以執行。具體步驟不做贅述，參考MariaDB策略。

MySQL 5.7.22 的并行復制策略

在 2018 年 4 月份發布的 MySQL 5.7.22 版本里（最新5.7.37），MySQL 增加了一個新的并行復制策略，基于 WRITESET 的并行復制。相應地，新增了一個參數 binlog-transaction-dependency-tracking，用來控制是否啟用這個新策略。這個參數的可選值有以下三種。

1. COMMIT_ORDER，表示的就是前面介紹的，根據同時進入 prepare 和 commit 來判斷是否可以并行的策略。
2. WRITESET，表示的是對于事務涉及更新的每一行，計算出這一行的 hash 值，組成集合 writeset。如果兩個事務沒有操作相同的行，也就是說它們的 writeset 沒有交集，就可以并行。
3. WRITESET_SESSION，是在 WRITESET 的基礎上多了一個約束，即在主庫上同一個線程先后執行的兩個事務，在備庫執行的時候，要保證相同的先后順序。

當然為了唯一標識，這個 hash 值是通過“庫名 + 表名 + 索引名 + 值”計算出來的。如果一個表上除了有主鍵索引外，還有其他唯一索引，那么對于每個唯一索引，insert 語句對應的 writeset 就要多增加一個 hash 值。

總結

總結一下，MySQL 并行復制策略主要是有三種思想：

1. 按照庫的級別粒度并行執行，用于決定分發策略的 hash 表里，key 就是數據庫名。
2. 按照行級別，根據id、唯一索引、value、庫名這些來計算hash值，做分組標示
3. 根據redo log 持久化原理，同一個commit組 或者 同時進入prepare或者commit表示可以同步執行。