1.MySQL讀寫分離

1.1 什么是讀寫分離？

讀寫分離,基本的原理是讓主數(shù)據(jù)庫處理事務(wù)性增、改、刪操作（insert、update、delete），而從數(shù)據(jù)庫處理select查詢操作。數(shù)據(jù)庫復制被用來把事務(wù)性操作導致的變更同步到集群中的從數(shù)據(jù)庫。

1.2 為什么要讀寫分離呢？

因為數(shù)據(jù)庫的“寫”（寫10000條數(shù)據(jù)可能要3分鐘）操作是比較耗時的。
但是數(shù)據(jù)庫的“讀”（讀10000條數(shù)據(jù)可能只要5秒鐘）。
所以讀寫分離，解決的是：數(shù)據(jù)庫的寫入，影響了查詢的效率。

1.3 什么時候要讀寫分離？

數(shù)據(jù)庫不一定要讀寫分離，如果程序使用數(shù)據(jù)庫較多時，而更新少，查詢多的情況下會考慮使用。利用數(shù)據(jù)庫主從同步，再通過讀寫分離可以分擔數(shù)據(jù)庫壓力，提高性能。

1.4 主從復制與讀寫分離

在實際的生產(chǎn)環(huán)境中，對數(shù)據(jù)庫的讀和寫都在同一個數(shù)據(jù)庫服務(wù)器中，是不能滿足實際需求的。無論是在安全性、高可用性還是高并發(fā)等各個方面都是完全不能滿足實際需求的。因此，通過主從復制的方式來同步數(shù)據(jù)，再通過讀寫分離來提升數(shù)據(jù)庫的并發(fā)負載能力。有點類似于rsync，但是不同的是rsync是對磁盤文件做備份，而mysql主從復制是對數(shù)據(jù)庫中的數(shù)據(jù)、語句做備份。

2.MySQL主從復制原理

2.1 MySQL復制類型

————MySQL的主從復制類型是基于二進制日志類型來實現(xiàn)的。

（1）STATEMENT：基于語句的復制。在服務(wù)器上執(zhí)行sql語句，在從服務(wù)器上執(zhí)行同樣的語句，mysql默認采用基于語句的復制，執(zhí)行效率高。但是高并發(fā)情況下，會出現(xiàn)SQL語句執(zhí)行順序紊亂的錯誤。
（2）ROW：基于行的復制。把改變的內(nèi)容復制過去，而不是把命令在從服務(wù)器上執(zhí)行一遍。
（3）MIXED：混合類型的復制。默認采用基于語句的復制，一旦發(fā)現(xiàn)基于語句無法精確復制時，就會采用基于行的復制。

2.2 主從復制工作過程

2.2.1 MySQL架構(gòu)圖

2.2.2 書面化工作過程

（1）Master節(jié)點將數(shù)據(jù)的改變記錄成二進制日志（bin log），當Master上的數(shù)據(jù)發(fā)生改變時，則將其改變寫入二進制日志中。
（2）Slave節(jié)點會在一定時間間隔內(nèi)對Master的二進制日志進行探測，其是否發(fā)生改變，如果發(fā)生改變，則開啟I/O線程請求Master的二進制事件。
（3）同時Master節(jié)點為每個I/O線程啟動一個dump線程，用于向其發(fā)送二進制事件，并保存至Slave節(jié)點本地的中繼日志（Relay log）中，Slave節(jié)點將啟動SQL線程從中繼日志中讀取數(shù)據(jù)記錄在本地重放，即解析成SQL語句逐一執(zhí)行，使得其數(shù)據(jù)內(nèi)容和Master節(jié)點保持一致，最后I/O線程和SQL線程將進入睡眠狀態(tài)，等待下一次被喚醒。

2.3 口語化工作工程

兩個日志、四個線程：
Master節(jié)點：二進制日志、dump線程、ack collector線程
Slave節(jié)點：中繼日志、I/O線程、SQL線程

口語化理解主從復制的工作工程：
（1）客戶端在數(shù)據(jù)庫中更新數(shù)據(jù)，相關(guān)的操作記錄則會根據(jù)二進制日志格式，寫入到二進制日志文件中；
（2）從服務(wù)器檢測到二進制日志發(fā)生改變，就會開啟I/O線程向主節(jié)點請求；
（3）主節(jié)點接收到I/O線程之后，會開啟dump線程，向從服務(wù)器發(fā)送二進制日志事件；
（4）從服務(wù)器接收到主服務(wù)器發(fā)來的二進制日志事件后，會將二進制日志記錄保存到自己的中繼日志中，并發(fā)送確認信息給主服務(wù)器的ack collector線程；
（5）從服務(wù)器開啟SQL線程讀取中繼日志中的二進制記錄，并解析成SQL語句在本地逐一執(zhí)行，從而實現(xiàn)主從服務(wù)器的數(shù)據(jù)同步。

