建站
咨詢
售后
建站咨詢
新聞中心
一、MySQL的數(shù)據(jù)庫主從復制原理
成都創(chuàng)新互聯(lián)公司主要從事網(wǎng)站設計、網(wǎng)站建設、網(wǎng)頁設計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務。立足成都服務于都,十載網(wǎng)站建設經(jīng)驗,價格優(yōu)惠、服務專業(yè),歡迎來電咨詢建站服務:028-86922220
MySQL主從復制實際上基于二進制日志，原理可以用一張圖來表示：
MySQL數(shù)據(jù)庫主從同步延遲分析及解決方案
分為四步走：
1. 主庫對所有DDL和DML產(chǎn)生的日志寫進binlog；
2. 主庫生成一個 log dump 線程，用來給從庫I/O線程讀取binlog；
3. 從庫的I/O Thread去請求主庫的binlog，并將得到的binlog日志寫到relay log文件中；
4. 從庫的SQL Thread會讀取relay log文件中的日志解析成具體操作，將主庫的DDL和DML操作事件重放。
關于DDL和DML
SQL語言共分為四大類：查詢語言DQL，控制語言DCL，操縱語言DML，定義語言DDL。
DQL：可以簡單理解為SELECT語句；
DCL：GRANT、ROLLBACK和COMMIT一類語句；
DML：可以理解為CREATE一類的語句；
DDL：INSERT、UPDATE和DELETE語句都是；
二、主從復制存在的問題
1. 主庫宕機后，數(shù)據(jù)可能丟失；
2. 主從同步延遲。
三、MySQL數(shù)據(jù)庫主從同步延遲產(chǎn)生原因
原因分析：MySQL的主從復制都是單線程的操作，主庫對所有DDL和DML產(chǎn)生的日志寫進binlog，由于binlog是順序?qū)懀孕屎芨?。Slave的SQL Thread線程將主庫的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是隨即的，不是順序的，成本高很多。另一方面，由于SQL Thread也是單線程的，當主庫的并發(fā)較高時，產(chǎn)生的DML數(shù)量超過slave的SQL Thread所能處理的速度，或者當slave中有大型query語句產(chǎn)生了鎖等待那么延時就產(chǎn)生了。
常見原因：Master負載過高、Slave負載過高、網(wǎng)絡延遲、機器性能太低、MySQL配置不合理。
四、主從延時排查方法
通過監(jiān)控 show slave status 命令輸出的Seconds_Behind_Master參數(shù)的值來判斷：
NULL，表示io_thread或是sql_thread有任何一個發(fā)生故障；
0，該值為零，表示主從復制良好；
正值，表示主從已經(jīng)出現(xiàn)延時，數(shù)字越大表示從庫延遲越嚴重。
五、解決方案
解決數(shù)據(jù)丟失的問題：
1. 半同步復制
從MySQL5.5開始，MySQL已經(jīng)支持半同步復制了，半同步復制介于異步復制和同步復制之間，主庫在執(zhí)行完事務后不立刻返回結(jié)果給客戶端，需要等待至少一個從庫接收到并寫到relay log中才返回結(jié)果給客戶端。相對于異步復制，半同步復制提高了數(shù)據(jù)的安全性，同時它也造成了一個TCP/IP往返耗時的延遲。
2. 主庫配置sync_binlog=1，innodb_flush_log_at_trx_commit=1
sync_binlog的默認值是0，MySQL不會將binlog同步到磁盤，其值表示每寫多少binlog同步一次磁盤。
innodb_flush_log_at_trx_commit為1表示每一次事務提交或事務外的指令都需要把日志flush到磁盤。
注意:將以上兩個值同時設置為1時，寫入性能會受到一定限制，只有對數(shù)據(jù)安全性要求很高的場景才建議使用，比如涉及到錢的訂單支付業(yè)務，而且系統(tǒng)I/O能力必須可以支撐！
解決從庫復制延遲的問題：
1. 優(yōu)化網(wǎng)絡
2. 升級Slave硬件配置
3. Slave調(diào)整參數(shù)，關閉binlog，修改innodb_flush_log_at_trx_commit參數(shù)值
4. 升級MySQL版本到5.7，使用并行復制
網(wǎng)頁名稱：MySQL數(shù)據(jù)庫主從同步延遲分析及解決方案
當前鏈接：http://m.5511xx.com/article/cdpsjss.html
