mysql-proxy實現讀寫分離

文章來自整理:http://blog.jobbole.com/94606/
其中Amoeba for MySQL也是實現讀寫分離

環境描述:
操做系統：CentOS6.5 32位
主服務器Master：192.168.179.146
從服務器Slave：192.168.179.147
調度服務器MySQL-Proxy：192.168.179.142
因爲電腦配置不行，安裝了三臺虛擬機，就卡死了，只能將就一下,因爲是一主
一從，因此，致使讀寫都在master上，有機會，再弄兩臺slave來測試
一.mysql主從複製，參考：http://www.cnblogs.com/lin3615/p/5679828.html

2、mysql-proxy實現讀寫分離
一、安裝mysql-proxy
實現讀寫分離是有lua腳本實現的，如今mysql-proxy裏面已經集成，無需再安裝

下載：http://dev.mysql.com/downloads/mysql-proxy/ 必定要下載對應的版本

tar zxvf mysql-proxy-0.8.5-linux-glibc2.3-x86-32bit.tar.gz
mv mysql-proxy-0.8.5-linux-glibc2.3-x86-32bit /usr/local/mysql-proxy

 

二、配置mysql-proxy，建立主配置文件

cd /usr/local/mysql-proxy
mkdir lua #建立腳本存放目錄
mkdir logs #建立日誌目錄
cp share/doc/mysql-proxy/rw-splitting.lua ./lua #複製讀寫分離配置文件
cp share/doc/mysql-proxy/admin-sql.lua ./lua #複製管理腳本
vi /etc/mysql-proxy.cnf   #建立配置文件
[mysql-proxy]
user=root #運行mysql-proxy用戶
admin-username=lin3615 #主從mysql共有的用戶
admin-password=123456 #用戶的密碼
proxy-address=192.168.179.142:4040 #mysql-proxy運行ip和端口，不加端口，默認4040
proxy-read-only-backend-addresses=192.168.179.147 #指定後端從slave讀取數據
proxy-backend-addresses=192.168.179.146 #指定後端主master寫入數據
proxy-lua-script=/usr/local/mysql-proxy/lua/rw-splitting.lua #指定讀寫分離配置文件位置
admin-lua-script=/usr/local/mysql-proxy/lua/admin-sql.lua #指定管理腳本
log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #日誌位置
log-level=info #定義log日誌級別，由高到低分別有(error|warning|info|message|debug)
daemon=true    #以守護進程方式運行
keepalive=true #mysql-proxy崩潰時，嘗試重啓
#保存退出！
chmod 660 /etc/mysql-porxy.cnf

 

三、修改讀寫分離配置文件

vim /usr/local/mysql-proxy/lua/rw-splitting.lua
if not proxy.global.config.rwsplit then
 proxy.global.config.rwsplit = {
  min_idle_connections = 1, #默認超過4個鏈接數時，纔開始讀寫分離，改成1
  max_idle_connections = 1, #默認8，改成1
  is_debug = false
 }
end

 

四、啓動mysql-proxy

/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/etc/mysql-proxy.cnf
netstat -tupln | grep 4000 #已經啓動

killall -9 mysql-proxy #關閉mysql-proxy使用

 

 

五、測試讀寫分離
(1).在主服務器建立proxy用戶用於mysql-proxy使用，從服務器也會同步這個操做

mysql> grant all on *.* to 'lin3615'@'192.168.179.142' identified by '123456';

(2).使用客戶端鏈接mysql-proxy

mysql -u lin3615 -h 192.168.179.142 -P 4040 -p123456

接下來就按基本的 curd執行便可,因爲只有一臺slave，測試時，每次讀寫都是從master，電腦性能沒法開四臺虛擬機，因此有機會，再測試多臺 slave，看下是否ＯＫ

讀寫分離，延遲是個大問題

在slave服務器上執行 show slave status,
能夠看到不少同步的參數,要注意的參數有：
Master_Log_File:slave中的I/O線程當前正在讀取的master服務器二進制式日誌文件名.
Read_Master_Log_Pos:在當前的 master服務器二進制日誌中，slave中的I/O線程已經讀取的位置
Relay_Log_File:SQL線程當前正在讀取與執行中繼日誌文件的名稱
Relay_Log_Pos:在當前的中繼日誌中，SQL線程已讀取和執行的位置
Relay_Master_Log_File:由SQL線程執行的包含多數近期事件的master二進制日誌文件的名稱
Slave_IO_Running:I/O線程是否被啓動併成功鏈接到master
Slave_SQL_Running:SQL線程是否被啓動
Seconds_Behind_Master:slave服務器SQL線程和從服務器I/O線程之間的差距，單位爲秒計

slave同步延遲狀況出現：
1.Seconds_Behind_Master不爲了，這個值可能會很大
2.Relay_Master_Log_File和Master_Log_File顯示bin-log的編號相差很大，說明bin-log在slave上沒有及時同步，因此近期執行的 bin-log和當前I/O線程所讀的 bin-log相差很大
3.mysql的 slave數據庫目錄下存在大量的 mysql-relay-log日誌，該日誌同步完成以後就會被系統自動刪除，存在大量日誌，說明主從同步延遲很厲害