注意：

• 中繼日志通常會位于OS緩存中，所以中繼日志的開銷很小。
• 復制過程有一個很重要的限制，即復制在Slave上是串行化的，也就是說Master上的并行更新操作不能在Slave上并行操作。

2.4 MySQL 讀寫分離原理

讀寫分離就是只在主服務(wù)器上寫，只在從服務(wù)器上讀?；镜脑硎?mark>讓主數(shù)據(jù)庫處理事務(wù)性操作，而從數(shù)據(jù)庫處理select查詢。數(shù)據(jù)庫復制被用來主數(shù)據(jù)庫上事務(wù)性操作導致的變更，同步到集群中的從數(shù)據(jù)庫。

2.5 讀寫分離的兩種實現(xiàn)方式

（1）基于程序代碼內(nèi)部實現(xiàn)

在代碼中根據(jù)select、insert進行路由分類，這類方法也是目前生產(chǎn)環(huán)境應(yīng)用最廣泛的。
優(yōu)點是性能較好，因為在程序代碼中實現(xiàn)，不需要增加額外的設(shè)備為硬件開支；缺點是需要開發(fā)人員來實現(xiàn)，運維人員無從下手。
但是并不是所有的應(yīng)用都適合在程序代碼中實現(xiàn)讀寫分離，像一些大型復雜的Java應(yīng)用，如果在程序代碼中實現(xiàn)讀寫分離對代碼改動就較大。

（2）基于中間代理層實現(xiàn)

代理一般位于客戶端和服務(wù)器之間，代理服務(wù)器接到客戶端請求后通過判斷后轉(zhuǎn)發(fā)到后端數(shù)據(jù)庫，有以下代表性程序。

• MySQL-Proxy。MySQL-Proxy為MySQL開源項目，通過其自帶的lua腳本進行SQL判斷。
• Atlas。是由奇虎360的Web平臺開發(fā)維護的，一個基于MySQL協(xié)議的數(shù)據(jù)中間層項目。它是在mysql-proxy0.8.2版本的基礎(chǔ)上，對其進行了優(yōu)化，增加了一些新的功能特性。360內(nèi)部使用Atlas運行的mysql業(yè)務(wù)，每天承載的讀寫請求數(shù)達幾十億條。支持事物以及存儲過程。
• Amoeba。該程序由Java語言進行開發(fā)，阿里巴巴將其用于生產(chǎn)環(huán)境。但是它不支持事務(wù)和存儲過程。
• Mycat。是一款流行的基于Java語言編寫的數(shù)據(jù)庫中間件，是一個實現(xiàn)了MySql協(xié)議的服務(wù)器，其核心功能是分庫分表。配合數(shù)據(jù)庫的主從模式還可以實現(xiàn)讀寫分離。
  

3.實現(xiàn)MySQL主從復制

3.1 搭建MySQL主從復制步驟

MySQL主從服務(wù)器時間同步
主服務(wù)器設(shè)置

yum install ntp -y

vim /etc/ntp.conf
--末尾添加--
server 127.127.80.0							#設(shè)置本地是時鐘源，注意修改網(wǎng)段
fudge 127.127.80.0 stratum 8				#設(shè)置時間層級為8（限制在15內(nèi)）

service ntpd start

從服務(wù)器設(shè)置

yum install ntp ntpdate -y

service ntpd start
/usr/sbin/ntpdate 192.168.80.10				#進行時間同步

crontab -e
*/30 * * * * /usr/sbin/ntpdate 192.168.80.10

主服務(wù)器的mysql配置

vim /etc/my.cnf
server-id=11
log-bin=mysql-bin						#添加，主服務(wù)器開啟二進制日志
binlog_format=mixed
	
#選配項	
expire_logs_days=7						#設(shè)置二進制日志文件過期時間，默認值為0，表示logs不過期
max_binlog_size=500M					#設(shè)置二進制日志限制大小，如果超出給定值，日志就會發(fā)生滾動，默認值是1GB
skip_slave_start=1						#阻止從庫崩潰后自動啟動復制，崩潰后再自動復制可能會導致數(shù)據(jù)不一致的

