主從架構設計

查看binlog

show master status; show BINLOG events in 'BUUUG-bin.000120';

主從同步需要考慮的風險

• 突然斷電導致主從數據不一致
• 數據同步延遲問題（主庫寫，從庫查）

如何避免

同步方式：
異步同步（保證性能不會受到同步的影響）
半同步：同步時等待，直到數據已經同步到relay binlog之后，才可以返回到Web/App Server
強制讀主…等

不同的主從架構方案

1、一主一從
Slave可以用來做Master的備份。

2、一主多從（應用較廣泛）
Master承載了大部分的寫請求，Slave承載大部分的讀請求。同時可以在Slave3中做備份節點，用于定時任務操作/線下查生產環境數據（哪怕是把數據改了，也不會影響線上）等。選一個Slave做Master的備份，當Master掛掉之后，使用Slave承擔Master 的工作。

3、雙主
適合寫請求壓力非常大的情況。比如對id取模，偶數寫進一個節點，奇數寫進另一個節點。缺點是如果其中一個掛了，整個系統就掛了。

4、級聯同步
優點：如果Master掛掉，剩下的Slave是一個天然的主從架構。Master只和一個Slave同步，減輕Master的壓力。

5、環形多主
早期淘寶使用過，Master上再接許多從庫，形成數據庫矩陣，用于提高承載性。
但是只要掛掉一個Master，整體就掛了。特殊情況使用。
現在很少使用了

使用Docker

不推薦在Docker容器中存放頻繁讀寫的文件系統，因為Docker的文件系統是虛擬的，其增刪改查操作相對于直接訪問主機里的文件系統來說，速度會慢很多。

所以，為了提高性能，應該將Data目錄以及配置文件掛載在容器外面。

MySQL主從架構的實現方案

將寫請求發動到Master中，將讀請求發送到Slave中
不推薦使用AOP進行insert/select分離，因為會增加整個業務系統的復雜性，需要進行修改程序、測試等一系列操作。AOP在調試的時候不是線性的調試，如果對別人寫的AOP邏輯了解的話，不容易找到問題出在哪里。

有一些第三方的組件幫助我們進行讀寫分離，如 sharing-jdbc 等，是侵入式的方案。

使用中心代理節點的方案，對insert/select進行分發，可以屏蔽后端MySQL架構的復雜性，從而讓MySQL后端架構對于開發人員來說是透明的。

可以使用MyCat或者Atlas

編寫docker-compose.yml

主庫的配置



配置完之后，重啟數據庫
dc restart master

再使用show master status;查看 Binlog_Do_DB，會發現多了一個庫

從庫的配置



配置完之后，重啟數據庫
dc restart slave1

需要配置主庫信息，才能知道要從哪一個庫同步

可以使用show slave status查看slave的同步狀態

slave2的配置與slave1相同

Atlas的配置

全部啟動

總結

以上是生活随笔為你收集整理的【MySQL】主从复制架构方案 - 笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。