mysql出現(xiàn)主從同步不一致的情況分析-創(chuàng)新互聯(lián)

本篇內(nèi)容主要講解“mysql出現(xiàn)主從同步不一致的情況分析”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“mysql出現(xiàn)主從同步不一致的情況分析”吧!

創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括府谷網(wǎng)站建設(shè)、府谷網(wǎng)站制作、府谷網(wǎng)頁(yè)制作以及府谷網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，府谷網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到府谷省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

1. MySQL數(shù)據(jù)庫(kù)主從同步延遲原理。

答：談到MySQL數(shù)據(jù)庫(kù)主從同步延遲原理，得從mysql的數(shù)據(jù)庫(kù)主從復(fù)制原理說(shuō)起，mysql的主從復(fù)制都是單線程的操作，主庫(kù)對(duì)所有DDL和 DML產(chǎn)生binlog，binlog是順序?qū)?，所以效率很高，slave的Slave_IO_Running線程到主庫(kù)取日志，效率很比較高，下一步， 問(wèn)題來(lái)了，slave的Slave_SQL_Running線程將主庫(kù)的DDL和DML操作在slave實(shí)施。DML和DDL的IO操作是隨即的，不是順 序的，成本高很多，還可能可slave上的其他查詢產(chǎn)生lock爭(zhēng)用，由于Slave_SQL_Running也是單線程的，所以一個(gè)DDL卡主了，需要 執(zhí)行10分鐘，那么所有之后的DDL會(huì)等待這個(gè)DDL執(zhí)行完才會(huì)繼續(xù)執(zhí)行，這就導(dǎo)致了延時(shí)。有朋友會(huì)問(wèn)：“主庫(kù)上那個(gè)相同的DDL也需要執(zhí)行10分，為什 么slave會(huì)延時(shí)？”，答案是master可以并發(fā)，Slave_SQL_Running線程卻不可以。

2. MySQL數(shù)據(jù)庫(kù)主從同步延遲是怎么產(chǎn)生的。

答：當(dāng)主庫(kù)的TPS并發(fā)較高時(shí)，產(chǎn)生的DDL數(shù)量超過(guò)slave一個(gè)sql線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與slave的大型query語(yǔ)句產(chǎn)生了鎖等待。

3. MySQL數(shù)據(jù)庫(kù)主從同步延遲解決方案

答：最簡(jiǎn)單的減少slave同步延時(shí)的方案就是在架構(gòu)上做優(yōu)化，盡量讓主庫(kù)的DDL快速執(zhí)行。還有就是主庫(kù)是寫(xiě)，對(duì)數(shù)據(jù)安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設(shè)置，而slave則不需要這么高的數(shù)據(jù)安全，完全可以講sync_binlog設(shè)置為0或者關(guān)閉binlog，innodb_flushlog也 可以設(shè)置為0來(lái)提高sql的執(zhí)行效率。另外就是使用比主庫(kù)更好的硬件設(shè)備作為slave。

mysql-5.6.3已經(jīng)支持了多線程的主從復(fù)制。

GTID的概念

     普通的復(fù)制過(guò)程中，從庫(kù)通過(guò)記錄主庫(kù)的binlog文件名和偏移量來(lái)記錄和接收主庫(kù)binlog的事件工作進(jìn)展。下次開(kāi)始復(fù)制的時(shí)候告知主庫(kù)這些信息，讓主庫(kù)可以從正確的位置開(kāi)始發(fā)送binlog的事件給從庫(kù)。但基于GTID的復(fù)制就不再需要告知這些事情，在執(zhí)行  CHANGE  MASTER  TO 命令，也不需要指定MASTER_LOG_FILE 和 MASTER_LOG_POS參數(shù)。只需要指定MASTER_AUTO_POSTION = 1 就可以了，主庫(kù)會(huì)根據(jù)從庫(kù)發(fā)送過(guò)來(lái)的一個(gè)GTID集合信息來(lái)決定從哪里開(kāi)始發(fā)送binlog事件。大大簡(jiǎn)化了數(shù)據(jù)庫(kù)管理員在復(fù)制中的工作。

    GTID是在數(shù)據(jù)庫(kù)提交事務(wù)時(shí)創(chuàng)建的唯一的標(biāo)示符。該標(biāo)示符與事務(wù)是一一相關(guān)的。

    GTID有兩部分組成，如下所示：

    GTID = source_id：transaction_id 

    source_id 用于標(biāo)識(shí)這個(gè)事務(wù)是在哪個(gè)數(shù)據(jù)庫(kù)實(shí)例上執(zhí)行的。用的是uuid作為source_id 。

    transaction_id 是一個(gè)序列號(hào)，取決于該事務(wù)在數(shù)據(jù)庫(kù)上的提交順序。該序列號(hào)初始為1.

在MySQL5.6以前的版本，同步復(fù)制都是單線程的，只能一個(gè)一個(gè)執(zhí)行。在5.6做到了多個(gè)庫(kù)多線程復(fù)制。

但是需要注意的是。一個(gè)庫(kù)只能由一個(gè)線程去復(fù)制。也就是說(shuō)若復(fù)制的庫(kù)只有1個(gè)，那么線程也只有一個(gè)。復(fù)制的庫(kù)有2個(gè)。那么線程可以增加到兩個(gè)。

GTID的作用，具體歸納下來(lái)有以下兩點(diǎn)：

   1.根據(jù)GTID來(lái)確認(rèn)事務(wù)最初的是在哪個(gè)實(shí)例上提交的

   2.GTID的存在方便了Replication和failover。

到此，相信大家對(duì)“mysql出現(xiàn)主從同步不一致的情況分析”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享題目：mysql出現(xiàn)主從同步不一致的情況分析-創(chuàng)新互聯(lián)
路徑分享：http://muchs.cn/article32/cesspc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計(jì)、網(wǎng)站內(nèi)鏈、服務(wù)器托管、網(wǎng)站收錄、做網(wǎng)站、用戶體驗(yàn)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

商城網(wǎng)站建設(shè)