實驗:Mysql實現企業級數據庫互爲主從架構實戰

首先看一下主從從架構的圖:
這裏寫圖片描述
一、單一master和多slave
在實際應用場景中,MySQL複製90%以上都是一個Master複製到一個或者多個
Slave的架構模式,主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因
爲只要Master和Slave的壓力不是太大(尤其是Slave端壓力)的話,異步複製的延
時一般都很少很少。尤其是自從Slave端的複製方式改成兩個線程處理之後,更是減
小了Slave端的延時問題。而帶來的效益是,對於數據實時性要求不是特別高的應用
,只需要通過廉價的pcserver來擴展Slave的數量,將讀壓力分散到多臺Slave的機
器上面,即可通過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸,畢
竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決
了目前很多中小型網站的數據庫壓力瓶頸問題,甚至有些大型網站也在使用類似方案
解決數據庫瓶頸。
這裏寫圖片描述
(1) 不同的slave扮演不同的作用(例如使用不同的索引,或者不同的存儲引擎);
(2) 用一個slave作爲備用master,只進行復制;#主服務器掛了之後,可在從服務器執行
1> 在備機上執行STOP SLAVE 和RESET MASTER
2> 查看show slave status \G;
3> 然後修改應用的連接地址。
(3) 用一個遠程的slave,用於災難恢復;
二、互爲主從Master-Master(Master-Master in Active-Active Mode)
這裏寫圖片描述
Master-Master複製的兩臺服務器,既是master,又是另一臺服務器的slave。這
樣,任何一方所做的變更,都會通過複製應用到另外一方的數據庫中。

互爲主從複製過程
什麼是自增長ID?
對於某些唯一性的字段,可以通過設置自增長ID來實現,自增長ID的數據,代表這個表中存在一條唯一的記錄;而自增長id是肯定不會重複的;
創建表,設置ID爲自增長
create table userInfo (id int PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);
兩邊插入數據看數據增長
insert into userInfo(name) value(‘xiao’),(‘da’),(‘lao’);
互爲主從複製過程
主主複製:
互爲主從:兩個節點各自都要開啓binlog和relay log;
1、數據不一致;
2、自動增長id;
定義一個節點使用奇數id
auto_increment_increment=2 #表示自增長字段每次遞增的量
auto_increment_offset=1 #表示自增長字段從那個數開始
另一個節點使用偶數id
auto_increment_increment=2
auto_increment_offset=2
配置:
1、server_id必須要使用不同值;
2、均啓用binlog和relay log;
3、存在自動增長id的表,爲了使得id不相沖突,需要定義其自動增長方式;
服務啓動後執行如下兩步:
4、都授權有複製權限的用戶賬號;
互爲主從的配置:
在實驗:Mysql實現企業級數據庫主從複製架構實戰基礎上進行配置,
可查看連接:
http://blog.csdn.net/ketchup_/article/details/78999733
master:vim /etc/my.cnf
這裏寫圖片描述
• 重啓服務:systemctl restart mariadb
• 進入mariadb:mysql -uroot -p123456
• 查看狀態:show master status;
這裏寫圖片描述
• 在slave上創建賬戶:
這裏寫圖片描述
• 啓動服務器複製線程
這裏寫圖片描述
• 啓動:start slave;
• 查看狀態:show master status;
這裏寫圖片描述
Slave 操作:
slave:vim /etc/my.cnf
這裏寫圖片描述
• 重啓服務:systemctl restart mariadb
• 查看狀態:show master status;
這裏寫圖片描述

• 啓動從服務器複製線程
讓slave連接master,並開始重做master二進制日誌中的事件。
位置:mysql -uroot -p123456 然後直接輸入命令即可;
CHANGE MASTER TO MASTER_HOST=’172.17.252.233’,
MASTER_USER=’slave’,
MASTER_PASSWORD=’magedu’,
MASTER_LOG_FILE=’mysql-bin.000001’,
MASTER_LOG_POS=278; #查看:MariaDB [mysql]> show binlog events;
這裏寫圖片描述
執行start slave;# 啓動複製線程。
• 查看slave狀態:show slave status\G;
這裏寫圖片描述

測試:
在master裏創建自增長ID:
這裏寫圖片描述
查看錶結構:
這裏寫圖片描述
這裏寫圖片描述
擴展:
異步複製(Asynchronous replication)
MySQL默認的複製即是異步的,主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端
,並不關心從庫是否已經接收並處理,這樣就會有一個問題,主如果crash掉了,此時主上已經
提交的事務可能並沒有傳到從上,如果此時,強行將從提升爲主,可能導致新主上的數據不完整
。 全
同步複製(Fully synchronous replication)
指當主庫執行完一個事務,所有的從庫都執行了該事務才返回給客戶端。因爲需要等待所有從庫
執行完該事務才能返回,所以全同步複製的性能必然會收到嚴重的影響。需要有超時時間。
半同步複製(Semisynchronous replication)
介於異步複製和全同步複製之間,主庫在執行完客戶端提交的事務後不是立刻返回給客戶端,而
是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製,半同步複製
提高了數據的安全性,同時它也造成了一定程度的延遲,這個延遲最少是一個TCP/IP往返的時
間。所以,半同步複製最好在低延時的網絡中使用。
半同步複製:
master:
安裝插件:
MariaDB [BB]> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;
這裏寫圖片描述
查看狀態:SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%’;
這裏寫圖片描述
開啓半同步狀態: SET GLOBAL rpl_semi_sync_master_enabled=ON; 或SET GLOBAL rpl_semi_sync_master_enabled=1;
這裏寫圖片描述
重新啓動slave:stop slave ; start slave;
slave:
• 安裝插件:MariaDB [BB]> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;
這裏寫圖片描述
• 查看狀態:SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%’;
這裏寫圖片描述
• 開啓半同步狀態:
set global rpl_semi_sync_slave_enabled=on;
這裏寫圖片描述
• 查看狀態:SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%’;
這裏寫圖片描述
• 重新啓動slave:stop slave ; start slave;

在倆邊查看:tail -200 /var/log/mariadb/mariadb.log
這裏寫圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章