複製拓撲
*
所有拓撲都應該遵循乙個備庫只能擁有乙個主庫，每個備庫只能有乙個
server id
的規則。
*一主多備。簡單的拓撲，但是能夠滿足大部分需求：
1.為不同的角色使用不同的備庫。
2.選用乙個備庫當作待用主庫，以備主備切換。
3.可以用於災難恢復。
4.可以將乙個備庫用作測試。對於這種結構需要關注多個備庫的延遲，對於延遲特別嚴重的需要進行一些處理。另外就是雖然多個備庫可以緩解讀壓力，但是對於寫壓力仍然在主庫上，並且隨著備庫的增多，主庫需要增加更多的
io執行緒來傳送
binlog
給備庫，這在擴充套件時需要注意。
-主動模式下的主主複製。這種將寫入分配給了兩台伺服器，很容易造成衝突從而導致資料不一致。比如說主鍵自增衝突，兩台主庫同時插入一行，結果兩台主庫的行都會使用同乙個主鍵，解決這個問題是設定
auto increment increment
和auto increment offset
，給主備庫主鍵設定乙個
offset
來避免衝突。此外還有其他一些問題，比如兩台伺服器同時對一些資料進行操作，執行複製時可能因為兩邊語句執行順序不一致導致問題。
-被動模式下的主主複製。這種複製解決了主動主動模式下的衝突問題。其中一台伺服器可以寫入，而另一台唯讀。這種模式下切換角色，進行故障轉移等都很方便。這裡有個細節就是，主動的語句複製到被動一方，被動一方執行後悔寫入自己的
binlog
，這時主動一方又會讀取被動一方的
binlog
，mysql
在這裡會忽略
binlog
中serverid
跟自己相同的語句，這也是為什麼要顯式設定
server id
的原因。
*環形結構。由三颱主庫相互順序連線形成。這個結構出現問題的機率大於上乙個模式，同時存在著乙個問題就是如果其中乙個主庫崩潰了，那麼這個主庫所造成的修改的語句會在仍然存活的兩個主庫上無限迴圈。
*分發主庫。前面提到，如果備庫數量過大，會使主庫存在過多
io執行緒進行
binlog
傳送，這裡有個解決方法就是設定乙個分發主庫，分發主庫不儲存資料，只儲存日誌，它接受主庫傳來的日誌，然後將所有表都設定為
blackhole
引擎，這個引擎會吞噬所有資料而不進行實際操作，因而不耗什麼時間，這樣做實際上就是將主庫的寫入功能和分發日誌功能分離以減輕主庫壓力。不過
blackhole
引擎仍然存在一些
bug，比如有時會忘記將自增
id寫入
binlog
，使用需要慎重。
*樹或金字塔模式。這種模式也可以減輕主庫的分發壓力，將分發的壓力下分給備庫，不過存在乙個問題就是如果中間層的備庫出現問題，那麼下面的備庫都會跟著出現問題，對恢復造成困難。
*部分資料備庫（資料分離）。考慮寫入壓力特別大的情況，由於備庫是單執行緒複製，這可能會造成很大的延遲。可以將主庫的資料庫分別分給每個備庫，這樣每個備庫只擁有一部資料庫，這減輕了主庫的分發壓力，每個執行緒只需傳輸一部分
binlog
，也減輕了每個備庫的讀取和重放壓力，只用處理一部分
binlog。*
功能分離。比如可以將應用的
oltp
查詢和olap
查詢分配到不同的備庫上，備庫間儲存相同的資料，但是使用不同的設定，引數，硬體，儲存引擎等。
*模擬多主庫複製。雖然說
mysql
備庫不支援多主庫複製，但是可以通過一些技巧來達成偽多主庫複製。一種方法是定時切換備庫的主庫，這適用於負載較低的情況。一種是使用主主結構並且配合
blackhole
引擎表。
Mysql主從複製和Redis主從複製的區別
這是學習的時候自己總結的筆記，因為使用typora記筆記，導致太多的筆記分散，所以傳到部落格方便查詢，代表的是typora裡的高亮 mysql主從複製和redis主從複製的區別 複製時機 mysql的主從複製是 從接入點開始 主機之前的資料，從機不會複製 但是redis是 從頭開始備份 主機之前的資...
mysql主從複製
罪過啊，博主最近好久沒有更新部落格了，轉有道雲筆記了，筆記裡還有些乾貨，最近慢慢分享出來吧。博主最近發現有好多想學，但是發現精力有限啊，博主本來是搞個開發的，但是偏偏想把運維，dba的技術全都學了 mysql集群，nginx等等等 但是發現精力有限，所以簡單了解一下，mysql的主從複製，後面還有m...
MySQL 主從複製
1.概念 將主伺服器的資料複製到另外一台或多台伺服器的過程。也即將主資料庫的ddl和dml操作通過二進位制日誌傳到復 務器上，然後在從伺服器上對這些日誌進行重新執行，從而 保持資料同步。2.作用 降低主伺服器的訪問壓力 避免主伺服器因故障導致資料丟失。3.操作步驟 1 主伺服器將資料的改變記錄到二進...