#"雙1設(shè)置"，數(shù)據(jù)寫入最安全
innodb_flush_logs_at_trx_commit=1		#redo log（事務(wù)日志）的刷盤策略，每次事務(wù)提交時MySQL都會把事務(wù)日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，并且刷新到磁盤中，該模式為系統(tǒng)默認
sync_binlog=1							#在進行每1次事務(wù)提交（寫入二進制日志）以后，Mysql將執(zhí)行一次fsync的磁盤同步指令，將緩沖區(qū)數(shù)據(jù)刷新到磁盤
---------------------------------------------------------------
#"雙1設(shè)置"適合數(shù)據(jù)安全性要求非常高，而且磁盤IO寫能力足夠支持的業(yè)務(wù)，比如訂單、交易、充值、支付消費系統(tǒng)。"雙1模式"下，當磁盤IO無法滿足業(yè)務(wù)需求時，比如11.11活動的壓力。推薦一下性能較快的設(shè)置，并使用帶蓄電池后備電源，防止系統(tǒng)斷電異常。
innodb_flush_logs_at_trx_commit=2		#每次事務(wù)提交時MySQL都會把日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，但是并不會同時刷新到磁盤上。該模式下，MySQL會每秒執(zhí)行一次刷新磁盤操作
sync_binlog=500							#在進行500次事務(wù)提交以后，Mysql將執(zhí)行一次fsync的磁盤同步指令，將緩沖區(qū)數(shù)據(jù)刷新到磁盤
---------------------------------------------------------------

systemctl restart mysqld

mysql -u root -pabc123
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.80.%' IDENTIFIED BY '123456';			#給從服務(wù)器授權(quán)
FLUSH PRIVILEGES;

show master status;
//如顯示以下
+-------------------+----------+--------------+------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+------------------+
| mysql-bin.000002  |    339   |              |                  |
+-------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

#File列顯示日志名，Position列顯示偏移量

從服務(wù)器的mysql配置

vim /etc/my.cnf
server-id = 22								#修改，注意id與Master的不同，兩個Slave的id也要不同
relay-log=relay-log-bin						#開啟中繼日志，從主服務(wù)器上同步日志文件記錄到本地
relay-log-index=relay-log-bin.index			#定義中繼日志文件的位置和名稱，一般和relay-log在同一目錄

#選配項
innodb_buffer_pool_size=2048M		#用于緩存數(shù)據(jù)和索引的內(nèi)存大小，讓更多數(shù)據(jù)讀寫內(nèi)存中完成，減少磁盤操作，可設(shè)置為服務(wù)器總可用內(nèi)存的70-80%
sync_binlog=0						#MySQL不做任何強制性的磁盤刷新指令，而是依賴操作系統(tǒng)來刷新數(shù)據(jù)到磁盤
innodb_flush_log_at_trx_commit=2	#每次事務(wù)log buffer會寫入log file，但一秒一次刷新到磁盤
log-slave-updates=0					#slave從master 復制的數(shù)據(jù)會寫入二進制日志文件里，從庫做為其他從庫的主庫時設(shè)置為 1
relay_log_recovery=1				#當slave從庫宕機后，假如relay-log損壞了，導致一部分中繼日志沒有處理，則自動放棄所有未執(zhí)行的relay-log， 并且重新從master上獲取日志，這樣就保證了relay-log的完整性。默認情況下該功能是關(guān)閉的，將relay_log_recovery的值設(shè)置為1時， 可在slave從庫上開啟該功能，建議開啟。


systemctl restart mysqld

mysql -u root -pabc123
CHANGE master to master_host='192.168.80.10',master_user='myslave',master_password='123456',master_log_file='mysql-bin.000002',master_log_pos=339;					#配置同步，注意master_log_file和 master_log_pos的值要與Master查詢的一致

start slave;						#啟動同步，如有報錯執(zhí)行reset slave;
show slave status\G					#查看Slave狀態(tài)
//確保 IO 和 SQL 線程都是 Yes，代表同步正常。
Slave_IO_Running: Yes				#負責與主機的io通信
Slave_SQL_Running: Yes				#負責自己的slave mysql進程

3.2 從I/O進程未開啟的原因

一般Slave_IO_Running: No 的可能性:

