mysql的应用_mysql应用场景
MySQL復制
MySQL復制支持單向,異步復制。通過一臺主服務器將更新寫入二進制日志文件,并維護文件的一個索引以跟蹤日志循環。這些日志可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時,它通知主服務器從服務器在日志中讀取的最后一次成功更新的位置。從服務器接收從那時起發生的任何更新,然后封鎖并等待主服務器通知新的更新。MySQL主從復制是異步進行的。同步需要版本為5.5,使用google提供的插件來實現。
MySQL主從復制操作很靈活既可以實現整個服務的級別的復制,也可以實現對某個庫,甚至某個數據庫中的指定的某個對象進行復制。
MySQL主從復制應用場景
1.提高性能。通過一(多)主多從的部署方案,將涉及數據寫的操作放在Master端操作,而將數據讀的操作分散到眾多的Slave當中。降低了Master的負載,提高數據寫入的響應效率;多臺從服務器提供讀,分擔了請求,提高了讀的效率。
2.數據安全。數據復制到Slave節點,即使Master宕機,Slave節點還保存著完整數據。
3.數據分析。將數據分析,放在slave上。
主從復制的原理
MySQL的Replication是一個異步的復制過程,從一個MySQL實例(Master)復制到另一臺MySQL實例上。在Master和Slave之間復制的整個過程主要由3個線程完成,其中兩個線程(SQL線程和IO線程)在Slave端,另外一個線程(IO線程)在Master端。
要實現主從復制,首先要在Master端打開Binary Log功能。因為整個復制過程實際上就是Slave從Master上獲取二進制日志,然后在自己身上完全按照產生的順序一次執行日志中記錄的各種操作的過程。
復制的具體過程如下:
1.Slave的IO線程連上Master,并請求日志文件指定位置(或從開始的日志)之后的日志的內容。
2.Master接收到來自Slave的IO線程請求后,負責復制IO線程根據請求的信息讀取指定日志之后的日志信息,返回給Slave端的IO線程。返回信息中除了日志所包含的信息,還包含了包括本次返回的信息在Master端的Binary Log文件的名稱和位置。
3.Slave的IO線程接受到信息后,將日志內容一次寫入Slave端的Relay Log文件(mysql-relay-bin.xxxx)的末端,并將讀取到的Master端的bin-log的文件和位置記錄到master-info文件中,以便在下一次讀取時能夠清楚地告訴Master,下次從bin-log哪個位置開始往后的日志內容。
4.Slave的SQL線程檢測檢測到Relay Log中更新內容后,會馬上解析該Log文件中的內容,還原成在Master端真實執行時的可執行的SQL語句,并執行這些SQK語句。實際上Master和Slave執行同樣的語句。
Binary Log記錄方式
Row Level
Binary Log會記錄成每一行數據被修改的形式,然后在Slave端再對相同的數據進行修改。
優點:在Row Level模式下,Binnary Log可以不記錄執行的Query語句的上下文相關信息,只要記錄哪一行修改了,修改成什么樣子。Row Level會詳細的記錄下每一行數據的修改細節,而且不會出現某個特定情況下的存儲過程,或Function,以及Trigger的調用和觸發無法被正確復制問題。
缺點:產生大量的日志內容。
StatmentLevel
每一條會修改的SQL語句都會記錄到Master的Binnary中。Slave端在復制的時候,SQL線程會解析成和原來Master端執行過相同的SQL語句,并再次執行。
優點:首先,解決了Row Level下的缺點,不須要記錄每一行的數據變化,減少了BinnaryLog日志量,節約了IO成本,提高了性能。
缺點:由于它是記錄的執行語句,為了讓這些語句在Slave端也能正確執行。那么它還必須記錄每條語句在執行時的一些相關信息,即上下文信息,以保證所有語句在Slave端被執行的時候能夠得到和在Master端執行時相同的結果。另外,由于MySQL發展比較快,很多新功能不斷加入,使得MySQL復制遇到了不小的挑戰,復制時設計的內容岳父在,越容易出bug。在StatementLevel下,目前已發現不少的情況下會造成MySQL的復制問題。主要是在修改數據使用了某些特定的函數貨功能后,出現,比如:Sleep()函數在有些版本中就不能正確的復制,在存儲過程中使用了last_insert_id()函數,可能會使Slave和Master的到不一致的ID,等等。
Mixed Level
在Mixed模式下,MySQL會根據執行的每一條具體的SQL語句來區分對待記錄的日志形式,也就是在Statement和Row之間選擇一種。除了MySQL認為通過Statement方式可能造成復制過程中Master和Slave之間產生不一致數據。(如特殊Procedure和Funtion的使用,UUID()函數的使用等特殊情況)時,它會選擇ROW的模式來記錄變更之外,都會使用Statement方式。
設置主從
主從設置的主要步驟是
1.修改Master和Slave的my.cnf中的server-id,使之唯一,開啟binlog。
2.若不停Master時,加入全局鎖,記錄bin-log文件和bin-log文件的位置,全備要同步的數據庫;解除全局鎖
3.若可以停庫時,停止主庫,物理備份所需要同步的數據庫。
4.在Slave端恢復備份的數據。
5.用change master在Slave建立與master的聯系。
6.啟動Slave。
7.檢查Slave的狀態。
實例
1.不停主庫的建立主從復制。
第一部分對主庫的操作1、修改主庫的文件,開啟MySQL的bin-log。(一般安裝的時候最好先做好,這樣可以不停庫。)修改主庫的配置文件my.cnf:1
2
3
4
5
6vim? /etc/my.cnf
server-id =1#設置server-id確保id為唯一,最好用ip地址,后三位bin-log=mysql-bin#設置bin-log,這地方可以指定為bin-log的目錄?/etc/init.d/mysqld restart
修改完成后,重啟mysql2、登錄主庫,添加從庫的同步賬號。1
2mysql –uroot –pgrantreplicationslaveon*.*to'rep'@'%'identifiedby'passwd';3、對主庫進行鎖表操作,禁止更新,(為了防止備份時的數據不一致問題)。并查看bin-log的名字和日志的(position)。1
2
3
4
5
6
7
8
9
10
11
12flush? tables with read lock;show master status;mysql> show ?master status;+------------------+----------+--------------+------------------+| File???? ????????| Position | Binlog_Do_DB | ?Binlog_Ignore_DB |+------------------+----------+--------------+------------------+| ?mysql-bin.000107 | 38874616 |????????????? ?|????????????????? |+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
mysql>
記錄這兩個值mysql-bin.00010738874616取得bin-log和position1mysql -uroot -p'yz11235' -e"show master status"| awk '{if(NR == 2){print$1"\n"$2;}}' > temp.txt4、對主庫進行全備份。1mysqldump? -h hostname -uroot -p’’ ?-A -B -F| gzip >alldb.sql.gz5、導出數據庫后,進行對數據庫表解鎖。1unlocktables
第二部分從庫上操作
1.在從庫上設置my.cnf,設置server-id,和注釋bin-log。1
2server-id =2# bin-log = ?mysql-bin
重啟mysql。2、登錄從庫,并設置從庫信息1
2
3
4
5
6
7
8CHANGEMASTERTOMASTER_HOST='10.143.39.174',
MASTER_PORT=3306,
MASTER_USER='rep',
MASTER_PASSWORD='passwd',
MASTER_LOG_FILE='mysql-bin.000003',
MASTER_LOG_POS=151348020,
MASTER_CONNECT_RETRY=10;3、啟動從庫1startslave4、查看從庫狀態,1showslavestatus\G
觀察:slave_IO_Running : YesSlave_SQL_Running: Yes以上兩個為Yes說明主從已經成功。Second_behind_master= 0這是從庫落后主庫的秒數。
總結
以上是生活随笔為你收集整理的mysql的应用_mysql应用场景的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 写出调试c语言程序的基本操作步骤,C语言
- 下一篇: mysql服务启动失败