企業 - MySQL主從備份
一、雙機熱備的概念簡單說一下,就是要保持兩個數據庫的狀態自動同步。對任何一個數據庫的操作都自動應用到另外一個數據庫,始終保持兩個數據庫中的數據一致。 這樣做有如下幾點好處:
1. 可以做災備,其中一個壞了可以切換到另一個。
2. 可以做負載均衡,可以將請求分攤到其中任何一臺上,提高網站吞吐量。 對於異地熱備,尤其適合災備。
二、mysql 主從備份工作原理
簡單的說就是把 一個服務器上執行過的sql語句在別的服務器上也重復執行一遍, 這樣只要兩個數據庫的初態是一樣的,那麽它們就能一直同步。
二、實現方式
MYSQL主從同步是在MySQL主從復制(Master-Slave Replication
)基礎上實現的,通過設置在Master
上的binlog
,使其處於打開狀態;Slave
通過一個I/O
線程從Master
上讀取binlog
,然後傳輸到Slave
的中繼日誌中,然後使用SQL
線程讀取中繼日誌,並應用到自身數據庫中,從而實現主從數據同步功能。
有兩個服務器,演示了從一個主服務器(master)把數據同步到從服務器(slave)的過程。
對於一個mysql服務器,一般有兩個線程來負責復制和被復制。當開啟復制這個開關之後(start slave)
1. 作為主服務器Master,會把自己的每一次改動都記錄到 二進制日誌 Binarylog 中。 (從服務器會負責來讀取這個log,然後在自己那裏再執行一遍。)
2. 作為從服務器Slave,會用master上的賬號登陸到master上,去讀取master的Binarylog, 然後寫入到自己的中繼日誌Relaylog,然後自己的sql線程會負責讀取這個中繼日誌,並執行一遍。到這裏主服務器上的更改就同步到從服務器上了。
在mysql上可以查看當前服務器的主,從狀態。 其實就是當前服務器的 Binary(作為主服務器角色)狀態和位置。以及其RelayLog(作為從服務器)的復制進度。
三、復制的過程
該過程的第一部分就是master記錄二進制日誌。在每個事務更新數據完成之前,master在二日誌記錄這些改變。MySQL將事務串行的
寫入二進制日誌,即使事務中的語句都是交叉執行的。在事件寫入二進制日誌完成後,master通知存儲引擎提交事務。
下一步就是slave將master的binary
log拷貝到它自己的中繼日誌。首先,slave開始一個工作線程——I/O線程。I/O線程在master上打開一個普通的連接,然後開始binlog
dump process。Binlog dump
process從master的二進制日誌中讀取事件,如果已經跟上master,它會睡眠並等待master產生新的事件。I/O線程將這些事件寫入中
繼日誌。 SQL slave
thread(SQL從線程)處理該過程的最後一步。SQL線程從中繼日誌讀取事件,並重放其中的事件而更新slave的數據,使其與master中的數
據一致。只要該線程與I/O線程保持一致,中繼日誌通常會位於OS的緩存中,所以中繼日誌的開銷很小。
此外,在master中也有一個工作線程:和其它MySQL的連接一樣,slave在master中打開一個連接也會使得master開始一個線程。復制
過程有一個很重要的限制——復制在slave上是串行化的,也就是說master上的並行更新操作不能在slave上並行操作。
實驗
實驗環境
server2 master
server3 slave
master上下載包
mysql-5.7.17-1.el6.x86_64.rpm-bundle.tar
安裝數據庫
[root@server2~]# yum install -y mysql-community-client-5.7.17-1.el6.x86_64.rpm mysql-community-common-5.7.17-1.el6.x86_64.rpm mysql-community-libs-5.7.17-1.el6.x86_64.rpm mysql-community-libs-compat-5.7.17-1.el6.x86_64.rpm mysql-community-server-5.7.17-1.el6.x86_64.rpm
[root@server3 ~]# yum install -y *
修改mysql的配置文件
[root@server2 ~]# vim /etc/my.cnf
server-id = n | 給服務器分配一個唯一的ID編號 |
log-bin [= filename] | 把對數據進行修改的所有SQL命令(也就是INSERT、UPDATE和DELETE命令)以二進制格式記入日誌(二進制變更日誌,binary update log)。這種日誌的文件名是filename.n或默認的hostname.n,其中n是一個6位數字的整數(日誌文件按順序編號)。 |
開啟服務
修改slave配置文件
server-id = n | 給服務器分配一個唯一的ID編號 |
[root@server3 ~]# vim /etc/my.cnf
開啟服務
查看密碼
安全配置向導
如下方法修改slave密碼
mysql> alter user root@localhost identified by 'LH=redhat123';
master上進行授權
mysql> grant replication slave on *.* to cara@'192.168.122.13' identified by 'LH@redhat123' ; 用戶授權
mysql> flush privileges; 刷新
master授權後,slave可以遠程登錄
master端查看
使 slave 與 master 建立連接,從而同步:
mysql> change master to master_host='192.168.122.12',master_user='cara',master_password='LH=redhat123',master_log_file='mysql-bin.000003',master_log_pos=1706;
slave端 mysql -p 登錄
查看
[root@server3 mysql]# pwd
/var/lib/mysql
[root@server3 mysql]# cat master.info
[root@server3 mysql]# cat server3-relay-bin.index
mysql> show slave status\G; 查看slave狀態
mysql> start slave; 開啟slave
創建庫westos,創建表usertb
在表中插入數據
更改密碼
刪除表中數據
[root@server2 mysql]# mysqlbinlog mysql-bin.000003 可查看master所做的操作
在slave上也可查看master上數據
深入了解復制-全局事務標識符(GTID)
1)什麽是GTID
GTID(Global Transaction ID)是對於一個已提交事務的編號,並且是一個全局唯一的編號。GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標 識,保存在mysql數據目錄下的auto.cnf文件裏。TID代表了該實例上已經提交的事務數量,並且隨著事務提交單調遞增。下面是一個GTID的具 體形式:3E11FA47-71CA-11E1-9E33-C80AA9429562:23。
2)GTID的作用
根據GTID可以知道事務最初是在哪個實例上提交的
GTID的存在方便了Replication的Failover
3)GTID比傳統復制的優勢
更簡單的實現failover,不用以前那樣在需要找log_file和log_Pos。
更簡單的搭建主從復制。
比傳統復制更加安全。
GTID是連續沒有空洞的,因此主從庫出現數據沖突時,可以用添加空事物的方式進行跳過。
4)GTID的工作原理:
master更新數據時,會在事務前產生GTID,一同記錄到binlog日誌中。
slave端的i/o線程將變更的binlog,寫入到本地的relay log中。
sql線程從relay log中獲取GTID,然後對比slave端的binlog是否有記錄。
如果有記錄,說明該GTID的事務已經執行,slave會忽略。
如果沒有記錄,slave就會從relay log中執行該GTID的事務,並記錄到binlog。
在解析過程中會判斷是否有主鍵,如果沒有就用二級索引,如果沒有就用全部掃描。
先關掉slave
修改配置文件/etc/my.cof
master
slave
重啟服務
更錄數據庫,查看
master
slave
change master to master_host='192.168.122.12',master_user='cara',master_password='LH=redhat123',master_auto_position=1;
--------------------------------------------------------------------master端--------------------------------------------------------------------
--------------------------------------------------------------------slave端--------------------------------------------------------------------
企業 - MySQL主從備份