Mysql實現企業級數據庫主從復制架構實戰
背景
公司規模已經形成，用戶數據已成為公司的核心命脈，一次老王一不小心把數據庫文件刪除，通過mysqldump備份策略恢復用了兩個小時，在這兩小時中，公司業務中斷，損失100萬，老王做出深刻反省，公司也因此對於數據庫的性能和可靠性提出更高要求。要求對數據庫進行改造，使其承載力進行提升，故障修復時間減少，有沒有能實現的方案呢？
?
數據庫常遇到的問題
一、性能問題
1、向上拓展 scale up ：針對單臺服務器，提高服務器的硬件性能，比如：內存，cpu等，個體本身 容易達到極限
2、向外拓展 scale out ：多臺服務器形成集群，共同完成一件事情
二、可用性問題
1、數據庫服務中斷
2、誤操作數據損壞
3、硬件故障
4、數據庫升級測試遭遇bug
5、黑客攻擊
?
數據庫高可用技術說明
高可用架構對於互聯網服務基本是標配，無論是應用服務還是數據庫服務都需要做到高可用。雖然互聯網服務號稱7*24小時不間斷服務，但多多少少有一些時候服務不可用，比如某些時候網頁打不開，百度不能搜索或者無法發微博，發微信等。一般而言，衡量高可用做到什麽程度可以通過一年內服務不可用時間作為參考，要做到3個9的可用性，一年內只能累計有8個小時不可服務，而如果要做到5個9的可用性，則一年內只能累計5分鐘服務中斷。所以雖說每個公司都說自己的服務是7*24不間斷的，但實際上能做到5個9的屈指可數，甚至根本做不到，國內互聯網巨頭BAT(百度，阿裏巴巴，騰訊)都有因為故障導致的停服問題。對於一個系統而言，可能包含很多模塊，比如前端應用，緩存，數據庫，搜索，消息隊列等，每個模塊都需要做到高可用，才能保證整個系統的高可用。對於數據庫服務而言，高可用可能更復雜，對用戶的服務可用，不僅僅是能訪問，還需要有正確性保證，因此，對於實現數據庫高可用，對互聯網公司來說極其重要！
企業級數據庫高可用架構圖
?
Mysql主從架構技術說明
Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一臺主機（Master）的數據復制到其它主機（slaves）上，並重新執行一遍來實現的。復制過程中一個服務器充當主服務器，而一個或多個其它服務器充當從服務器。主服務器將更新寫入二進制日誌文件，這些日誌可以記錄發送到從服務器的更新。當一個從服務器連接主服務器時，它通知主服務器從服務器在日誌中讀取的最後一次成功更新的位置。從服務器接收從那時起發生的任何更新，然後封鎖並等待主服務器通知新的更新。
主從復制架構圖
?
?
數據庫復制特性
Mysql復制解決的問題
MySQL復制技術有以下一些特點：
(1) 數據分布 (Data distribution )
(2) 負載平衡(load balancing)
(3) 備份(Backups)
(4) 高可用性和容錯性 High availabilityand failover
?
Mysql復制如何工作
Mysql的復制功能主要有3個步驟：
(1) 主服務器（master）將改變記錄到二進制日誌(binarylog)中（這些記錄叫做二進制日誌事件，binary log events）
(2) 從服務器（slave）將主服務器master的binary logevents拷貝到它的中繼日誌(relay log)
(3) slave重做中繼日誌中的事件，將改變反映它自己的數據。
1、該過程的第一部分就是master記錄二進制日誌。在每個事務更新數據完成之前，master在二進制日誌記錄這些改變。MySQL將事務串行的寫入二進制日誌，在事件寫入二進制日誌完成後，master通知存儲引擎提交事務。此後可接收slave的請求
2、下一步就是slave將master的binary log拷貝到它自己的中繼日誌。首先，slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接，然後開始在主節點上binlog dump process（二進制轉存線程）。Binlog dump process從master的二進制日誌中讀取事件，如果已經跟上master，它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中繼日誌。
3、 SQL slave thread（SQL從線程）處理該過程的最後一步。SQL線程從中繼日誌讀取事件，並重放其中的事件而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌通常會位於OS的緩存中，所以中繼日誌的開銷很小。
?
?
I/O線程：將master數據庫二進制日誌拉到slave數據庫上，並將二進制日誌寫到中繼日誌，寫完之後，他會睡眠並等待master數據庫二進制日誌更新，一旦更新，就會寫入slave數據庫的中繼日誌中
SQL線程：讀取中繼日誌的事件，並在數據庫中執行，寫入到內存中，使slave數據庫的數據與master數據庫中的數據一致
?
Mysql實現企業級數據庫主從復制架構實戰
註意：slave數據庫只能是可讀的，不能是可寫的，如果改變了slave數據庫的數據，master不能從slave數據庫上同步數據，導致主從數據庫數據不一致。
實戰演練
一、環境準備
centos系統服務器2臺、一臺用戶做Mysql主服務器，一臺用於做Mysql從服務器，都在同一個網段中，配置好yum源、防火墻關閉、各節點時鐘服務同步、各節點之間可以通過主機名互相通信
二、準備步驟：
1、iptables -F && setenforce 清空防火墻策略，關閉selinux
2、拿兩臺服務器都使用yum方式安裝Mysql服務，要求版本一致
3、分別啟動兩臺服務器mysql服務，確保服務正常
三、實現步驟:
1、配置master主服務器
對master進行配置，包括打開二進制日誌，指定唯一的servr ID。例如，在配置文件加入如下值
vim /etc/my.cnf
server-id=1 #配置server-id，讓主服務器有唯一ID號（讓從服務器知道他的主服務器是誰）
log-bin=mysql-bin #打開Mysql日誌，日誌格式為二進制
skip-name-resolve#關閉名稱解析，（非必須）
然後重啟數據庫服務
systemctl restart mariadb
2．創建復制帳號
在Master的數據庫中建立一個備份帳戶：每個slave使用標準的MySQL用戶名和密碼連接master
。進行復制操作的用戶會授予REPLICATION SLAVE權限。（給從服務器授權，讓他能從主服務器拷貝二進制日誌）
mysql
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@‘192.168.10.%‘ IDENTIFIED BY ‘magedu‘;
3．查看主服務器狀態
在Master的數據庫執行show master status，查看主服務器二進制日誌狀態
4、配置slave從服務器
對slave進行配置，打開中繼日誌，指定唯一的servr ID，設置只讀權限。在配置文件加入如下值
vim /etc/my.cnf
server-id=2 #配置server-id，讓從服務器有唯一ID號
relay_log = mysql-relay-bin #打開Mysql日誌，日誌格式為二進制
read_only = 1 #設置只讀權限
log_bin = mysql-bin #開啟從服務器二進制日誌
log_slave_updates = 1 #使得更新的數據寫進二進制日誌中
然後重啟數據庫服務
systemctl restart mariadb
5．啟動從服務器復制線程
讓slave連接master，並開始重做master二進制日誌中的事件。
mysql
CHANGE MASTER TO MASTER_HOST=‘192.168.10.190‘,
MASTER_USER=‘slave‘,
MASTER_PASSWORD=‘magedu‘,
MASTER_LOG_FILE=‘mysql-bin.000001‘,
MASTER_LOG_POS=278;
執行start slave；# 啟動復制線程。
6、查看從服務器狀態
可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制狀態：
mysql
SHOW SLAVE STATUS\G
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
7.測試
理想的結果是在主服務器上添加的數據，在從服務器上也會同步
在主服務器上
?
在從服務器上
四、添加新slave服務器
假如master已經運行很久了，想對新安裝的slave進行數據同步，甚至它沒有master的數據。
此時，有幾種方法可以使slave從另一個服務開始，例如，從master拷貝數據，從另一個slave克隆，從最近的備份開始一個slave。為了加快Slave與master同步，可用以下方式先進行數據同步：
(1)master的某個時刻的數據快照；
(2)數據庫的備份數據
(3)master的二進制日誌文件。
?
實現主從從架構
也可以搭建主從從架構，讓從服務器之間進行復制
就是在從服務器也開啟二進制日誌，然後從的從I/O線程再將從的二進制日誌給拷貝過來寫入到自己的relay log中，然後sql線程再讀取relay log中的事件，在數據庫中執行，寫入到內存中。
?
Mysql復制過濾器
復制過濾器：
僅復制有限一個或幾個數據庫相關的數據，而非所有；由復制過濾器進行；
有兩種實現思路：
(1) 主服務器
主服務器僅向二進制日誌中記錄有關特定數據庫相關的寫操作；
binlog_do_db=
binlog_ignore_db=
(2) 從服務器
從服務器的SQL THREAD僅重放關註的數據庫或表相關的事件，並將其應用於本地；
Replicate_Do_DB=
Replicate_Ignore_DB=
?
企業常見數據庫架構
一、單一master和多slave
在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用於讀壓力比較大的應用的數據庫端廉價擴展解決方案。因為只要Master和Slave的壓力不是太大（尤其是Slave端壓力）的話，異步復制的延時一般都很少很少。尤其是自從Slave端的復制方式改成兩個線程處理之後，更是減小了Slave端的延時問題。而帶來的效益是，對於數據實時性要求不是特別高的應用，只需要通過廉價的pcserver來擴展Slave的數量，將讀壓力分散到多臺Slave的機器上面，即可通過分散單臺數據庫服務器的讀壓力來解決數據庫端的讀性能瓶頸，畢竟在大多數數據庫應用系統中的讀壓力還是要比寫壓力大很多。這在很大程度上解決了目前很多中小型網站的數據庫壓力瓶頸問題，甚至有些大型網站也在使用類似方案解決數據庫瓶頸。
單一master和多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。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。
即：在兩臺服務器上既執行master的操作又執行slave的操作（註意：兩臺數據庫都必須是可寫的）
?
互為主從復制過程
互為主從：兩個節點各自都要開啟binlog和relay log；
1、數據不一致；
2、自動增長id；
?
什麽是自增長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‘);
?
定義一個節點使用奇數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； read only = 0(因為互為主從，所以必須是可寫的)
3、存在自動增長id的表，為了使得id不相沖突，需要定義其自動增長方式；
服務啟動後執行如下兩步：
4、都授權有復制權限的用戶賬號；
5、各把對方指定為主節點；
?
實驗：數據庫互為主從復制步驟
1.修改mysql配置文件
一臺數據庫服務器上
vim /etc/my.cnf
server-id = 1
log_bin = mysql_bin
relay_log = relay-log
skip-name-resolve = on
log_slave_updates = 1
auto_increment_increment=2
auto_increment_offset=1
另一臺數據庫服務器上
vim /etc/my.cnf
server-id = 2
relay_log = relay-log
log_bin = mysql-log
skip-name-resolve = on
log_slave_updates = 1
auto_increment_increment=2
auto_increment_offset=2
修改完配置文件後，重啟數據庫服務
systemctl restart mariadb
2．創建復制帳號
分別在兩臺數據庫服務器上創建復制賬號
mysql
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@‘192.168.10.%‘ IDENTIFIED BY ‘magedu‘;
3．啟動從服務器復制線程
讓slave連接master，並開始重做master二進制日誌中的事件。
mysql
CHANGE MASTER TO MASTER_HOST=‘192.168.10.190‘,
MASTER_USER=‘slave‘,
MASTER_PASSWORD=‘magedu‘,
MASTER_LOG_FILE=‘mysql-bin.000001‘,
MASTER_LOG_POS=278;
執行start slave；# 啟動復制線程。
另一臺數據庫服務器也是如此
4、查看從服務器狀態
可使用SHOW SLAVE STATUS\G查看從服務器狀態，如下所示，也可用show processlist \G查看前復制態：
mysql
SHOW SLAVE STATUS\G
Slave_IO_Running: Yes #IO線程正常運行
Slave_SQL_Running: Yes #SQL線程正常運行
兩臺數據庫服務器都顯示如上結果就ok
5.創建表，設置ID為自增長,兩邊插入數據看數據增長
在一臺數據庫服務器上
mysql
create database dnf;
use dnf;
create table userinfo (id int PRIMARY KEY AUTO_INCREMENT,name varchar(20) NOT NULL);
insert into userinfo (name) values(‘ni‘),(‘wo‘),(‘ta‘);
然後查看表，因為是自增長id，從1開始，步長為2，所以添加的數據id為1,3,5
然後在另一臺數據庫服務器插入數據，因為是自增長id，從2開始，步長為2，所以新添加的數據id為6,8,10
?
排錯：當配置文件中配置中繼日誌格式不小心配置錯了，或者讓slave連接master，執行sql語句不小心寫錯了，都有可能導致start slave；報錯，此時可以show slave status\G;會出現一大串信息，裏面會提示錯誤。找到錯誤以後，重置slave，reset slave;重新設置，然後再start slave；
註意：mysql的錯誤日誌非常重要，可以提供錯誤信息，從而找到錯誤原因。
?
互為主從容易導致數據不一致，此時我們可以用兩個實例來互為主從
mysql優化：
1.可以用數據緩存，常見的memcache
2.數據庫本身有很多緩存機制，可使用對應的緩存策略
3.對數據來說，竟可能使用索引
4.對請求而言，可以實現讀寫分離，對讀請求負載均衡
5.對大數據庫或者表，可根據業務邏輯進行分庫分表
6.多有的優化，盡可能網內存中存放
?
?
半同步復制
異步復制（Asynchronous replication）
MySQL默認的復制即是異步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升為主，可能導致新主上的數據不完整
全同步復制（Fully synchronous replication）
指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步復制的性能必然會收到嚴重的影響。需要有超時時間。
半同步復制（Semisynchronous replication）
介於異步復制和全同步復制之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步復制，半同步復制提高了數據的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復制最好在低延時的網絡中使用。
?
半同步復制
支持多種插件：/usr/lib64/mysql/plugins/
需要安裝方可使用：
mysql> INSTALL PLUGIN plugin_name SONAME ‘shared_library_name‘;
半同步復制：
semisync_master.so
semisync_slave.so
?
主節點：
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+------------------------------------+-------+
| Variable_name | Value |
+------------------------------------+-------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
+------------------------------------+-------+
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_master_enabled=ON/1;
stop slave;
start slave;
?
從節點：
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
+---------------------------------+-------+
| Variable_name | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------+-------+
MariaDB [mydb]> STOP SLAVE IO_THREAD;
MariaDB [mydb]> SET GLOBAL rpl_semi_sync_slave_enabled = ON ;
MariaDB [mydb]> SHOW GLOBAL VARIABLES LIKE ‘rpl_semi%‘;
MariaDB [mydb]> START SLAVE IO_THREAD;
stop slave;
start slave;
可查看從庫錯誤日誌觀察是否生效
master錯誤日誌
slave錯誤日誌
?
?
Mysql實現企業級數據庫主從復制架構實戰