（1）網(wǎng)絡(luò)不通
（2）my.cnf配置有問題
（3）密碼、file文件名、pos偏移量不對
（4）防火墻沒有關(guān)閉

3.3 雙"1"設(shè)置概述

1是每次事務(wù)提交時，MySQL都會把事務(wù)日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，并且刷新到磁盤中。
2是每次事務(wù)提交時，MySQL都會把事務(wù)日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，但不會同時刷新到磁盤上，而是會每秒執(zhí)行一次刷新磁盤操作。
0是系統(tǒng)自動每秒將緩存區(qū)的數(shù)據(jù)寫入到日志文件中，并同時刷新磁盤操作。

雙’1’設(shè)置就是innodb_flush_log_at_trx_commit和sync_binlog兩個參數(shù)設(shè)置，都設(shè)置為1就是雙 1 設(shè)置。MySQL 默認配置就是雙1配置。

innodb_flush_logs_at_trx_commit=1

詳解： redo log（事務(wù)日志）的刷盤策略，每次事務(wù)提交時,MySQL都會把事務(wù)日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，并且刷新到磁盤中.

sync_binlog=1
詳解： 在進行每次事務(wù)提交（寫入二進制日志）以后，Mysql將執(zhí)行一次fsync的磁盤同步指令，將緩沖區(qū)數(shù)據(jù)刷新到磁盤.

innodb_flush_logs_at_trx_commit=2

詳解： 每次事務(wù)提交時MySQL都會把日志緩存區(qū)的數(shù)據(jù)寫入日志文件中，但是并不會同時刷新到磁盤上。該模式下，MySQL會每秒執(zhí)行一次刷新磁盤操作.

總結(jié)： 1安全性最高，但性能比較低，對硬盤要求很高，雙11能夠保證主服務(wù)器的數(shù)據(jù)安全；
0安全性最差，由系統(tǒng)自動刷盤；
2是折中方案，安全性和性能都適中。

3.4 MySQL主從復制的同步模式

3.4.1 三種同步模式

異步復制（Asynchronous replication）

MySQL默認的復制即是異步的，主庫在執(zhí)行完客戶端提交的事務(wù)后會立即將結(jié)果返回給客戶端，并不關(guān)心從庫是否已經(jīng)接收并處理。這樣就會有一個問題，主如果宕掉了，此時主上已經(jīng)提交的事務(wù)可能并沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數(shù)據(jù)不完整。

全同步復制（Fully synchronous replication）

指當主庫執(zhí)行完一個事務(wù)，所有的從庫都執(zhí)行了該事務(wù)才返回給客戶端。因為需要等待所有從庫執(zhí)行完該事務(wù)才能返回，所以全同步復制的性能必然會收到嚴重的影響。

半同步復制（Semisynchronous replication）

介于異步復制和全同步復制之間，主庫在執(zhí)行完客戶端提交的事務(wù)后不是立刻返回給客戶端，而是等待至少一個從庫接收到并寫到relay log中才返回給客戶端。相對于異步復制，半同步復制提高了數(shù)據(jù)的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復制最好在低延時的網(wǎng)絡(luò)中使用。

注意： 雙’11’設(shè)置用于保證主服務(wù)器的數(shù)據(jù)安全，半同步復制用于保證主從復制之間，從服務(wù)器的數(shù)據(jù)完整。

3.4.2 案例實施：搭建半同步模式

實驗環(huán)境搭建參見：案例實施：搭建MySQL主從復制

主節(jié)點服務(wù)器（CentOS 7-5）

（1）添加半同步模式參數(shù)，并重啟mysql服務(wù)；

vim /etc/my.cnf
###添加半同步模式的參數(shù)
plugin-load=rpl_semi_sync_master=semisync_master.so	   #加載mysql半同步復制的插件
rpl_semi_sync_master_enabled=ON		  #或者設(shè)置為"1"，即開啟半同步復制功能				
rpl-semi-sync-master-timeout=1000     #超時時間為1000ms，即1s

systemctl restart mysqld					

（2）驗證并查看半同步是否在運行；

show status like 'Rpl_semi_sync_master_status';
show variables like 'rpl_semi_sync_master_timeout';

（3）查詢半同步模式狀態(tài)；

show status like '%Rpl_semi%';	

參數(shù)說明：