mysql主從同步延遲原理
mysql主從同步原理
主庫針對讀寫操做，順序寫 binlog，從庫單線程去主庫讀"寫操做的binlog",從庫取到 binlog在本地原樣執行(隨機寫),來保證主從數據邏輯上一致.
mysql的主從複製都是單線程的操做，主庫對全部DDL和DML產生 binlog，binlog是順序寫，因此效率很高，slave的Slave_IO_Running線程到主庫取日誌，效率比較高，下一步問題來了，slave的 slave_sql_running線程將主庫的 DDL和DML操做在 slave實施。DML，DDL的IO操做是隨即的，不能順序的，成本高不少，還有可能slave上的其餘查詢產生 lock，因爲 slave_sql_running也是單線程的，因此 一個 DDL卡住了，需求需求執行一段時間，那麼全部以後的DDL會等待這個 DDL執行完纔會繼續執行，這就致使了延遲.因爲master能夠併發，Slave_sql_running線程卻不能夠，因此主庫執行 DDL需求一段時間，在slave執行相同的DDL時，就產生了延遲.

主從同步延遲產生緣由
當主庫的TPS併發較高時，產生的DDL數量超過Slave一個 sql線程所能承受的範圍，那麼延遲就產生了，固然還有就是可能與 slave的大型 query語句產生了鎖等待
首要緣由：數據庫在業務上讀寫壓力太大，CPU計算負荷大，網卡負荷大，硬盤隨機IO過高
次要緣由：讀寫 binlog帶來的性能影響，網絡傳輸延遲
主從同步延遲解決方案
架構方面
1.業務的持久化層的實現採用分庫架構，mysql服務可平行擴展分散壓力
2.單個庫讀寫分離，一主多從，主寫從讀，分散壓力。
3.服務的基礎架構在業務和mysql之間加放 cache層
4.不一樣業務的mysql放在不一樣的機器
5.使用比主加更了的硬件設備做slave
反正就是mysql壓力變小，延遲天然會變小

硬件方面：
採用好的服務器

mysql主從同步加速
一、sync_binlog在slave端設置爲0
二、–logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日誌。
三、直接禁用slave端的binlog
四、slave端，若是使用的存儲引擎是innodb，innodb_flush_log_at_trx_commit =2

從文件系統自己屬性角度優化
master端
修改linux、Unix文件系統中文件的etime屬性， 因爲每當讀文件時OS都會將讀取操做發生的時間回寫到磁盤上，對於讀操做頻繁的數據庫文件來講這是不必的，只會增長磁盤系統的負擔影響I/O性能。能夠經過設置文件系統的mount屬性，組織操做系統寫atime信息，在linux上的操做爲：
打開/etc/fstab，加上noatime參數
/dev/sdb1 /data reiserfs noatime 1 2
而後從新mount文件系統
#mount -oremount /data

主庫是寫，對數據安全性較高，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置是須要的
而slave則不須要這麼高的數據安全，徹底能夠講sync_binlog設置爲0或者關閉binlog，innodb_flushlog也能夠設置爲0來提升sql的執行效率
一、sync_binlog=1 o
MySQL提供一個sync_binlog參數來控制數據庫的binlog刷到磁盤上去。
默認，sync_binlog=0，表示MySQL不控制binlog的刷新，由文件系統本身控制它的緩存的刷新。這時候的性能是最好的，可是風險也是最大的。一旦系統Crash，在binlog_cache中的全部binlog信息都會被丟失。
若是sync_binlog>0，表示每sync_binlog次事務提交，MySQL調用文件系統的刷新操做將緩存刷下去。最安全的就是sync_binlog=1了，表示每次事務提交，MySQL都會把binlog刷下去，是最安全可是性能損耗最大的設置。這樣的話，在數據庫所在的主機操做系統損壞或者忽然掉電的狀況下，系統纔有可能丟失1個事務的數據。
可是binlog雖然是順序IO，可是設置sync_binlog=1，多個事務同時提交，一樣很大的影響MySQL和IO性能。
雖然能夠經過group commit的補丁緩解，可是刷新的頻率太高對IO的影響也很是大。對於高併發事務的系統來講，
「sync_binlog」設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。
因此不少MySQL DBA設置的sync_binlog並非最安全的1，而是2或者是0。這樣犧牲必定的一致性，能夠得到更高的併發和性能。
默認狀況下，並非每次寫入時都將binlog與硬盤同步。所以若是操做系統或機器(不只僅是MySQL服務器)崩潰，有可能binlog中最後的語句丟失了。要想防止這種狀況，你可使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入後與硬盤同步。即便sync_binlog設置爲1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。

二、innodb_flush_log_at_trx_commit （這個很管用）
抱怨Innodb比MyISAM慢 100倍？那麼你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都須要把日誌寫入（flush）硬盤，這是很費時的。特別是使用電池供電緩存（Battery backed up cache）時。設成2對於不少運用，特別是從MyISAM錶轉過來的是能夠的，它的意思是不寫入硬盤而是寫入系統緩存。
日誌仍然會每秒flush到硬 盤，因此你通常不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即便MySQL掛了也可能會丟失事務的數據。而值2只會在整個操做系統 掛了時纔可能丟數據。

三、ls(1) 命令可用來列出文件的 atime、ctime 和 mtime。
atime 文件的access time 在讀取文件或者執行文件時更改的
ctime 文件的create time 在寫入文件，更改全部者，權限或連接設置時隨inode的內容更改而更改
mtime 文件的modified time 在寫入文件時隨文件內容的更改而更改
ls -lc filename 列出文件的 ctime
ls -lu filename 列出文件的 atime
ls -l filename 列出文件的 mtime
stat filename 列出atime，mtime，ctime
atime不必定在訪問文件以後被修改
由於：使用ext3文件系統的時候，若是在mount的時候使用了noatime參數那麼就不會更新atime信息。
這三個time stamp都放在 inode 中.若是mtime,atime 修改,inode 就必定會改, 既然 inode 改了,那ctime也就跟着改了.
之因此在 mount option 中使用 noatime, 就是不想file system 作太多的修改, 而改善讀取效能

4.進行分庫分表處理，這樣減小數據量的複製同步操做