mysql主從同步一直在進行嗎？

開啟後，沒有停機、錯誤或任何東西，並且會繼續進行。

從理論上講，主從複製支援無限數量的從站，但實際上，它受到伺服器頻寬和讀寫能力的影響。

從理論上講，通過使用單個主伺服器多從伺服器設定，可以通過新增更多從伺服器來擴充套件系統，直到網路頻寬用完或更新負載增長到主伺服器無法處理的程度。

為了確定您可以擁有多少個從站，以及您可以提高站點效能的程度，您需要了解查詢模式和基準測試，並根據經驗確定典型主伺服器和從伺服器的讀取（每秒讀取次數或最大讀取次數）吞吐量與寫入（最大寫入次數）吞吐量之間的關係。 使用乙個具有複製功能的假設系統，這個例子給出了乙個非常簡單的冰雹埋葬計算。

假設系統負載包括 10% 的寫入和 90% 的讀取，我們通過基準測試確定最大讀取為 1200 2 個最大寫入。 換言之，在不進行寫入的情況下，系統每秒可以執行 1,200 次讀取，平均寫入操作所需的時間是平均讀取操作的兩倍，並且關係是線性的。 我們假設主伺服器和每個從伺服器具有相同的效能，並且我們有乙個主伺服器和 n 個從伺服器。

好吧，對於每個伺服器（主伺服器或從伺服器），我們有：

reads=1200_2×writes

reads=9 次寫入 （n1）（讀取是分離的，但寫入所有伺服器）。

9×writes/(n1)2×writes=1200

writes=1200/(29/(n1))

最後乙個公式表示對 n 個從屬伺服器的最大寫入次數，假設最大可能的讀取速率為每分鐘 1,200 次，並且讀取與寫入的比率為 9。

上述分析可以得出以下結論：

如果 n=0（表示沒有複製），則系統每秒可以處理大約 1200 次 11=109 次寫入。

如果 n = 1，則每秒可進行 184 次寫入。

如果 n=8，則每秒可進行 400 次寫入。

如果 n = 17，則每秒可進行 480 次寫入。

1.從屬裝置過多會導致複製延遲。

優化：建議從機數量為3-5個。

2.從屬硬體比主硬體差。

優化：提公升硬體效能。

3.慢速 SQL 語句太多。

優化：SQL語句執行時間過長，SQL語句4主從複製的設計問題。

優化：主從複製為單執行緒，可通過多執行緒IO方案解決。 此外，還支援多執行緒 IO 複製。

5.主資料庫和從資料庫之間的網路延遲。

優化：保持鏈路盡可能短，增加埠頻寬。

6.主資料庫具有較高的讀寫壓力。

優化：在前端增加緩衝區和快取。 主從延遲不同步：

再耽誤，只要不影響業務，就沒事了。

7. 業務設計缺陷導致延誤，影響業務。

優化：二級資料庫的資料不會跳轉到主資料庫。

當我使用 pt-table-checksum 時，會影響業務績效嗎？

實驗。 讓我們從一對主從開始：

然後使用 mysqlslap 執行恆定壓力：

開啟另乙個租約大型會話，並在主節點上開啟常規日誌：

然後通過 pt-table-checksum 進行比較：

檢視 master 的一般日誌，由於 mysqlslap 導致的通用日誌中有很多內容，我們找到與 pt-table-checksum 相關的執行緒：

世界銀行單獨列出了此執行緒的操作

有很多操作，讓我們一點一一地解釋一下：

在這裡，該工具減少了 INNODB 鎖定等待時間。 這樣一來，只要在innodb上稍有鎖，操作就會立即放棄，對業務的影響就會很小。

此外，該工具減少了等待超時時間，沒有特殊效果。

該工具將隔離級別調整為 RR 級別，交易的維護成本會高於 RC，但正如我們稍後將看到的，該工具使用的每個交易都非常小，並且前面提到的 innodb 鎖的等待時間調整為乙個小，這將對線上業務造成更少的成本。

RR水平是資料比較的基本要求。

該工具通過一系列操作提供表的概述。 一次驗證乙個塊，此處獲得第乙個塊的下邊界。

接下來，工具獲取下乙個資料塊的下邊界，並在每個 SQL 之前進行解釋，看看執行是否作弊，回租非常小心。

之後，工具獲取乙個資料塊的校驗和，該校驗和並不大，如果與業務流量發生衝突，它會立即啟動 innodb 的鎖定超時並立即撤退。

以上是 pt-table-checksum 的一些設計，可以看到這些地方都經過精心維護，以確保業務流量不受影響。

該工具還設計了其他機制來保證業務流量，例如引數 --max-load 和 --pause-file，以及精心設計的資料塊劃分方法、索引選擇方法等。 大家可以根據自己的情況一起使用，以達到良好的效果。

總結。 本期我們簡單分析一下pt-table-checksum是否會影響業務流量，推薦使用或不推薦使用工具的各種引數，算命的案例很多，可以用簡單的實驗來分析作用機理。

同樣，效能測試不能被道聽途說所信任，而必須通過實驗進行分析。