Rpl_semi_sync_master_clients              		#半同步復制客戶端的個數(shù)
Rpl_semi_sync_master_net_avg_wait_time    		#平均等待時間（默認毫秒）
Rpl_semi_sync_master_net_wait_time        		#總共等待時間
Rpl_semi_sync_master_net_waits            		#等待次數(shù)
Rpl_semi_sync_master_no_times             		#關(guān)閉半同步復制的次數(shù)
Rpl_semi_sync_master_no_tx                		#表示沒有成功接收slave提交的次數(shù)
Rpl_semi_sync_master_status               		#表示當前是異步模式還是半同步模式，on為半同步
Rpl_semi_sync_master_timefunc_failures    		#調(diào)用時間函數(shù)失敗的次數(shù)
Rpl_semi_sync_master_tx_avg_wait_time     		#事物的平均傳輸時間
Rpl_semi_sync_master_tx_wait_time         		#事物的總共傳輸時間
Rpl_semi_sync_master_tx_waits             		#事物等待次數(shù)
Rpl_semi_sync_master_wait_pos_backtraverse		#可以理解為"后來的先到了，而先來的還沒有到的次數(shù)"
Rpl_semi_sync_master_wait_sessions        		#當前有多少個session因為slave的回復而造成等待
Rpl_semi_sync_master_yes_tx               		#成功接受到slave事物回復的次數(shù)

從節(jié)點服務(wù)器（CentOS 7-6）

（1）添加半同步模式參數(shù)，并重啟mysql服務(wù)；

vim /etc/my.cnf
###添加半同步模式的參數(shù)
plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=ON

systemctl restart mysqld

（2）驗證并查看半同步是否在運行；

###注意：此時可能還是OFF狀態(tài)，需要在下一步重啟IO線程后，從庫半同步狀態(tài)才會為ON
show status like 'Rpl_semi_sync_slave_status';

#重啟從數(shù)據(jù)庫上的IO線程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

知識點補充：
（1）在一主多從的架構(gòu)中，如果要開啟半同步復制，并不要求所有的從都是半同步復制。
（2）MySQL 5.7極大的提升了半同步復制的性能。
5.6 版本的半同步復制，dump thread承擔了兩份不同且又十分頻繁的任務(wù)：傳送binlog給slave ，還需要等待slave反饋信息，而且這兩個任務(wù)是串行的，dump thread必須等待slave返回之后才會傳送下一個events事務(wù)。dump thread已然成為整個半同步提高性能的瓶頸。在高并發(fā)業(yè)務(wù)場景下，這樣的機制會影響數(shù)據(jù)庫整體的系統(tǒng)吞吐量(TPS)。
5.7 版本的半同步復制中，獨立出一個ack collector thread ，專門用于接收slave的反饋信息。這樣master上有兩個線程獨立工作，可以同時發(fā)送binlog到slave ，和接收slave的反饋。

3.5 半同步模式 VS 異步模式

面試題： 你們數(shù)據(jù)庫主從復制采用是什么模式？什么情況下半同步模式會轉(zhuǎn)換為異步模式？異步模式又會在什么模式下變?yōu)榘胪侥Ｊ?/mark>？

主從復制在延遲超時時間內(nèi)，主沒有收到從的反饋響應(yīng)，主會暫時關(guān)閉半同步復制，轉(zhuǎn)而使用異步復制模式，也就是會自動降為異步工作。當主dump線程發(fā)送完一個事務(wù)的所有事件之后，如果在延遲超時時間內(nèi)，主又收到了從庫的響應(yīng)， 主就會再次恢復為半同步模式。
注意： 延遲超時時間由rpl_semi_sync_master_timeout參數(shù)控制，默認為10000ms，即10s.

3.6 詳解MySQL主從復制延遲問題

延遲的產(chǎn)生

當主庫的TPS并發(fā)較高時，由于主庫是多線程寫入的，而從庫的SQL線程是單線程的，導致從庫SQL可能會跟不上主庫的處理速度（生產(chǎn)者比消費者快，導致商品堆積）。
延遲產(chǎn)生的可能原因：

（1）master服務(wù)器高并發(fā)，形成大量事務(wù)
（2）網(wǎng)絡(luò)延遲
（3）主從硬件設(shè)備導致，cpu主頻、內(nèi)存io、硬盤io等
（4）是同步復制、而不是異步復制

延遲的解決：

網(wǎng)絡(luò)方面：將從庫分布在相同局域網(wǎng)內(nèi)或網(wǎng)絡(luò)延遲較小的環(huán)境中,避免跨機房實現(xiàn)同步。

