mysql架構(gòu)怎么玩 Mysql架構(gòu)
MySQL Mycat 分布式架構(gòu)
參考：
成都創(chuàng)新互聯(lián)公司為企業(yè)級客戶提高一站式互聯(lián)網(wǎng)+設(shè)計(jì)服務(wù)，主要包括網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)、重慶App定制開發(fā)、小程序設(shè)計(jì)、宣傳片制作、LOGO設(shè)計(jì)等，幫助客戶快速提升營銷能力和企業(yè)形象，創(chuàng)新互聯(lián)各部門都有經(jīng)驗(yàn)豐富的經(jīng)驗(yàn)，可以確保每一個(gè)作品的質(zhì)量和創(chuàng)作周期，同時(shí)每年都有很多新員工加入，為我們帶來大量新的創(chuàng)意。
圖中是兩組分片，紅色我們稱為shard1，藍(lán)色我們稱為shard2
51 52是服務(wù)器
兩個(gè)3307互為主從(雙主)，3309是本地3307的從庫
說明：沒有明確說明是只在某一個(gè)節(jié)點(diǎn)上做的，就是兩個(gè)節(jié)點(diǎn)都做
兩臺(tái)虛擬機(jī) db01 db02
每臺(tái)創(chuàng)建四個(gè)mysql實(shí)例：3307 3308 3309 3310
mysql軟件我們之前已完成二進(jìn)制安裝，直接初始化即可
我們server-id規(guī)劃為：db01上是7/8/9/10,db02上是17/18/19/20
"箭頭指向誰是主庫"
10.0.0.51:3307 ----- 10.0.0.52:3307
10.0.0.51:3309 ------ 10.0.0.51:3307
10.0.0.52:3309 ------ 10.0.0.52:3307
兩個(gè)分片，每個(gè)分片四個(gè)mysql節(jié)點(diǎn)
shard1：
Master：10.0.0.51:3307
slave1：10.0.0.51:3309
Standby Master：10.0.0.52:3307
slave2：10.0.0.52:3309
shard2：
Master：10.0.0.52:3308
slave1：10.0.0.52:3310
Standby Master：10.0.0.51:3308
slave2：10.0.0.51:3310
shard1
10.0.0.51:3307 ----- 10.0.0.52:3307
db02
db01
db02
10.0.0.51:3309 ------ 10.0.0.51:3307
db01
10.0.0.52:3309 ------ 10.0.0.52:3307
db02
shard2
10.0.0.52:3308 ----- 10.0.0.51:3308
db01
db02
db01
10.0.0.52:3310 ----- 10.0.0.52:3308
db02
10.0.0.51:3310 ----- 10.0.0.51:3308
db01
這個(gè)復(fù)制用戶在誰上建都行
注：如果中間出現(xiàn)錯(cuò)誤，在每個(gè)節(jié)點(diǎn)進(jìn)行執(zhí)行以下命令
常見方案：
360 Atlas-Sharding 360
Alibaba cobar 阿里
Mycat 開源
TDDL 淘寶
Heisenberg 百度
Oceanus 58同城
Vitess 谷歌
OneProxy
DRDS 阿里云
我們裝的是openjdk，不是官方的那個(gè)
Mycat-server-xxxxx.linux.tar.gz
配置環(huán)境變量
我們mycat的命令也是在bin目錄下
啟動(dòng)
8066就是對外提供服務(wù)的端口，9066是管理端口
連接mycat：
默認(rèn)123456
db01:
我們一般先把原schema.xml備份，然后自己新寫一個(gè)：
xml和html看起來差不多，xml是從下往上調(diào)用的
前三行我們不用看，直接從第四行schema開始看起：
定義了schema，然后以/schema結(jié)尾
為什么要用邏輯庫？
業(yè)務(wù)透明化
此配置文件就是實(shí)現(xiàn)讀寫分離的配置
重啟mycat
讀寫分離測試
總結(jié)：
以上案例實(shí)現(xiàn)了1主1從的讀寫分離功能，寫操作落到主庫，讀操作落到從庫.如果主庫宕機(jī)，從庫不能在繼續(xù)提供服務(wù)了。
我們推薦這種架構(gòu)
一寫三讀，
不設(shè)置雙寫的原因是：性能沒提升多少，反而引起主鍵沖突的情況
配置文件：
之后重啟：mycat restart
真正的 writehost：負(fù)責(zé)寫操作的writehost
standby writeHost ：和readhost一樣，只提供讀服務(wù)
我們此處寫了兩個(gè)writehost，默認(rèn)使用第一個(gè)
當(dāng)寫節(jié)點(diǎn)宕機(jī)后，后面跟的readhost也不提供服務(wù)，這時(shí)候standby的writehost就提供寫服務(wù)，
后面跟的readhost提供讀服務(wù)
測試：
讀寫分離測試
對db01 3307節(jié)點(diǎn)進(jìn)行關(guān)閉和啟動(dòng),測試讀寫操作
結(jié)果應(yīng)為另一臺(tái)(52)的3307(17)是寫，3309(19)是讀
一旦7號節(jié)點(diǎn)恢復(fù)，此時(shí)因?yàn)?落后了，寫節(jié)點(diǎn)仍是17
balance屬性
負(fù)載均衡類型，目前的取值有3種：
writeType屬性
負(fù)載均衡類型，目前的取值有2種：
switchType屬性
-1 表示不自動(dòng)切換
1 默認(rèn)值，自動(dòng)切換
2 基于MySQL主從同步的狀態(tài)決定是否切換 ，心跳語句為 show slave status
datahost其他配置
dataHost name="localhost1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1"
maxCon="1000"：最大的并發(fā)連接數(shù)
minCon="10" ：mycat在啟動(dòng)之后，會(huì)在后端節(jié)點(diǎn)上自動(dòng)開啟的連接線程，長連接，好處是連接速度快，弊端是占內(nèi)存
tempReadHostAvailable="1"
這個(gè)一主一從時(shí)（1個(gè)writehost，1個(gè)readhost時(shí)），可以開啟這個(gè)參數(shù)，如果2個(gè)writehost，2個(gè)readhost時(shí)
heartbeatselect user()/heartbeat 監(jiān)測心跳
其他參數(shù)sqlMaxLimit自動(dòng)分頁,必須在啟用分表的情況下才生效
創(chuàng)建測試庫和表:
我們重啟mycat后連接到8066
發(fā)現(xiàn)跟一個(gè)庫一樣，實(shí)際上已經(jīng)分到不同的物理硬件上了
分片：對一個(gè)"bigtable"，比如說t3表
熱點(diǎn)數(shù)據(jù)表 核心表
(1)行數(shù)非常多，800w下坡
(2)訪問非常頻繁
分片的目的：
（1）將大數(shù)據(jù)量進(jìn)行分布存儲(chǔ)
（2）提供均衡的訪問路由
分片策略：
范圍 range 800w 1-400w 400w01-800w 不適用于業(yè)務(wù)訪問不均勻的情況
取模 mod (取余數(shù)) 和節(jié)點(diǎn)的數(shù)量進(jìn)行取模
枚舉 按枚舉的種類分，如移動(dòng)項(xiàng)目按省份分
哈希 hash
時(shí)間 流水
優(yōu)化關(guān)聯(lián)查詢（否則join的表在不同分片上，效率會(huì)比單庫還要低）
全局表
ER分片
案例：移動(dòng)統(tǒng)一：先拆出邊緣業(yè)務(wù)，再按地域分片，但對應(yīng)用來說是統(tǒng)一的
vim rule.xml
tableRule name="auto-sharding-long"
rule
columnsid/columns
algorithmrang-long/algorithm
/rule
function name="rang-long"
class="io.mycat.route.function.AutoPartitionByLong"
property name="mapFile"autopartition-long.txt/property
/function
===================================
vim autopartition-long.txt
0-10=0
11-20=1
創(chuàng)建測試表：
mysql -S /data/3307/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t3 (id int not null primary key auto_increment,name varchar(20) not null);"
測試：
重啟mycat
mycat restart
mysql -uroot -p123456 -h 127.0.0.1 -P 8066
insert into t3(id,name) values(1,'a');
insert into t3(id,name) values(2,'b');
insert into t3(id,name) values(3,'c');
insert into t3(id,name) values(4,'d');
insert into t3(id,name) values(11,'aa');
insert into t3(id,name) values(12,'bb');
insert into t3(id,name) values(13,'cc');
insert into t3(id,name) values(14,'dd');
取余分片方式：分片鍵（一個(gè)列）與節(jié)點(diǎn)數(shù)量進(jìn)行取余，得到余數(shù)，將數(shù)據(jù)寫入對應(yīng)節(jié)點(diǎn)
vim schema.xml
table name="t4" dataNode="sh1,sh2" rule="mod-long" /
vim rule.xml
property name="count"2/property
準(zhǔn)備測試環(huán)境
創(chuàng)建測試表：
mysql -S /data/3307/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t4 (id int not null primary key auto_increment,name varchar(20) not null);"
重啟mycat
mycat restart
測試：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t4(id,name) values(1,'a');
insert into t4(id,name) values(2,'b');
insert into t4(id,name) values(3,'c');
insert into t4(id,name) values(4,'d');
分別登錄后端節(jié)點(diǎn)查詢數(shù)據(jù)
mysql -S /data/3307/mysql.sock
use taobao
select * from t4;
mysql -S /data/3308/mysql.sock
use taobao
select * from t4;
t5 表
id name telnum
1 bj 1212
2 sh 22222
3 bj 3333
4 sh 44444
5 bj 5555
sharding-by-intfile
vim schema.xml
table name="t5" dataNode="sh1,sh2" rule="sharding-by-intfile" /
vim rule.xml
tableRule name="sharding-by-intfile"
rule columnsname/columns
algorithmhash-int/algorithm
/rule
/tableRule
function name="hash-int" class="org.opencloudb.route.function.PartitionByFileMap"
property name="mapFile"partition-hash-int.txt/property
property name="type"1/property
property name="defaultNode"0/property
/function
partition-hash-int.txt 配置：
bj=0
sh=1
DEFAULT_NODE=1
columns 標(biāo)識將要分片的表字段，algorithm 分片函數(shù)， 其中分片函數(shù)配置中，mapFile標(biāo)識配置文件名稱
準(zhǔn)備測試環(huán)境
mysql -S /data/3307/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"
mysql -S /data/3308/mysql.sock -e "use taobao;create table t5 (id int not null primary key auto_increment,name varchar(20) not null);"
重啟mycat
mycat restart
mysql -uroot -p123456 -h10.0.0.51 -P8066
use TESTDB
insert into t5(id,name) values(1,'bj');
insert into t5(id,name) values(2,'sh');
insert into t5(id,name) values(3,'bj');
insert into t5(id,name) values(4,'sh');
insert into t5(id,name) values(5,'tj');
a b c d
join
t
select t1.name ,t.x from t1
join t
select t2.name ,t.x from t2
join t
select t3.name ,t.x from t3
join t
使用場景：
如果你的業(yè)務(wù)中有些數(shù)據(jù)類似于數(shù)據(jù)字典，比如配置文件的配置，
常用業(yè)務(wù)的配置或者數(shù)據(jù)量不大很少變動(dòng)的表，這些表往往不是特別大，
而且大部分的業(yè)務(wù)場景都會(huì)用到，那么這種表適合于Mycat全局表，無須對數(shù)據(jù)進(jìn)行切分，
要在所有的分片上保存一份數(shù)據(jù)即可，Mycat 在Join操作中，業(yè)務(wù)表與全局表進(jìn)行Join聚合會(huì)優(yōu)先選擇相同分片內(nèi)的全局表join，
避免跨庫Join，在進(jìn)行數(shù)據(jù)插入操作時(shí)，mycat將把數(shù)據(jù)分發(fā)到全局表對應(yīng)的所有分片執(zhí)行，在進(jìn)行數(shù)據(jù)讀取時(shí)候?qū)?huì)隨機(jī)獲取一個(gè)節(jié)點(diǎn)讀取數(shù)據(jù)。
vim schema.xml
table name="t_area" primaryKey="id" type="global" dataNode="sh1,sh2" /
后端數(shù)據(jù)準(zhǔn)備
mysql -S /data/3307/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null);
mysql -S /data/3308/mysql.sock
use taobao
create table t_area (id int not null primary key auto_increment,name varchar(20) not null);
重啟mycat
mycat restart
測試：
mysql -uroot -p123456 -h10.0.0.52 -P8066
use TESTDB
insert into t_area(id,name) values(1,'a');
insert into t_area(id,name) values(2,'b');
insert into t_area(id,name) values(3,'c');
insert into t_area(id,name) values(4,'d');
A
join
B
為了防止跨分片join，可以使用E-R模式
A join B
on a.xx=b.yy
join C
on A.id=C.id
table name="A" dataNode="sh1,sh2" rule="mod-long"
childTable name="B" joinKey="yy" parentKey="xx" /
/table
mysql是怎樣運(yùn)行的 從根兒上理解mysql
MySQL架構(gòu)如下：
我們寫的sql語句通過client對接MYSQL的連接層，然后有查詢緩存，語法解析器，優(yōu)化器，生成最終執(zhí)行計(jì)劃，然后去查詢插件式存儲(chǔ)引擎，如InnoDB等。我們的數(shù)據(jù)是通過存儲(chǔ)引擎來和物理設(shè)備交互的。
五大常見的MySQL高可用方案(最全)
1. 概述
我們在考慮MySQL數(shù)據(jù)庫的高可用的架構(gòu)時(shí)，主要要考慮如下幾方面：
如果數(shù)據(jù)庫發(fā)生了宕機(jī)或者意外中斷等故障，能盡快恢復(fù)數(shù)據(jù)庫的可用性，盡可能的減少停機(jī)時(shí)間，保證業(yè)務(wù)不會(huì)因?yàn)閿?shù)據(jù)庫的故障而中斷。
用作備份、只讀副本等功能的非主節(jié)點(diǎn)的數(shù)據(jù)應(yīng)該和主節(jié)點(diǎn)的數(shù)據(jù)實(shí)時(shí)或者最終保持一致。
當(dāng)業(yè)務(wù)發(fā)生數(shù)據(jù)庫切換時(shí)，切換前后的數(shù)據(jù)庫內(nèi)容應(yīng)當(dāng)一致，不會(huì)因?yàn)閿?shù)據(jù)缺失或者數(shù)據(jù)不一致而影響業(yè)務(wù)。
關(guān)于對高可用的分級在這里我們不做詳細(xì)的討論，這里只討論常用高可用方案的優(yōu)缺點(diǎn)以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步復(fù)制
使用雙節(jié)點(diǎn)數(shù)據(jù)庫，搭建單向或者雙向的半同步復(fù)制。在5.7以后的版本中，由于lossless replication、logical多線程復(fù)制等一些列新特性的引入，使得MySQL原生半同步復(fù)制更加可靠。
常見架構(gòu)如下：
通常會(huì)和proxy、keepalived等第三方軟件同時(shí)使用，即可以用來監(jiān)控?cái)?shù)據(jù)庫的 健康 ，又可以執(zhí)行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續(xù)使用數(shù)據(jù)庫。
優(yōu)點(diǎn)：
架構(gòu)比較簡單，使用原生半同步復(fù)制作為數(shù)據(jù)同步的依據(jù)；
雙節(jié)點(diǎn)，沒有主機(jī)宕機(jī)后的選主問題，直接切換即可；
雙節(jié)點(diǎn)，需求資源少，部署簡單；
缺點(diǎn)：
完全依賴于半同步復(fù)制，如果半同步復(fù)制退化為異步復(fù)制，數(shù)據(jù)一致性無法得到保證；
需要額外考慮haproxy、keepalived的高可用機(jī)制。
2.2. 半同步復(fù)制優(yōu)化
半同步復(fù)制機(jī)制是可靠的。如果半同步復(fù)制一直是生效的，那么便可以認(rèn)為數(shù)據(jù)是一致的。但是由于網(wǎng)絡(luò)波動(dòng)等一些客觀原因，導(dǎo)致半同步復(fù)制發(fā)生超時(shí)而切換為異步復(fù)制，那么這時(shí)便不能保證數(shù)據(jù)的一致性。所以盡可能的保證半同步復(fù)制，便可提高數(shù)據(jù)的一致性。
該方案同樣使用雙節(jié)點(diǎn)架構(gòu)，但是在原有半同復(fù)制的基礎(chǔ)上做了功能上的優(yōu)化，使半同步復(fù)制的機(jī)制變得更加可靠。
可參考的優(yōu)化方案如下：
2.2.1. 雙通道復(fù)制
半同步復(fù)制由于發(fā)生超時(shí)后，復(fù)制斷開，當(dāng)再次建立起復(fù)制時(shí)，同時(shí)建立兩條通道，其中一條半同步復(fù)制通道從當(dāng)前位置開始復(fù)制，保證從機(jī)知道當(dāng)前主機(jī)執(zhí)行的進(jìn)度。另外一條異步復(fù)制通道開始追補(bǔ)從機(jī)落后的數(shù)據(jù)。當(dāng)異步復(fù)制通道追趕到半同步復(fù)制的起始位置時(shí)，恢復(fù)半同步復(fù)制。
2.2.2. binlog文件服務(wù)器
搭建兩條半同步復(fù)制通道，其中連接文件服務(wù)器的半同步通道正常情況下不啟用，當(dāng)主從的半同步復(fù)制發(fā)生網(wǎng)絡(luò)問題退化后，啟動(dòng)與文件服務(wù)器的半同步復(fù)制通道。當(dāng)主從半同步復(fù)制恢復(fù)后，關(guān)閉與文件服務(wù)器的半同步復(fù)制通道。
優(yōu)點(diǎn)：
雙節(jié)點(diǎn)，需求資源少，部署簡單；
架構(gòu)簡單，沒有選主的問題，直接切換即可;
相比于原生復(fù)制，優(yōu)化后的半同步復(fù)制更能保證數(shù)據(jù)的一致性。
缺點(diǎn)：
需要修改內(nèi)核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開發(fā)。
依舊依賴于半同步復(fù)制，沒有從根本上解決數(shù)據(jù)一致性問題。
2.3. 高可用架構(gòu)優(yōu)化
將雙節(jié)點(diǎn)數(shù)據(jù)庫擴(kuò)展到多節(jié)點(diǎn)數(shù)據(jù)庫，或者多節(jié)點(diǎn)數(shù)據(jù)庫集群?？梢愿鶕?jù)自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由于半同步復(fù)制，存在接收到一個(gè)從機(jī)的成功應(yīng)答即認(rèn)為半同步復(fù)制成功的特性，所以多從半同步復(fù)制的可靠性要優(yōu)于單從半同步復(fù)制的可靠性。并且多節(jié)點(diǎn)同時(shí)宕機(jī)的幾率也要小于單節(jié)點(diǎn)宕機(jī)的幾率，所以多節(jié)點(diǎn)架構(gòu)在一定程度上可以認(rèn)為高可用性是好于雙節(jié)點(diǎn)架構(gòu)。
但是由于數(shù)據(jù)庫數(shù)量較多，所以需要數(shù)據(jù)庫管理軟件來保證數(shù)據(jù)庫的可維護(hù)性。可以選擇MMM、MHA或者各個(gè)版本的proxy等等。常見方案如下：
2.3.1. MHA+多節(jié)點(diǎn)集群
MHA Manager會(huì)定時(shí)探測集群中的master節(jié)點(diǎn)，當(dāng)master出現(xiàn)故障時(shí)，它可以自動(dòng)將最新數(shù)據(jù)的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個(gè)故障轉(zhuǎn)移過程對應(yīng)用程序完全透明。
MHA Node運(yùn)行在每臺(tái)MySQL服務(wù)器上，主要作用是切換時(shí)處理二進(jìn)制日志，確保切換盡量少丟數(shù)據(jù)。
MHA也可以擴(kuò)展到如下的多節(jié)點(diǎn)集群：
優(yōu)點(diǎn)：
可以進(jìn)行故障的自動(dòng)檢測和轉(zhuǎn)移;
可擴(kuò)展性較好，可以根據(jù)需要擴(kuò)展MySQL的節(jié)點(diǎn)數(shù)量和結(jié)構(gòu);
相比于雙節(jié)點(diǎn)的MySQL復(fù)制，三節(jié)點(diǎn)/多節(jié)點(diǎn)的MySQL發(fā)生不可用的概率更低
缺點(diǎn)：
至少需要三節(jié)點(diǎn)，相對于雙節(jié)點(diǎn)需要更多的資源;
邏輯較為復(fù)雜，發(fā)生故障后排查問題，定位問題更加困難;
數(shù)據(jù)一致性仍然靠原生半同步復(fù)制保證，仍然存在數(shù)據(jù)不一致的風(fēng)險(xiǎn);
可能因?yàn)榫W(wǎng)絡(luò)分區(qū)發(fā)生腦裂現(xiàn)象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式算法保證集群數(shù)據(jù)的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網(wǎng)絡(luò)分區(qū)現(xiàn)象的產(chǎn)生。
優(yōu)點(diǎn)：
較好的保證了整個(gè)系統(tǒng)的高可用性，包括proxy、MySQL;
擴(kuò)展性較好，可以擴(kuò)展為大規(guī)模集群;
缺點(diǎn)：
數(shù)據(jù)一致性仍然依賴于原生的mysql半同步復(fù)制;
引入zk，整個(gè)系統(tǒng)的邏輯變得更加復(fù)雜;
2.4. 共享存儲(chǔ)
共享存儲(chǔ)實(shí)現(xiàn)了數(shù)據(jù)庫服務(wù)器和存儲(chǔ)設(shè)備的解耦，不同數(shù)據(jù)庫之間的數(shù)據(jù)同步不再依賴于MySQL的原生復(fù)制功能，而是通過磁盤數(shù)據(jù)同步的手段，來保證數(shù)據(jù)的一致性。
2.4.1. SAN共享儲(chǔ)存
SAN的概念是允許存儲(chǔ)設(shè)備和處理器（服務(wù)器）之間建立直接的高速網(wǎng)絡(luò)（與LAN相比）連接，通過這種連接實(shí)現(xiàn)數(shù)據(jù)的集中式存儲(chǔ)。常用架構(gòu)如下：
使用共享存儲(chǔ)時(shí)，MySQL服務(wù)器能夠正常掛載文件系統(tǒng)并操作，如果主庫發(fā)生宕機(jī)，備庫可以掛載相同的文件系統(tǒng)，保證主庫和備庫使用相同的數(shù)據(jù)。
優(yōu)點(diǎn)：
兩節(jié)點(diǎn)即可，部署簡單，切換邏輯簡單；
很好的保證數(shù)據(jù)的強(qiáng)一致性；
不會(huì)因?yàn)镸ySQL的邏輯錯(cuò)誤發(fā)生數(shù)據(jù)不一致的情況；
缺點(diǎn)：
需要考慮共享存儲(chǔ)的高可用；
價(jià)格昂貴；
2.4.2. DRBD磁盤復(fù)制
DRBD是一種基于軟件、基于網(wǎng)絡(luò)的塊復(fù)制存儲(chǔ)解決方案，主要用于對服務(wù)器之間的磁盤、分區(qū)、邏輯卷等進(jìn)行數(shù)據(jù)鏡像，當(dāng)用戶將數(shù)據(jù)寫入本地磁盤時(shí)，還會(huì)將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中另一臺(tái)主機(jī)的磁盤上，這樣的本地主機(jī)(主節(jié)點(diǎn))與遠(yuǎn)程主機(jī)(備節(jié)點(diǎn))的數(shù)據(jù)就可以保證實(shí)時(shí)同步。常用架構(gòu)如下：
當(dāng)本地主機(jī)出現(xiàn)問題，遠(yuǎn)程主機(jī)上還保留著一份相同的數(shù)據(jù)，可以繼續(xù)使用，保證了數(shù)據(jù)的安全。
DRBD是linux內(nèi)核模塊實(shí)現(xiàn)的快級別的同步復(fù)制技術(shù)，可以與SAN達(dá)到相同的共享存儲(chǔ)效果。
優(yōu)點(diǎn)：
兩節(jié)點(diǎn)即可，部署簡單，切換邏輯簡單；
相比于SAN儲(chǔ)存網(wǎng)絡(luò)，價(jià)格低廉；
保證數(shù)據(jù)的強(qiáng)一致性；
缺點(diǎn)：
對io性能影響較大；
從庫不提供讀操作；
2.5. 分布式協(xié)議
分布式協(xié)議可以很好解決數(shù)據(jù)一致性問題。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通過使用NDB存儲(chǔ)引擎實(shí)時(shí)備份冗余數(shù)據(jù)，實(shí)現(xiàn)數(shù)據(jù)庫的高可用性和數(shù)據(jù)一致性。
優(yōu)點(diǎn)：
全部使用官方組件，不依賴于第三方軟件；
可以實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性；
缺點(diǎn)：
國內(nèi)使用的較少；
配置較復(fù)雜，需要使用NDB儲(chǔ)存引擎，與MySQL常規(guī)引擎存在一定差異；
至少三節(jié)點(diǎn)；
2.5.2. Galera
基于Galera的MySQL高可用集群， 是多主數(shù)據(jù)同步的MySQL集群解決方案，使用簡單，沒有單點(diǎn)故障，可用性高。常見架構(gòu)如下：
優(yōu)點(diǎn)：
多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性；
有成熟的社區(qū)，有互聯(lián)網(wǎng)公司在大規(guī)模的使用；
自動(dòng)故障轉(zhuǎn)移，自動(dòng)添加、剔除節(jié)點(diǎn)；
缺點(diǎn)：
需要為原生MySQL節(jié)點(diǎn)打wsrep補(bǔ)丁
只支持innodb儲(chǔ)存引擎
至少三節(jié)點(diǎn)；
2.5.3. POAXS
Paxos 算法解決的問題是一個(gè)分布式系統(tǒng)如何就某個(gè)值（決議）達(dá)成一致。這個(gè)算法被認(rèn)為是同類算法中最有效的。Paxos與MySQL相結(jié)合可以實(shí)現(xiàn)在分布式的MySQL數(shù)據(jù)的強(qiáng)一致性。常見架構(gòu)如下：
優(yōu)點(diǎn)：
多主寫入，無延遲復(fù)制，能保證數(shù)據(jù)強(qiáng)一致性；
有成熟理論基礎(chǔ)；
自動(dòng)故障轉(zhuǎn)移，自動(dòng)添加、剔除節(jié)點(diǎn)；
缺點(diǎn)：
只支持innodb儲(chǔ)存引擎
至少三節(jié)點(diǎn)；
3. 總結(jié)
隨著人們對數(shù)據(jù)一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數(shù)據(jù)一致性的問題，如MySQL自身的優(yōu)化、MySQL集群架構(gòu)的優(yōu)化、Paxos、Raft、2PC算法的引入等等。
而使用分布式算法用來解決MySQL數(shù)據(jù)庫數(shù)據(jù)一致性的問題的方法，也越來越被人們所接受，一系列成熟的產(chǎn)品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規(guī)模使用。
隨著官方MySQL Group Replication的GA，使用分布式協(xié)議來解決數(shù)據(jù)一致性問題已經(jīng)成為了主流的方向。期望越來越多優(yōu)秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
網(wǎng)頁題目：mysql架構(gòu)怎么玩 Mysql架構(gòu)
本文網(wǎng)址：http://m.jiaotiyi.com/article/doejceh.html