一个色综合导航,国产福利一区二区在线观看,国产精品久久久久久久久久大牛

MySQL主從模式是指數(shù)據(jù)可以從一個(gè)MySQL數(shù)據(jù)庫(kù)服務(wù)器主節(jié)點(diǎn)復(fù)制到一個(gè)或多個(gè)從節(jié)點(diǎn)。MySQL 默認(rèn)采用異步復(fù)制方式，這樣從節(jié)點(diǎn)不用一直訪問(wèn)主服務(wù)器來(lái)更新自己的數(shù)據(jù)，從節(jié)點(diǎn)可以復(fù)制主數(shù)據(jù)庫(kù) 中的所有數(shù)據(jù)庫(kù)，或者特定的數(shù)據(jù)庫(kù)，或者特定的表。

阿粉在前面的幾篇文章中，說(shuō)了索引的分析，索引的原理，以及慢查詢應(yīng)該怎么去做合理的優(yōu)化，接下來(lái)阿粉也給大家說(shuō)說(shuō)這個(gè) MySQL 的組從復(fù)制到底是個(gè)怎么回事。

主從模式

mysql主從復(fù)制用途：

實(shí)時(shí)災(zāi)備，用于故障切換（高可用）
讀寫(xiě)分離，提供查詢服務(wù)（讀擴(kuò)展）
數(shù)據(jù)備份，避免影響業(yè)務(wù)（高可用）

主從部署必要條件：

從庫(kù)服務(wù)器能連通主庫(kù)
主庫(kù)開(kāi)啟binlog日志（設(shè)置log-bin參數(shù)）
主從server-id不

上面這些就是我們?nèi)绻胍渴鹨惶讓儆谧约旱?MySQL 的主從復(fù)制時(shí)，需要的條件，那么主從復(fù)制都是什么原理呢？

主從復(fù)制的步驟

主從復(fù)制整體分為以下三個(gè)步驟：

第一步：主庫(kù)將數(shù)據(jù)庫(kù)的變更操作記錄到Binlog日志文件中

第二步：從庫(kù)讀取主庫(kù)中的Binlog日志文件信息寫(xiě)入到從庫(kù)的Relay Log中繼日志中

第三步：從庫(kù)讀取中繼日志信息在從庫(kù)中進(jìn)行Replay,更新從庫(kù)數(shù)據(jù)信息

上面的是文字描述，

我們?cè)賮?lái)一張?jiān)韴D看看：

在上述三個(gè)過(guò)程中，涉及了Master的BinlogDump Thread和Slave的I/O Thread、SQL Thread，它們的作用如下：

Master服務(wù)器對(duì)數(shù)據(jù)庫(kù)更改操作記錄在Binlog中，BinlogDump Thread接到寫(xiě)入請(qǐng)求后，讀取 Binlog信息推送給Slave的I/O Thread。
Slave的I/O Thread將讀取到的Binlog信息寫(xiě)入到本地Relay Log中。
Slave的SQL Thread檢測(cè)到Relay Log的變更請(qǐng)求，解析relay log中內(nèi)容在從庫(kù)上執(zhí)行。上述過(guò)程都是異步操作，俗稱異步復(fù)制，存在數(shù)據(jù)延遲現(xiàn)象。

但是如果我們這么看主從復(fù)制的話，是不是會(huì)發(fā)現(xiàn)一些問(wèn)題呢？

MySQL主從復(fù)制的問(wèn)題：

主庫(kù)宕機(jī)后，數(shù)據(jù)可能丟失
從庫(kù)只有一個(gè)SQL Thread，主庫(kù)寫(xiě)壓力大，復(fù)制很可能延時(shí)

一般的，如果我們做了主從復(fù)制的話，那么數(shù)據(jù)庫(kù)一定出現(xiàn)過(guò)復(fù)制延遲的情況，如果你沒(méi)遇到過(guò)，說(shuō)明你沒(méi)有發(fā)現(xiàn)過(guò)，但是實(shí)際上是肯定有過(guò)的，除非你已經(jīng)想到了如何去解決這個(gè)問(wèn)題了，那么解決這個(gè)問(wèn)題的方式是什么呢？

半同步復(fù)制---解決數(shù)據(jù)丟失的問(wèn)題
并行復(fù)制----解決從庫(kù)復(fù)制延遲的問(wèn)題