硬件方面：從庫配置更好的硬件，提升隨機寫的性能。

配置方面：
從庫配置

從庫優(yōu)化MySQL參數(shù)。比如增大innodb_buffer_pool_size,讓更多操作在MySQL內(nèi)存中完成，減少磁盤操作,或者升級Mysql5.7版本使用并行復制。

從庫使用高性能主機。包括cpu強悍、內(nèi)存加大,使用SSD磁盤。避免使用虛擬云主機，使用物理主機，這樣提升了I/O方面性。

架構(gòu)方面：比如在事務(wù)當中盡量對主庫讀寫，其他非事務(wù)中的讀在從庫。消除一部分延遲帶來的數(shù)據(jù)庫不一致。增加緩存降低一些從庫的負載。

3.7 如何判斷MySQL主從復制是否發(fā)生延遲？

主從延遲判斷的方法，通常有兩種方法:Seconds_Behind_Master和mk-heartbeat

Seconds_Behind_Master的判斷是：通過監(jiān)控show slave status\G命令輸出的Seconds_Behind_Master參數(shù)的值來判斷。

Seconds_Behind_Master:是通過比較sql_thread執(zhí)行的event的timestamp和io_thread復制好的event的timestamp(簡寫為ts)進行比較，而得到的這么一個差值;

• 0―該值為零，是我們極為渴望看到的情況，表示主從復制良好，可以認為lag不存在。
• 正值―表示主從已經(jīng)出現(xiàn)延時，數(shù)字越大表示從庫落后主庫越多。
• 負值一幾乎很少見，我只是聽一些資深的DBA說見過，其實，這是一個BUG值，該參數(shù)是不支持負值的，也就是不應(yīng)該出現(xiàn)。

3.8 如何解決主從復制不一致問題？

方法一：忽略錯誤后，繼續(xù)同步

該方法適用于主從庫數(shù)據(jù)相差不大，或者要求數(shù)據(jù)可以不完全統(tǒng)一的情況，數(shù)據(jù)要求不嚴格的情況.
解決措施：

stop slave;
#表示跳過一步錯誤，后面的數(shù)字可變
set global sql_slave_skip_counter =1;
start slave;
之后再用mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
ok，現(xiàn)在主從同步狀態(tài)正常了。。。

方式二：重新做主從，完全同步

該方法適用于主從庫數(shù)據(jù)相差較大，或者要求數(shù)據(jù)完全統(tǒng)一的情況.
解決步驟如下：
（1）先進入主庫，進行鎖表，防止數(shù)據(jù)寫入

mysql> flush tables with read lock;

注意： 該處是鎖定為只讀狀態(tài)，語句不區(qū)分大小寫
（2）進行數(shù)據(jù)備份

#把數(shù)據(jù)備份到mysql.bak.sql文件
[root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql
這里注意一點：數(shù)據(jù)庫備份一定要定期進行，可以用shell腳本或者python腳本，都比較方便，確保數(shù)據(jù)萬無一失

（3）查看master狀態(tài)

mysql> show master status;
+-------------------+----------+--------------+-------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+----------+--------------+-------------------------------+
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema |
+-------------------+----------+--------------+-------------------------------+
1 row in set (0.00 sec)

（4）把mysql備份文件傳到從庫，進行數(shù)據(jù)恢復

#使用scp命令
[root@server01 mysql]# scp mysql.bak.sql root@192.168.128.101:/tmp/

（5）停止從庫的狀態(tài)

mysql> stop slave;

（6）然后到從庫執(zhí)行mysql命令，導入數(shù)據(jù)備份

mysql> source /tmp/mysql.bak.sql

（7）設(shè)置從庫同步，注意該處的同步點，就是主庫show master status信息里的| File| Position兩項

change master to master_host = '192.168.128.100', master_user = 'rsync', master_port=3306, master_password='', master_log_file = 'mysqld-bin.000001', master_log_pos=3260;

（8）重新開啟從同步

mysql> start slave;

（9）查看同步狀態(tài)

mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

總結(jié)：文章來源地址http://www.zghlxwxcb.cn/news/detail-502293.html

1.鎖定主庫的表，只能讀不能寫
2.主庫做完全備份，并且把備份導給從庫
3.從庫重新進行主從復制

到了這里，關(guān)于【數(shù)據(jù)庫七】MySQL主從復制與讀寫分離的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！