項目實戰7—Mysql實現企業級數據庫主從複製架構實戰
環境背景：公司規模已經造成，用戶數據已成爲公司的核心命脈，一次老王一不當心把數據庫文件刪除，經過mysqldump備份策略恢復用了兩個小時，在這兩小時中，公司業務中斷，損失100萬，老王作出深入檢討，公司也所以對於數據庫的性能和可靠性提出更高要求。mysql
要求對數據庫進行改造，使其承載力進行提高，故障修復時間減小，有沒有能實現的方案呢？linux
Mysql實現數據庫主從複製實戰架構及其原理
一、實驗架構及其原理
二、過程分析
② mysql的進程讀事務日誌，事務日誌的內容作到數據庫內存中；此時能夠回覆客戶端，數據爲髒數據服務器
⑤ I/O thread線程：從主的數據庫上，把二進制文件的內容拉過來，寫到relay log中繼日誌中
⑥ SQL thread線程：把relay log內容拉出來，寫到數據庫內存中
⑦ 從數據庫也能夠把執行的操做記錄到本身的二進制文件中，非必須
三、主從的優點
一個master 寫入，多個slave同時讀出；大大提升了讀的效率
現實中，不少都是讀的請求大，寫的請求相對小的多，如電商網站，大多都是人們去訪問，下單的較少；因此主從的關係已經能很好的提升性能了
四、實驗前準備
① iptables -F && setenforce 清空防火牆策略，關閉selinux
② 拿兩臺服務器都使用yum 方式安裝Mysql 服務，要求版本一致
實戰一：Mysql實現數據庫簡單一主多從複製實戰
一、環境準備
centos 系統服務器3 臺、一臺用戶作Mysql 主服務器，2臺用於作Mysql 從服務器，配置好yum 源、 防火牆關閉、各節點時鐘服務同步、各節點之間能夠經過主機名互相通訊
| 機器名稱 |
IP配置 |
服務角色 |
備註 |
| master-mysql |
192.168.30.107 |
主數據庫 |
二進制日誌 |
| slave-mysql1 |
192.168.30.7 |
從數據庫 |
中繼日誌 |
| slave-mysql2 |
192.168.30.2 |
從數據庫 |
中繼日誌 |
二、在主master 主服務器上
① vim /etc/my.cnf 修改mysql主配置文件，對master進行配置，包括打開二進制日誌，指定惟一的servr ID
server-id=1 #配置server-id，讓主服務器有惟一ID號 log-bin=mysql-bin #打開Mysql日誌，日誌格式爲二進制 skip-name-resolve #關閉名稱解析，（非必須）
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'192.168.%.%' IDENTIFIED BY 'along'; 分析：在Master的數據庫中創建一個備份賬戶：每一個slave使用標準的MySQL用戶名和密碼鏈接master。進行復制操做的用戶會授予REPLICATION SLAVE權限。
在Master的數據庫執行show master status，查看主服務器二進制日誌狀態，位置號
三、在從slave mysql1上
vim /etc/my.cnf 打開中繼日誌，指定惟一的servr ID，設置只讀權限
server-id=2 #配置server-id，讓從服務器有惟一ID號 relay_log = mysql-relay-bin #打開Mysql日誌，日誌格式爲二進制 read_only = 1 #設置只讀權限 log_bin = mysql-bin #開啓從服務器二進制日誌，（非必須） log_slave_updates = 1 #使得更新的數據寫進二進制日誌中
② 啓動從服務器複製線程，讓slave鏈接master，並開始重作master二進制日誌中的事件。
MariaDB [(none)]> change master to master_host='192.168.30.107', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000001', -> master_log_pos=245; MariaDB [(none)]> start slave; # 啓動複製線程，就是打開I/O線程和SQL線程；實現拉主的bin-log到從的relay-log上；再從relay-log寫到數據庫內存裏
可以使用SHOW SLAVE STATUS\G查看從服務器狀態，以下所示，也可用show processlist \G查看當前複製狀態：
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
四、測試
五、若要繼續添加新salve，實現一主多從
假如master 已經運行好久了，想對新安裝的slave 進行數據同步，甚至它沒有master 的數據。
① 進行徹底備份 mysqldump --all-databases > /backup/mysql-all-backup-`date +%F-%T`.sql 把備份生成的文件發給salve-mysql2機器上 scp /backup/mysql-all-backup-2017-11-20-22\:04\:06.sql @192.168.30.2: ② 查看如今的二進制文件狀態 MariaDB [(none)]> show master status;
mysql -uroot -p < mysql-all-backup-2017-11-20-22\:04\:06.sql
MariaDB [(none)]> change master to master_host='192.168.30.107', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000003', -> master_log_pos=500;
六、測試三臺機器的一主多從關係
七、解除主從關係，恢復獨立的服務器
① MariaDB [(none)]> stop slave; 關閉兩個線程
relay-log =mysql-relay-log read-only = 1 log_slave_updates = 1
③ systemctl restart mariadb 重啓服務
實戰二：實現主從從架構及複製過濾器
架構原理：一個主master，一個從slave1；從slave1再作主，另外一個slave2以他爲主作從；大致作法與上實驗類似
複製過濾原理：複製過濾器：（黑、白名單）僅複製有限一個或幾個數據庫相關的數據，而非全部；由複製過濾器進行；
(1) 主服務器 主服務器僅向二進制日誌中記錄有關特定數據庫相關的寫操做； binlog_do_db= #僅容許從複製這個庫的二進制日誌 binlog_ignore_db= #除了這個庫，其餘都容許複製 (2) 從服務器 從服務器的SQL THREAD僅重放關注的數據庫或表相關的事件，並將其應用於本地； Replicate_Do_DB= #只複製主的這個數據庫數據 Replicate_Ignore_DB= #除了這個都複製
一、環境準備
| 機器名稱 |
IP配置 |
服務角色 |
備註 |
| master-mysql |
192.168.30.107 |
主數據庫 |
二進制日誌 |
| slave-mysql1 |
192.168.30.7 |
從數據庫 |
中繼日誌 |
| slave-mysql2 |
192.168.30.2 |
從數據庫 |
中繼日誌 |
二、在主master 主服務器上
① vim /etc/my.cnf 修改mysql主配置文件，對master進行配置，打開二進制日誌，指定惟一的servr ID，設置複製過濾 server-id=1 #配置server-id，讓主服務器有惟一ID號 log-bin=mysql-bin #打開Mysql日誌，日誌格式爲二進制 skip-name-resolve #關閉名稱解析，（非必須） binlog_ignore_db=home #除了home數據庫，其餘都容許從複製主的二進制文件 #binlog_do_db=along #僅容許從複製along數據庫的二進制文件
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'192.168.%.%' IDENTIFIED BY 'along'; 分析：在Master的數據庫中創建一個備份賬戶：每一個slave使用標準的MySQL用戶名和密碼鏈接master。進行復制操做的用戶會授予REPLICATION SLAVE權限。
在Master的數據庫執行show master status，查看主服務器二進制日誌狀態，位置號
三、在從slave mysql1上
vim /etc/my.cnf 打開中繼日誌，指定惟一的servr ID，設置只讀權限
server-id=2 #配置server-id，讓從服務器有惟一ID號 relay_log = mysql-relay-bin #打開Mysql日誌，日誌格式爲二進制 read_only = 1 #設置只讀權限 log_bin = mysql-bin #開啓從服務器二進制日誌，（必須） log_slave_updates = 1 #使得更新的數據寫進二進制日誌中
② 啓動從服務器複製線程，讓slave鏈接master，並開始重作master二進制日誌中的事件。
MariaDB [(none)]> change master to master_host='192.168.30.107', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000001', -> master_log_pos=245; MariaDB [(none)]> start slave; # 啓動複製線程，就是打開I/O線程和SQL線程；實現拉主的bin-log到從的relay-log上；再從relay-log寫到數據庫內存裏
可以使用SHOW SLAVE STATUS\G查看從服務器狀態，以下所示，也可用show processlist \G查看當前複製狀態：
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
四、測試主從和複製過濾
在主上建立一個along、home庫；從上自動生成along、home數據庫
① 在主上：在along庫中建立一個classes的表；從上自動生成
MariaDB [home]> create table classes (id int not null,name varchar(20));
② 在主上：在home庫中建立一個classes的表；從上沒有生成
MariaDB [home]> create table classes (id int not null,name varchar(20));
五、設置slave-mysql2 爲slave-mysql1 的從，且在mysql2 設置複製過濾
由於上邊主配置文件已經開啓了本身的二進制文件；且slave-mysql1 是從開始就同步master的，因此受權命令也同步過了
MariaDB [home]> select user,host from mysql.user; 能夠查看本身受權過的用戶
（2）slave-mysql2 上，能夠像上實驗同樣，先給主的徹底備份在本機恢復一下
① 在主上完備 mysqldump --all-databases > /backup/mysql-all-backup-`date +%F-%T`.sql scp /backup/mysql-all-backup-2017-11-21-11:14:59.sql @192.168.30.2: ② 進行master的徹底備份恢復 mysql -uroot -p < mysql-all-backup-2017-11-20-22\:04\:06.sql ③ 在slave-mysql2 上 vim /etc/my.cnf 修改主配置文件，設爲從；且設置過濾 server-id =3 relay-log =mysql-relay-log read-only = 1 log-bin = mysql-bin log_slave_updates = 1 replicate_do_dB=along #只複製它的主的along數據庫
啓動從服務器複製線程，讓slave鏈接master，並開始重作master二進制日誌中的事件。
MariaDB [(none)]> change master to master_host='192.168.30.7', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000008', -> master_log_pos=773; MariaDB [(none)]> start slave;
⑤ MariaDB [(none)]> show slave status \G; 查看，兩個進程打開，且只複製主的along數據庫
六、測試主從從和slave-mysql2的複製過濾
（1）在主上刪除job數據庫，master 和slave-mysql1 都刪除成功
MariaDB [home]> drop database job; 刪除job庫
由於slave-mysql2 只同步slave-mysql1 的along庫，因此沒有刪除
（2）在主上的along數據庫，建立一個grade 表，master 和slave-mysql1 都刪除成功
MariaDB [along]> create table grade (id int not null,name varchar(20));
實戰三：mysql數據庫雙主的實現
爲了解決雙主同時對一個數據庫進行寫入，採用自增加ID來解決，兩個mysql寫入用奇偶ID岔開
① 建立表，設置ID爲自增加 create table userInfo (id int PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL); ② 定義一個節點使用奇數id：從1開始，步長爲2， auto_increment_increment=2 #表示自增加字段每次遞增的量，步長 auto_increment_offset=1 #表示自增加字段從那個數開始 ③ 另外一個節點使用偶數id：從2開始，步長爲2， auto_increment_increment=2 auto_increment_offset=2
一、環境準備
| 機器名稱 |
IP配置 |
服務角色 |
備註 |
| mysql1 |
192.168.30.107 |
數據庫 |
中繼日誌、二進制日誌 |
| mysql2 |
192.168.30.7 |
數據庫 |
中繼日誌、二進制日誌 |
二、配置總配置文件，除了ID號和起始數，兩邊都是同樣的
server-id =1 #mysql1的配置ID爲1，mysql2的ID爲2 relay-log =mysql-relay-log log-bin = mysql-bin log_slave_updates = 1 auto_increment_increment=2 #表示自增加字段每次遞增的量，步長 auto_increment_offset=1 #表示自增加字段從那個數開始，mysql1從1開始；mysql2從2開始
三、互相設爲對方的從
（1）受權遠程登陸的用戶 mysql一、2 上 GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'192.168.%.%' IDENTIFIED BY 'along'; （2）開啓複製線程 ① mysql1 上 MariaDB [(none)]> change master to master_host='192.168.30.7', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000002', -> master_log_pos=245; MariaDB [(none)]> start slave; # 啓動複製線程 ② mysql2 上 MariaDB [(none)]> change master to master_host='192.168.30.107', -> master_user='slave', -> master_password='along', -> master_log_file='mysql-bin.000002', -> master_log_pos=245; MariaDB [(none)]> start slave; # 啓動複製線程
四、測試雙方互爲主從的關係
在mysql1上，刪除test數據庫；mysql2 上也自動刪除
在mysql2上，建立xiaohei數據庫；mysql2 上也自動生成
五、設置自增加ID的表
MariaDB [along]> create table home (id int PRIMARY KEY AUTO_INCREMENT,name varchar(20));
MariaDB [along]> insert into home(name) value('mayun'),('mahuateng'),('wangjianlin');
MariaDB [along]> insert into home(name) value('dinglei'),('liyanhong'),('leijun');
實驗四：實現半同步複製的一主多從
原理：介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是馬上返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了必定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。因此，半同步複製最好在低延時的網絡中使用。
注意：原本是應該最少2個從mysql，纔能有真正的效果，可是原理都是同樣的，我就只用了一主一從
一、環境準備
| 機器名稱 |
IP配置 |
服務角色 |
備註 |
| master-mysql |
192.168.30.107 |
主數據庫 |
二進制日誌 |
| slave-mysql |
192.168.30.7 |
從數據庫 |
中繼日誌 |
二、按照實戰一，實現主從
三、加載模塊，實現半同步
MariaDB [(none)]> install plugin rpl_semi_sync_master soname 'semisync_master.so'; 加載模塊 MariaDB [(none)]> show global variables like 'rpl_semi%'; 查看是否開啓 MariaDB [(none)]> set global rpl_semi_sync_master_enabled = on; 開啓
MariaDB [(none)]> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'rpl_semi%';
MariaDB [(none)]> set global rpl_semi_sync_slave_enabled = on; 爲了主從同步，再重啓啓動下slave 兩個進程 MariaDB [(none)]> stop slave; MariaDB [(none)]> start slave;
四、查詢日誌，驗證
③ 啓動半同步的binlog 轉儲到slave (id:2)上
實驗五：實現MHA 高可用mysql數據庫架構
原理：總之就是當主master mysql宕機時，從slave mysql頂上去的一系列操做
① 從宕機崩潰的master 保存二進制日誌事件（binlog events ）;
③ 應用差別的中繼日誌(relay log) 到其餘slave;
④ 應用從master 保存的二進制日誌事件(binlog events);
一、環境準備
| 機器名稱 |
IP配置 |
服務角色 |
備註 |
| master-mysql |
192.168.30.107 |
主數據庫 |
二進制日誌、中繼日誌 |
| slave-mysql1 |
192.168.30.7 |
從數據庫 |
二進制日誌、中繼日誌 |
| slave-mysql2 |
192.168.30.2 |
從數據庫 |
二進制日誌、中繼日誌 |
| MHA manager |
192.168.30.3 |
MHA的管理節點 |
|
二、實現三臺服務器的一主多從
① 每一個節點都需開啓二進制和中繼日誌，由於主會宕機，當主的機器修復完畢，能夠做爲從繼續使用，因此中繼日誌是必須的；從也會在主宕機的時候，頂爲主，因此二進制日誌也是必須的
② 各從節點必須顯示啓用其read-only 屬性，並關閉relay_log_purge 清理中繼日誌的功能
（1）vim /etc/my.cnf 修改配置文件 ① 主的配置文件 server-id=1 log-bin=mysql-bin relay-log=mysql-relay-log skip-name-resolve ② 從的配置文件，各個從的配置文件除了ID，其餘都相同 server-id =2[/3] #各自對應本身的id relay-log =mysql-relay-log log-bin = mysql-bin read_only = on relay_log_purge = 0 skip_name_resolve systemctl start mariadb 啓動服務 （2）在主上：受權 MariaDB [(none)]> grant replication slave,replication client on *.* to slave@'192.168.30.%' identified by 'along'; （3）在從上：開啓I/O，SQL線程，實現主從 MariaDB [(none)]> change master to master_host='192.168.30.107', master_user='slave', master_password='along', master_log_file='mysql-bin.000001', master_log_pos=245; MariaDB [(none)]> start slave ;
三、配置MHA的準備
需安裝2個包 rz，我已經放到我網盤裏，須要的私聊http://pan.baidu.com/s/1kV8BCJt
mha4mysql-manager-0.56-0.el6.noarch.rpm
mha4mysql-node-0.56-0.el6.noarch.rpm
yum -y localinstall mha4mysql-*
分析：MHA 集羣中的各節點彼此之間均須要基於ssh 互信通訊，以實現遠程控制及數據管理功能。
ssh-keygen -t rsa 生成公私祕鑰對，能夠直接敲3個回車，不須加密 ssh-copy-id -i .ssh/id_rsa.pub root@192.168.30.7: ssh-copy-id -i .ssh/id_rsa.pub root@192.168.30.2: ssh-copy-id -i .ssh/id_rsa.pub root@192.168.30.3: 把公鑰發給其餘3個機器 注意：每一個mysql服務器都須要發送本身的公鑰
MariaDB [(none)]> grant all on *.* to 'mhaadm'@'192.168.30.%' identified by 'along';
注意：MHA manager 須要作不少事，因此給很大的權限；且已經實現主從，因此只需在master上執行受權命令
mkdir /etc/mha_master 建立配置文件存放目錄
vim /etc/mha_master/app.cnf 設置配置文件，注意註釋不要加在配置文件中，不然檢測不過
[server default] // 適用於server1,2,3 個server 的配置 user=mhaadm //mha 管理用戶 password=along //mha 管理密碼 manager_workdir=/etc/mha_master/app //mha_master 本身的工做路徑 manager_log=/etc/mha_master/manager.log // mha_master 本身的日誌文件 remote_workdir=/mydata/mha_master/app // 每一個遠程主機的工做目錄在何處 ssh_user=root // 基於ssh 的密鑰認證 repl_user=slave // 數據庫用戶名 repl_password=along // 數據庫密碼 ping_interval=1 // ping 間隔時長 [server1] // 節點1 hostname=192.168.30.107 // 節點1 主機地址 ssh_port=22 // 節點1 的ssh 端口 candidate_master=1 // 未來可不能夠成爲master 候選節點/ 主節點 [server2] hostname=192.168.30.7 ssh_port=22 candidate_master=1 [server3] hostname=192.168.30.2 ssh_port=22 candidate_master=1
四、開啓服務以前的檢測
注意：開啓服務以前的檢查很是有必要，由於mha服務是管理mysql的，全部要求很嚴格，若是檢查通不過，開啓服務時會有一堆錯誤。每次啓動服務以前都需檢測環境。
masterha_check_ssh -conf=/etc/mha_master/app.cnf
[info]All SSH connection tests passed successfully.
② 檢查管理的MySQL 複製集羣的鏈接配置參數是否OK ：
masterha_check_repl -conf=/etc/mha_master/app.cnf
MySQL Replication Health is OK.
③ 注意：若是測試時會報錯 ，多是從節點上沒有帳號，由於這個架構，任何一個從節點，將有可能成爲主節點，因此也須要建立帳號。
MariaDB [(none)]> grant all on *.* to 'mhaadm'@'192.168.30.%' identified by 'along';
MariaDB [(none)]> FLUSH PRIVILEGES;
五、啓動MHA
nohup masterha_manager -conf=/etc/mha_master/app.cnf &> /etc/mha_master/manager.log &
啓動成功後，可用過以下命令來查看master 節點的狀態:
masterha_check_status -conf=/etc/mha_master/app.cnf
app (pid:3777) is running(0:PING_OK), master:192.168.30.107
上面的信息中"app (pid:3777)is running(0:PING_OK)" 表示MHA 服務運行OK ，不然，則會顯示爲相似"app is stopped(1:NOT_RUNNINg)."
（2）若是要中止MHA ，須要使用master_stop 命令。
masterha_stop -conf=/etc/mha_master/app.cnf
六、測試MHA 測試故障轉移
(1) 在master 節點關閉mariadb 服務， 模擬主節點數據崩潰
tail -20 /etc/mha_master/manager.log 日誌文件中出現以下信息，表示manager 檢測到192.168.30.107節點故障，然後自動執行故障轉移，將192.168.30.7 提高爲主節點。
注意：故障轉移完成後，manager 將會自動中止，此時使用
masterha_check_status 命令檢測將會遇到錯誤提示，以下所示：
七、提供新的從節點以修復複製集羣
原有 master 節點故障後，須要從新準備好一個新的 MySQL 節點。基於來自於master 節點的備份恢復數據後，將其配置爲新的 master 的從節點便可。注意，新加入的節點若是爲新增節點，其 IP 地址要配置爲原來 master 節點的 IP ，不然，還須要修改 app.cnf 中相應的 ip 地址。隨後再次啓動 manager ，並再次檢測其狀態。
除了增長新的mysql 節點，也能夠將壞掉主mysql 修復，再將其做爲從加入集羣中。因爲機器有限，我就用修復好的主做爲從，修復複製集羣。
mysqldump --all-databases > /backup/mysql-all-backup-`date +%F-%T`.sql
scp /backup/mysql-all-backup-2017-11-26-14\:03\:19.sql @192.168.30.107:
mysql -uroot -p < mysql-all-backup-2017-11-26-14\:03\:19.sql
MariaDB [(none)]> show master status;
MariaDB [(none)]> change master to master_host='192.168.30.7', master_user='slave', master_password='along', master_log_file='mysql-bin.000003', master_log_pos=245; MariaDB [(none)]> start slave;
revoke delete on *.* from 'mhaadm'@'192.168.30.%'; revoke delete on *.* from 'slave'@'192.168.30.%'; grant replication slave,replication client on *.* to slave@'192.168.30.%' identified by 'along'; grant all on *.* to 'mhaadm'@'192.168.30.%' identified by 'along';
masterha_check_status -conf=/etc/mha_master/app.cnf masterha_check_repl -conf=/etc/mha_master/app.cnf 檢查無誤，再次運行，此次要記錄日誌 masterha_manager -conf=/etc/mha_master/app.cnf >/etc/mha_master/manager.log 2>&1 &
八、新節點上線，故障轉換恢復注意事項
(1) 在生產環境中，當你的主節點掛了後，必定要在從節點上作一個備份，拿着備份文件把主節點手動提高爲從節點，並指明從哪個日誌文件的位置開始複製
(2) 每一次自動完成轉換後，每一次的(replication health ) 檢測不ok 始終都是啓動不了必須手動修復主節點，除非你改配置文件
masterha_check_repl --conf=/etc/mha_master/app.cnf
masterha_manager --conf=/etc/mha_master/app.cnf
- 1. 實驗：Mysql實現企業級數據庫主從複製架構實戰
- 2. Mysql實現企業級數據庫主從複製架構實戰
- 3. Mysql實現企業級數據庫主從複製架構
- 4. 實驗：Mysql實現企業級數據庫互爲主從架構實戰
- 5. 企業級mysql數據庫集羣實戰——mysql的主從複製
- 6. Linux企業實戰-Mysql(2)gtid實現主從複製
- 7. mysql主從複製實戰
- 8. MySQL主從複製實戰
- 9. MYSQL主從複製實戰
- 10. 實戰項目——mysql主從架構的實現
- 更多相關文章...
- • Thymeleaf項目實踐 - Thymeleaf 教程
- • AJAX 數據庫實例 - ASP 教程
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • Docker容器實戰(六) - 容器的隔離與限制
-
每一个你不满意的现在，都有一个你没有努力的曾经。