那么什么是半同步復(fù)制，什么是并行復(fù)制呢？

半同步復(fù)制

為了提升數(shù)據(jù)安全，MySQL讓Master在某一個(gè)時(shí)間點(diǎn)等待Slave節(jié)點(diǎn)的 ACK（Acknowledge character）消息，接收到ACK消息后才進(jìn)行事務(wù)提交，這也是半同步復(fù)制的基礎(chǔ)。

當(dāng)Master不需要關(guān)注Slave是否接受到Binlog Event時(shí)，即為傳統(tǒng)的主從復(fù)制。
當(dāng)Master需要在第三步等待Slave返回ACK時(shí)，即為 after-commit，半同步復(fù)制（MySQL 5.5引入）。
當(dāng)Master需要在第二步等待 Slave 返回 ACK 時(shí)，即為 after-sync，增強(qiáng)半同步（MySQL 5.7引入）。

主庫(kù)等待從庫(kù)寫(xiě)入 relay log 并返回 ACK 后才進(jìn)行Engine Commit。

并行復(fù)制

其實(shí) MySQL 的并行復(fù)制，每個(gè)版本都是不一樣的，因?yàn)樗麄兊膶?shí)現(xiàn)原理是不一樣的。

MySQL從5.6版本開(kāi)始追加了并行復(fù)制功能，目的就是為了改善復(fù)制延遲問(wèn)題，并行復(fù)制稱為enhanced multi-threaded slave（簡(jiǎn)稱MTS）。

在從庫(kù)中有兩個(gè)線程IO Thread和SQL Thread，都是單線程模式工作，因此有了延遲問(wèn)題，我們可以采用多線程機(jī)制來(lái)加強(qiáng)，減少?gòu)膸?kù)復(fù)制延遲。

MySQL5.7版本，基于組提交的并行復(fù)制，這個(gè)才是真正意義的并行復(fù)制，從庫(kù)的并行復(fù)制跟master庫(kù)的是一致，并行復(fù)制基于一個(gè)前提，即所有已經(jīng)處于prepare階段的事務(wù)，都是可以并行提交的。

MySQL8.0版本，基于write-set的并行復(fù)制，MySQL會(huì)有一個(gè)集合變量用來(lái)存儲(chǔ)事務(wù)修改的記錄信息（主鍵哈希值），當(dāng)新的修改時(shí)已提交時(shí)，會(huì)進(jìn)行判斷是否沖突，不沖突即可合并，這樣的并行的顆粒度就到row級(jí)別了，并行復(fù)制的速度更快

其實(shí)如果你想要進(jìn)行并行復(fù)制的話，那么你還需要知道如何去進(jìn)行并行復(fù)制的調(diào)優(yōu)，只有這樣，你才能掌握好這個(gè)主從復(fù)制。

binlog_transaction_dependency_history_size 用于控制集合變量的大小。

binlog_transaction_depandency_tracking 用于控制binlog文件中事務(wù)之間的依賴關(guān)系，即last_committed值。

transaction_write_set_extraction用于控制事務(wù)的檢測(cè)算法，參數(shù)值為：OFF、 XXHASH64、MURMUR32

master_info_repository開(kāi)啟MTS功能后，務(wù)必將參數(shù)master_info_repostitory設(shè)置為T(mén)ABLE，這樣性能可以有50%~80%的提升。這是因?yàn)椴⑿袕?fù)制開(kāi)啟后對(duì)于元master.info這個(gè)文件的更新將會(huì)大幅提升，資源的競(jìng)爭(zhēng)也會(huì)變大。

slave_parallel_workers若將slave_parallel_workers設(shè)置為0，則MySQL 5.7退化為原單線程復(fù)制，但將 slave_parallel_workers設(shè)置為1，則SQL線程功能轉(zhuǎn)化為coordinator線程，但是只有1個(gè)worker線程進(jìn)行回放，也是單線程復(fù)制。然而，這兩種性能卻又有一些的區(qū)別，因?yàn)槎嗔艘淮蝐oordinator線程的轉(zhuǎn)發(fā)，因此slave_parallel_workers=1的性能反而比0還要差。

這些參數(shù)實(shí)際上都是非常要掌握的，不然你再設(shè)置并行復(fù)制的時(shí)候，會(huì)遇到各種各樣的問(wèn)題，所以你學(xué)會(huì)了么？