技術分享 | MySQL 8.0 常見問題——複製篇

---

問題1：複製功能能夠在不一樣的操做系統上使用嗎？

答：能夠，複製功能能夠在不一樣的操做系統上面共同使用。

問題2：複製功能能夠在不一樣架構的硬件上使用嗎？

答：能夠，能夠在32位或64位架構的系統上共同使用。

問題3：主從複製時，從服務器必須老是鏈接到主服務器嗎？

答：不是。從服務器與主服務器的鏈接能夠斷開，當從新鏈接主服務器，從服務器會追趕主服務器上的更新。主從複製依賴於服務器上面的二進制日誌,當從服務器可以從最後讀取事件的位置繼續讀取二進制日誌時複製才能工做。所以，必須保證主服務器中還沒有複製到從服務器二進制日誌文件沒被刪除，纔可使斷開的從服務器從新鏈接主服務器繼續進行復制。

問題4：如何知道從服務器落後於主服務器多少？

答：執行SHOW SLAVE STATUS 語句，確認Seconds_Behind_Master 列的信息。

問題5：是否能夠強制主服務器阻止更新，直到從服務器遇上爲止?

答：能夠。
執行以下步驟：

• a. 在主服務器上執行：
  mysql> FLUSH TABLES WITH READ LOCK;
  mysql> SHOW MASTER STATUS;
• b. 在從服務器上執行下面的語句，函數的值使用上面輸出裏面相對應的值。
  mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
  SELECT語句被阻塞，直到從服務器到達指定的日誌文件和位置後，從服務器與主服務器保持同步，語句返回。
• c. 主服務器上，執行下面的語句，恢復更新處理：
  mysql> UNLOCK TABLES；

問題6：搭建雙向複製時應該注意哪些問題？

答：MySQL 的主從複製目前不支持主服務器和從服務器之間的任何鎖協議，沒法保證分佈式（跨服務器）更新的原子性。假設客戶端 A 對服務器 1 進行更新，同時，在它傳播到服務器 2 以前，客戶端 B 能夠對服務器 2 進行更新，這使得客戶端A的更新與對服務器 1 的更新不一樣。所以，當客戶端 A 更新到服務器2時，它生成的表與服務器 1 上的表不一樣。這意味着以雙向複製關係會具備很是大的風險——破壞數據的一致性，除非確保更新能夠以任何順序安全地進行，或者以某種方式在客戶端的代碼中處理。此外，就更新而言，雙向複製實際上並無顯著提升性能。每一個服務器必須執行相同數量的更新，就像單個服務器所作的同樣。唯一的區別是鎖的爭用要少一些，由於源自另外一臺服務器的更新是在一臺從服務器線程中序列化的。但這種好處也可能被網絡延遲所抵消。

問題7：如何利用複製改善系統性能？

答：能夠將一臺服務器設置爲主服務器，並將全部寫入指向它。而後在容許的範圍內配置儘量多的從服務器，並在主服務器和從服務器之間分配讀操做。還可使用 --skip-innodb 選項啓動從服務器，啓用 low_priority_updates 系統變量，並將 delay_key_write 系統變量設置爲 ALL，用以提高從服務器端速度。

對於處理頻繁讀取和少許寫入的系統，MySQL 複製是最有效的。理論上，使用一主多從的設置，能夠添加更多的從服務器來擴展系統，直到耗盡網絡帶寬，或者寫入負載增加到主服務器沒法處理它的程度。

若是想要肯定使用多少臺從服務器能夠提高性能，用戶必須瞭解系統的查詢模式，並對主服務器和從服務器上的讀寫吞吐量之間的關係進行基準測試。

假設系統負載由 10% 的寫入和 90% 的讀取組成，咱們經過基準測試肯定 R =1200 - 2 *W。（ R 和 W 表明每秒的讀取和寫入次數）換句話說，系統能夠在不進行寫入的狀況下每秒讀取 1200 次，平均的寫入速度是平均讀取速度的兩倍時長，而且關係是線性的。假設主服務器和每一個從服務器的性能相同，咱們有一個主服務器和 N 個從服務器。每臺服務器計算下面的等式：
R = 1200 - 2 * W
R = 9  W/ (N* + 1) (10%寫，90%讀。讀取被拆分，寫入被複制到全部從服務器。)
9  W / (N + 1) + 2  W = 1200
W = 1200 / (2 + 9/(N + 1))
最後一個等式表示了 N 個從服務器的最大寫入次數，給定最大可能的讀取速率爲每秒 1,200 次，每次寫入的讀取次數爲 9 次。

經過分析能夠得出如下結論：
若是 N=0，表示沒有使用複製功能，系統每秒能夠處理 1200/11=109 次寫操做。
若是 N=1，系統每秒能夠處理 184 次寫操做。
若是 N=8，系統每秒能夠處理 400 次寫操做。
若是 N=17，系統每秒能夠處理 480 次寫操做。
當 N 趨於無窮大時，咱們能夠很是接近每秒 600 次寫操做，將系統吞吐量提升約5.5倍。然而，在只有 8 臺服務器的狀況下，咱們將其增長了近 4 倍。
這些計算假定網絡帶寬是無限的，於是忽略了其餘幾個可能對系統很重要的因素。在大多數狀況下，用戶可能沒法執行相似的計算，但該計算能夠準確地預測若是添加 N 個從服務器將會在系統上發生什麼。
考慮如下問題能夠幫助決定複製是否會改善系統的性能，以及在多大程度上改善系統的性能：
a. 系統的讀/寫比率是多少?
b. 若是減小讀操做，一臺服務器能夠處理多少寫負載?
c. 網絡上有多少個從服務器可用帶寬?

問題8：如何使用複製功能提供高可用性？

答：如何實現冗餘取決於應用程序和系統環境。
高可用性解決方案（帶有自動故障轉移）須要系統監視工具、自定義腳本或中間件來提供從 MySQL 主服務器到從服務器的故障轉移。MySQL Router 能夠提供故障轉移。
若是要手動處理這個過程，能夠經過修改應用程序，讓其與新 MySQL 服務器通訊，或者將 DNS 從宕機的服務器調整到新的服務器。

問題9：如何防止 GRANT 和 REVOKE 語句複製到從服務器？

答：啓動服務器時，使用 --replicate-wild-ignore-table=mysql.% 選項，能夠忽略複製 mysql 數據庫下面的表。

問題10：如何知道從服務器複製最後一條語句的時間？

答：當從服務器的 SQL 線程執行從主服務器得到的事件時，它用事件的時間戳修改本身的時間。( 這也是 TIMESTAMP 能夠複製的緣由。) 在 SHOW PROCESSLIST 輸出的 Time 列中，從服務器 SQL 線程所顯示的秒數是上次複製事件的時間戳與從服務器的實際時間之間的秒數。可使用它來肯定最後一次複製事件的時間。假設從服務器與主服務器斷開鏈接一個小時，而後從新鏈接，可能會在 SHOW PROCESSLIST 的 Time 列看到相似 3600 這樣的大時間值，這是由於從服務器正在執行一個小時前的語句。