1樓：zhufeng
屬於資料冗餘技術，解決的問題是如何實現在不同位置儲存多份兒資料，來保證資料不會因為丟失乙份兒全部丟失的問題，這樣組成的架構，就是集群了，當然通過複製可以構造多種不同架構，所以解決的問題就是資料冗餘。
你所說的負載均衡等等問題都是在集群的基礎上，通過上層的邏輯，然後解決資料路由，讀寫分離等等問題，而剛剛說的資料複製，組成集群，資料冗餘都屬於物理層，可以這樣理解。
2樓：
主從複製解決不了很多問題：
1. 負載均衡，由於複製的時間差，不能保證同步讀，而且寫仍然單點，沒法多點寫，我對這個理解就是半吊子的讀寫均衡
2. 容災，基本都是有損容災，因為資料不同步，誰用誰知道，半吊子的容災
可能只是提供一種成本較低的資料備份方案加不完美的容災和負載均衡吧，這種方案注定是一種過渡方案，必將更新或被淘汰
3樓：櫻木花
複製顯然達不到集群的嚴格度，不論是HA 還AA（多活並行集群），複製都不能達不到資料一致性的集群要求， 複製很難嚴格界定是那種模式,可以歸類為：有一定冗餘度的非一致性非同步副本（不可靠不同步），對於沒有嚴格一致性要求的系統，可以定製為分擔負載、查詢過時報表的一種措施。
4樓：Frank 李先生
是不是負載均衡技術，這也不是乙個非黑即白的問題。可以說mysql主從資料複製一定程度上起到了負載均衡的作用。但其實主要目的還是為了保證資料冗餘和高可用性。
5樓：
贊同 @温國兵 的說法，主從既是資料庫的負載均衡的方案，同時也是保證資料高可用的技術方案。
去年去參加乙個線下沙龍，某位雲服務商的cto分享，乙份資料，至少有1+3份儲存，1主3從
6樓：Robin
嚴格地講，MySQL 複製屬於資料冗餘技術。不管是使用 MySQL NDB Cluster 還是 MySQL Replication 實現集群，都可以做到負載均衡，具體得看應用場景了。
MySQL主從複製鏈結問題？
one flower 複製是MySQL資料庫提供的一種高可用 高效能的解決方案，一般用來建立大型的應用。總體來說，複製的工作原理分為以下三個步驟 1 主伺服器把資料更新記錄到二進位制日誌中。2 從伺服器把主伺服器的二進位制日誌拷貝到自己的中繼日誌 Relay Log 中 3 從伺服器重做中繼日誌中的...
什麼情況會導致MySQL主從複製延遲？
愛可生 1.網路的延遲由於mysql主從複製是基於binlog的一種非同步複製，通過網路傳送binlog檔案，理所當然網路延遲是主從不同步的絕大多數的原因，特別是跨機房的資料同步出現這種機率非常的大，所以做讀寫分離，注意從業務層進行前期設計。2.主從兩台機器的負載不一致由於mysql主從複製是主資料...
MySQL 查詢 select from table where id in 幾百或幾千個 id 如何提高效率？
Gavin Wu 哈哈，看來純mysql的優化器確實還是比較捉急的，在oracle裡，這種情況一般用in謂詞條件，然後根據in後面的引數個數做執行計畫選擇，如果較短，會走in iterator，也就是每個表記錄進行if else判斷，要是深入想一下，這就是nested join，如果in後面引數較長...