為了保障數(shù)據(jù)的安全與穩(wěn)定性，我們常用數(shù)據(jù)庫的主從復(fù)制與主主復(fù)制來實現(xiàn)。主從復(fù)制為從機(jī)實時拷貝一份主機(jī)的數(shù)據(jù)，當(dāng)主機(jī)有數(shù)據(jù)變化時，從機(jī)的數(shù)據(jù)會跟著變，當(dāng)從機(jī)數(shù)據(jù)有變化時，主機(jī)數(shù)據(jù)不變；同樣地，主主復(fù)制就是，多個主機(jī)之間，只要有一個主機(jī)的數(shù)據(jù)變化了，其它主機(jī)數(shù)據(jù)也會跟著變化。
公司主營業(yè)務(wù)：成都網(wǎng)站設(shè)計、網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊有機(jī)會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出甕安免費做網(wǎng)站回饋大家。
添加以下內(nèi)容
如果你是使用我之前那種方式啟動的MySQL，那么你只需要去你相關(guān)聯(lián)的宿主機(jī)的配置文件夾里面去建立一個 my.cnf 然后寫入上面的類容就好了。
比如：我的啟動命令如下（不應(yīng)該換行的，這里為了方便查看，我給它分行了）
那么我只需要在 /docker/mysql_master/conf 這個目錄下創(chuàng)建 my.cnf 文件就好了。
這個命令是需要在容器里面執(zhí)行的
docker重啟mysql會關(guān)閉容器，我們需要重啟容器。
確保在主服務(wù)器上 skip_networking 選項處于 OFF 關(guān)閉狀態(tài), 這是默認(rèn)值。 如果是啟用的，則從站無法與主站通信，并且復(fù)制失敗。
我的命令如下
在從服務(wù)器配置連接到主服務(wù)器的相關(guān)信息 （在容器里面的mysql執(zhí)行）
上面代碼的xxxxx你需要換成你的IP，docker 查看容器 IP 的命令如下：
啟動的那個從服務(wù)器的線程
測試的話，你可以在主服務(wù)器里面，創(chuàng)建一個數(shù)據(jù)庫，發(fā)現(xiàn)從服務(wù)器里面也有了，就成功了。
如果你還想要一個從服務(wù)器，那么你只需要按照上面配置從服務(wù)器再配置一個就行了，新建的從服務(wù)器，會自動保存主服務(wù)器之前的數(shù)據(jù)。（測試結(jié)果） 如果你上面的主從復(fù)制搞定了，那么這個主主復(fù)制就很簡單了。我們把上面的從服務(wù)器也改成主服務(wù)器
1）、修改上面的從服務(wù)器的my.cnf文件，和主服務(wù)器的一樣（注意這個server-id不能一樣）然后重啟服務(wù)器 2）、在從服務(wù)器里面創(chuàng)建一個復(fù)制用戶創(chuàng)建命令一樣（這里修改一下用戶名可以改為 repl2） 3）、在之前的主服務(wù)器里面運行下面這個代碼
上面主要是教你怎么搭建一個MySQL集群，但是這里面還有很多其它的問題。也是我在學(xué)習(xí)過程中思考的問題，可能有的小伙伴上來看到文章長篇大論的看不下去，只想去實現(xiàn)這樣一直集群功能，所以我就把問題寫在下面了。
1）、MySQL的replication和pxc MySQL的集群方案有replication和pxc兩種，上面是基于replication實現(xiàn)的。
replication: 異步復(fù)制，速度快，無法保證數(shù)據(jù)的一致性。 pxc: 同步復(fù)制，速度慢，多個集群之間是事務(wù)提交的數(shù)據(jù)一致性強。
2）、MySQL的replication數(shù)據(jù)同步的原理 我們在配置的時候開啟了它的二進(jìn)制日志，每次操作數(shù)據(jù)庫的時候都會更新到這個日志里面去。主從通過同步這個日志來保證數(shù)據(jù)的一致性。
3）、可否不同步全部的數(shù)據(jù) 可以配置，同步哪些數(shù)據(jù)庫，甚至是哪些表。
4）、怎么關(guān)閉和開始同步
5）、我就我的理解畫出了，主從、主從從、主主、復(fù)制的圖。
往期推薦：
利用Docker僅花1分鐘時間安裝好MySQL服務(wù)
Linux下MySQL 5.7的離線與在線安裝（圖文）
Linux下安裝MySQL8.0（收藏?。?/p>
1、首先，我們需要修改mysql的配置文件，一般文件存放在/etc下面，文件名為my.cnf。
2、對于mysql服務(wù)的啟動，我們通常使用命令service mysqld start，沒問題的話就能啟動mysql服務(wù)了。
3、如何判斷mysql服務(wù)有沒有啟動成功了，一個是通過查看進(jìn)程的方式，我們使用命令ps -ef|grep mysqld，來查看。
4、當(dāng)然，更為穩(wěn)妥的方法是使用命令mysql -uuser -p passwd 來進(jìn)行連接，看看是否能接上。
5、如何停止mysql的服務(wù)呢。方法也很簡單，使用命令：service mysqld stop命令即可。
6、一般，如果mysql服務(wù)沒有啟動成功，可以通過查看錯誤日志的方式，日志默認(rèn)路徑/var/log/mysqld.log，
7、完成效果圖。
系統(tǒng)優(yōu)化：假如現(xiàn)在用戶反映系統(tǒng)太卡
1：如果是請求太多，判斷web服務(wù)器壓力過大，增加前端的web服務(wù)器，做負(fù)載均衡
2：如果請求靜態(tài)頁面不卡了，但是請求動態(tài)數(shù)據(jù)還是卡，說明MySQL處理的請求太多了，在應(yīng)用層增加緩存
3：如果請求激增，還是有大量的查詢到MySQL,想辦法處理MySQL ,在一個應(yīng)用中，大量的消耗MySQL的還是查詢，就可以把MySQL拆開，就像公路分道 公交車道，小轎車道，把MySQL做成主從
1,就算MYSQL拆成了多個,也必須分出主和從,所有的寫操作都必須要在主MYSQL 上完成;
2,所有的從MYSQL的數(shù)據(jù)都來自于(同步于)主MYSQL;
3,既然涉及到同步,那一定有延遲;有延遲,就一定可能在讀的時候產(chǎn)生臟數(shù)據(jù);所以,能夠在從MYSQL上進(jìn)行的讀操作,一定對實時性和臟數(shù)據(jù)有一定容忍度的數(shù)據(jù);比如,登陸日志,后臺報表,首頁統(tǒng)計信息來源;文章;資訊;SNS消息;
4,[注意]:在MYSQL主從時,如果一個業(yè)務(wù)(service中的一個方法)中,如果既有R操作,又有W操作,因為W操作一定要在主MYSQL上,所以在一個事務(wù)中所有的數(shù)據(jù)來源都只能來自于一個MYSQL
1,要完成主從同步,就必須讓在Master上執(zhí)行的所有的DML和DDL能夠正確的在Salve上再執(zhí)行一遍;MYSQL選擇使用文件來記錄SQL;
2,要完成主從同步,第一個事情就是把在主服務(wù)器上的bin-log(二進(jìn)制文件)打開,bin-log文件就可以記錄在MYSQL上執(zhí)行的所有的DML+DDL+TCL;
3,MYSQL使用被動注冊的方式來讓從MYSQL請求同步主MYSQL的binlog;原因:被動請求的方式,主的MYSQL不需要知道有哪些從的MYSQL,我額外添加/去掉從MYSQL服務(wù)器,對主MYSQL服務(wù)器的正常運行沒有任何影響;
4,第二步,從MYSQL后臺一個線程發(fā)送一個請求,到主服務(wù)器請求更新數(shù)據(jù);最重要的數(shù)據(jù)(我這次請求,請求你bin-log的哪一行數(shù)據(jù)之后的數(shù)據(jù))
5,第三步,主MYSQL后臺一個線程接收到從MYSQL發(fā)送的請求,然后讀取bin-log文件中指定的內(nèi)容,并放在從MYSQL的請求響應(yīng)中;
6,第四步,從MYSQL的請求帶回同步的數(shù)據(jù),然后寫在從MYSQL中的relay-log(重做日志)中;relay-log中記錄的就是從主MYSQL中請求回來的哪些SQL數(shù)據(jù);
7,第五步,從MYSQL后臺一個線程專門用于從relay-log中讀取同步回來的SQL,并寫入到從MYSQL中,完成同步;
8,MYSQL的主從同步是經(jīng)過高度優(yōu)化的,性能非常高;
在[mysqld]配置段添加如下字段
使用master狀態(tài)
show master status; 記錄file和position的值
在[mysqld]配置段添加如下字段,
連接slave，在mysql命令行執(zhí)行以下命令，設(shè)置參數(shù)，啟動slave
MASTER_LOG_FILE 對應(yīng)master的status的file
MASTER_LOG_POS 對應(yīng)master的status的position
主要查看Slave_IO_Running和Slave_SQL_Running 兩列是否都為YES
第一種：在master上刪除一條記錄，而slave上找不到。
Last_SQL_Error: Could not execute Delete_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;
the event's master log mysql-bin.000006, end_log_pos 254
第二種：主鍵重復(fù)。在slave已經(jīng)有該記錄，又在master上插入了同一條記錄。
Last_SQL_Error: Could not execute Write_rows event on table hcy.t1;
Duplicate entry '2' for key 'PRIMARY',
Error_code: 1062;
handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000006, end_log_pos 924
第三種：在master上更新一條記錄，而slave上找不到，丟失了數(shù)據(jù)。
Last_SQL_Error: Could not execute Update_rows event on table hcy.t1;
Can't find record in 't1',
Error_code: 1032;
handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000010, end_log_pos 263
異步半同步區(qū)別
MySQL 主從一直是面試?？?，里面的知識點雖然基礎(chǔ)，但是能回答全的同學(xué)不多。
比如樓哥之前面試小米，就被問到過主從復(fù)制的原理，以及主從延遲的解決方案，因為回答的非常不錯，給面試官留下非常好的印象。你之前面試，有遇到過哪些 MySQL 主從的問題呢？
所謂 MySQL 主從，就是建立兩個完全一樣的數(shù)據(jù)庫，一個是主庫，一個是從庫， 主庫對外提供讀寫的操作，從庫對外提供讀的操作 ，下面是一主一從模式：
對于數(shù)據(jù)庫單機(jī)部署，在 4 核 8G 的機(jī)器上運行 MySQL 5.7 時，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動時，查詢流量驟然，就需要進(jìn)行主從分離。
大部分系統(tǒng)的訪問模型是讀多寫少，讀寫請求量的差距可能達(dá)到幾個數(shù)量級，所以我們可以通過一主多從的方式， 主庫只負(fù)責(zé)寫入和部分核心邏輯的查詢，多個從庫只負(fù)責(zé)查詢，提升查詢性能，降低主庫壓力。
MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫宕機(jī)時，從庫可以切成主庫，保證服務(wù)的高可用，然后主庫也可以做數(shù)據(jù)的容災(zāi)備份。
整體場景總結(jié)如下：
MySQL 的主從復(fù)制是依賴于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。
主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫傳輸?shù)綇膸焐?，一般這個過程是異步的，即主庫上的操作不會等待 binlog 同步的完成。
詳細(xì)流程如下：
當(dāng)主庫和從庫數(shù)據(jù)同步時，突然中斷怎么辦？因為主庫與從庫之間維持了一個長鏈接，主庫內(nèi)部有一個線程，專門服務(wù)于從庫的這個長鏈接的。
對于下面的情況，假如主庫執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：
我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來的數(shù)據(jù)一般是不一樣的。
所以就會存在這種情況：在 binlog = statement 格式時，主庫在執(zhí)行這條 SQL 時，使用的是索引 a，而從庫在執(zhí)行這條 SQL 時，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。
那么我們改如何解決呢？
可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個 event:Table_map 和 Delete_rows。
Table_map event 說明要操作的表，Delete_rows event用于定義要刪除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要刪除的主鍵 ID 信息，因此不會出現(xiàn)主從不一致的問題。
但是如果 SQL 刪除 10 萬行數(shù)據(jù)，使用 row 格式就會很占空間的，10 萬條數(shù)據(jù)都在 binlog 里面，寫 binlog 的時候也很耗 IO。但是 statement 格式的 binlog 可能會導(dǎo)致數(shù)據(jù)不一致。
設(shè)計 MySQL 的大叔想了一個折中的方案，mixed 格式的 binlog，其實就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時，就用 row 格式，否則使用就用 statement 格式。
有時候我們遇到從數(shù)據(jù)庫中獲取不到信息的詭異問題時，會糾結(jié)于代碼中是否有一些邏輯會把之前寫入的內(nèi)容刪除，但是你又會發(fā)現(xiàn)，過了一段時間再去查詢時又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。
主從延遲，其實就是“從庫回放” 完成的時間，與 “主庫寫 binlog” 完成時間的差值， 會導(dǎo)致從庫查詢的數(shù)據(jù)，和主庫的不一致 。
談到 MySQL 數(shù)據(jù)庫主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說起：
總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過從庫一個 SQL 線程所能承受的范圍，那么延時就產(chǎn)生了，當(dāng)然還有就是可能與從庫的大型 query 語句產(chǎn)生了鎖等待。
我們一般會把從庫落后的時間作為一個重點的數(shù)據(jù)庫指標(biāo)做監(jiān)控和報警，正常的時間是在毫秒級別，一旦落后的時間達(dá)到了秒級別就需要告警了。
解決該問題的方法，除了縮短主從延遲的時間，還有一些其它的方法，基本原理都是盡量不查詢從庫。
具體解決方案如下：
在實際應(yīng)用場景中，對于一些非常核心的場景，比如庫存，支付訂單等，需要直接查詢從庫，其它非核心場景，就不要去查主庫了。
兩臺機(jī)器 A 和 B，A 為主庫，負(fù)責(zé)讀寫，B 為從庫，負(fù)責(zé)讀數(shù)據(jù)。
如果 A 庫發(fā)生故障，B 庫成為主庫負(fù)責(zé)讀寫，修復(fù)故障后，A 成為從庫，主庫 B 同步數(shù)據(jù)到從庫 A。
一臺主庫多臺從庫，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。
重慶分公司
重慶分公司
