答：可以，複製功能可以在不同的作業系統上面共同使用。
問題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 這樣的大時間值，這是因為從伺服器正在執行一個小時前的語句。
愛可生開源社區將在 2019 年 10 月 26 日迎來在北京的首場 DBLE 用戶見面會，以線下互動分享的會議形式跟大家見面。
時間：10月26日 9:00 - 12:00 AM
地點：HomeCafe 上地店（北京市海澱區上地二街一號龍泉湖酒店對面）
重要提醒：
1. 同日下午還有 dbaplus 社群舉辦的沙龍：聚焦數據中臺、數據架構與優化。
2. 愛可生開源社區會在每年10.24日開源一款高質量產品。本次在 dbaplus 沙龍會議上，愛可生的資深研發工程師閆阿龍，將為大家帶來《金融分布式事務實踐及txle概述》，並在現場開源。
診斷範圍支持：
Mycat 的故障診斷、源碼分析、性能優化
服務支持渠道：
技術交流群，進群後可提問
QQ群（669663113）
社區通道，郵件&電話
osc@actionsky.com
現場拜訪，線下實地，1天免費拜訪
關注「愛可生開源社區」公眾號，回復關鍵字「Mycat」，獲取活動詳情。
徵稿內容：
格式：.md/.doc/.txt
主題：MySQL、分布式中間件DBLE、數據傳輸組件DTLE相關技術內容
要求：原創且未發布過
獎勵：作者署名；200元京東E卡+社區周邊
投稿方式：
郵箱：osc@actionsky.com
格式：[投稿]姓名+文章標題
以附件形式發送，正文需註明姓名、手機號、微信號，以便小編及時聯繫
喜歡點「分享」，不行就「在看」