MySQL 主從一直是面試?？?，里面的知識(shí)點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。
公司主營業(yè)務(wù)：做網(wǎng)站、成都網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出明水免費(fèi)做網(wǎng)站回饋大家。
比如樓哥之前面試小米，就被問到過主從復(fù)制的原理，以及主從延遲的解決方案，因?yàn)榛卮鸬姆浅２诲e(cuò)，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？
所謂 MySQL 主從，就是建立兩個(gè)完全一樣的數(shù)據(jù)庫，一個(gè)是主庫，一個(gè)是從庫， 主庫對(duì)外提供讀寫的操作，從庫對(duì)外提供讀的操作 ，下面是一主一從模式：
對(duì)于數(shù)據(jù)庫單機(jī)部署，在 4 核 8G 的機(jī)器上運(yùn)行 MySQL 5.7 時(shí)，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動(dòng)時(shí)，查詢流量驟然，就需要進(jìn)行主從分離。
大部分系統(tǒng)的訪問模型是讀多寫少，讀寫請(qǐng)求量的差距可能達(dá)到幾個(gè)數(shù)量級(jí)，所以我們可以通過一主多從的方式， 主庫只負(fù)責(zé)寫入和部分核心邏輯的查詢，多個(gè)從庫只負(fù)責(zé)查詢，提升查詢性能，降低主庫壓力。
MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫宕機(jī)時(shí)，從庫可以切成主庫，保證服務(wù)的高可用，然后主庫也可以做數(shù)據(jù)的容災(zāi)備份。
整體場景總結(jié)如下：
MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。
主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐?，一般這個(gè)過程是異步的，即主庫上的操作不會(huì)等待 binlog 同步的完成。
詳細(xì)流程如下：
當(dāng)主庫和從庫數(shù)據(jù)同步時(shí)，突然中斷怎么辦？因?yàn)橹鲙炫c從庫之間維持了一個(gè)長鏈接，主庫內(nèi)部有一個(gè)線程，專門服務(wù)于從庫的這個(gè)長鏈接的。
對(duì)于下面的情況，假如主庫執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：
我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數(shù)據(jù)一般是不一樣的。
所以就會(huì)存在這種情況：在 binlog = statement 格式時(shí)，主庫在執(zhí)行這條 SQL 時(shí)，使用的是索引 a，而從庫在執(zhí)行這條 SQL 時(shí)，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。
那么我們改如何解決呢？
可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個(gè) event:Table_map 和 Delete_rows。
Table_map event 說明要操作的表，Delete_rows event用于定義要?jiǎng)h除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要?jiǎng)h除的主鍵 ID 信息，因此不會(huì)出現(xiàn)主從不一致的問題。
但是如果 SQL 刪除 10 萬行數(shù)據(jù)，使用 row 格式就會(huì)很占空間的，10 萬條數(shù)據(jù)都在 binlog 里面，寫 binlog 的時(shí)候也很耗 IO。但是 statement 格式的 binlog 可能會(huì)導(dǎo)致數(shù)據(jù)不一致。
設(shè)計(jì) MySQL 的大叔想了一個(gè)折中的方案，mixed 格式的 binlog，其實(shí)就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時(shí)，就用 row 格式，否則使用就用 statement 格式。
有時(shí)候我們遇到從數(shù)據(jù)庫中獲取不到信息的詭異問題時(shí)，會(huì)糾結(jié)于代碼中是否有一些邏輯會(huì)把之前寫入的內(nèi)容刪除，但是你又會(huì)發(fā)現(xiàn)，過了一段時(shí)間再去查詢時(shí)又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。
主從延遲，其實(shí)就是“從庫回放” 完成的時(shí)間，與 “主庫寫 binlog” 完成時(shí)間的差值， 會(huì)導(dǎo)致從庫查詢的數(shù)據(jù)，和主庫的不一致 。
談到 MySQL 數(shù)據(jù)庫主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說起：
總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過從庫一個(gè) SQL 線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與從庫的大型 query 語句產(chǎn)生了鎖等待。
我們一般會(huì)把從庫落后的時(shí)間作為一個(gè)重點(diǎn)的數(shù)據(jù)庫指標(biāo)做監(jiān)控和報(bào)警，正常的時(shí)間是在毫秒級(jí)別，一旦落后的時(shí)間達(dá)到了秒級(jí)別就需要告警了。
解決該問題的方法，除了縮短主從延遲的時(shí)間，還有一些其它的方法，基本原理都是盡量不查詢從庫。
具體解決方案如下：
在實(shí)際應(yīng)用場景中，對(duì)于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。
兩臺(tái)機(jī)器 A 和 B，A 為主庫，負(fù)責(zé)讀寫，B 為從庫，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，修復(fù)故障后，A 成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。
一臺(tái)主庫多臺(tái)從庫，A 為主庫，負(fù)責(zé)讀寫，B、C、D為從庫，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。
您好，我來為您解答：
方法1．使用reset master命令
方法2．使用purge master logs to命令
方法3．使用purge master logs before命令
方法4．在my.ini配置文件[mysqld]選項(xiàng)組中設(shè)置expire_logs_days參數(shù)
轉(zhuǎn)載，僅供參考。
如果我的回答沒能幫助您，請(qǐng)繼續(xù)追問。
MySQL主從又叫做Replication、AB復(fù)制。簡單講就是A和B兩臺(tái)機(jī)器做主從后，在A上寫數(shù)據(jù)，另外一臺(tái)B也會(huì)跟著寫數(shù)據(jù)，兩者數(shù)據(jù)實(shí)時(shí)同步；
MySQL主從是基于binlog的，主上須開啟binlog才能進(jìn)行主從。
主從過程大致有3個(gè)步驟
1）主將更改操作記錄到binlog里；
2）從將主的binlog事件(sql語句)同步到從本機(jī)上并記錄在relaylog里；
3）從根據(jù)relaylog里面的sql語句按順序執(zhí)行；
主上有一個(gè)log dump線程，用來和從的I/O線程傳遞binlog
從上有兩個(gè)線程，其中I/O線程用來同步主的binlog并生成relaylog，另外一個(gè)SQL線程用來把relaylog里面的sql語句落地
同步參數(shù)“主”“從”上均可設(shè)置，只要設(shè)置一個(gè)就可以了
重置mysql主從同步（MySQL Reset Master-Slave Replication）
在mysql主從同步的過程中，可能會(huì)因?yàn)楦鞣N原因出現(xiàn)主庫與從庫不同步的情況，網(wǎng)上雖然有一些解決辦法，但是有時(shí)很難徹底解決，重置主從服務(wù)器也許不是最快的辦法，但卻是最安全有效的。
下面將自己重置主從同步的步驟總結(jié)一下，以備不時(shí)之需。
master與slave均使用：centos6.0+mysql 5.1.61 ，假設(shè)有db1,db2兩個(gè)數(shù)據(jù)庫需要熱備。
文中shell與mysql均使用root賬號(hào)，在真實(shí)環(huán)境中，請(qǐng)根據(jù)情況更換。
1.停止slave服務(wù)器的主從同步
為了防止主從數(shù)據(jù)不同步，需要先停止slave上的同步服務(wù)。
STOP SLAVE;
2.對(duì)master服務(wù)器的數(shù)據(jù)庫加鎖
為了避免在備份的時(shí)候?qū)?shù)據(jù)庫進(jìn)行更新操作，必須對(duì)數(shù)據(jù)庫加鎖。
FLUSH TABLES WITH READ LOCK;
如果是web服務(wù)器也可以關(guān)閉apache或nginx服務(wù)，效果也是一樣的。
重慶分公司
重慶分公司
