MySQL-12mysql主從復制與備份

大家好，本片總結一下MySQL的主從復制，有些不對的地方可以評論，一起交流。

mysql主從復制與備份

  • 主從復制概述
  • 主從復制原理
  • 主從復制備份
  • 主從復制實現方式

MySQL數據庫支持單向、雙向、鏈式級聯、環(huán)狀等不同業(yè)務場景的復制。在復制過程中，一臺服務器充當 主服務器(Master)，接收來自用戶的內容更新，而一個或多個其他的服務器充當從服務器(Slave)，接 收來自主服務器binlog文件的日志內容，解析出SQL重新更新到從服務器，使得主從服務器數據達到一致。

1.1 應用場景

MySQL主從復制集群功能使得MySQL數據庫支持大規(guī)模高并發(fā)讀寫稱為可能，同時有效地保護了物理服務器宕機場景的數據備份。

  • 應用場景1:從服務器作為主服務器的實時數據備份

主從服務器架構的設置，可以大大加強MySQL數據庫架構的健壯性。例如:當主服務器出現問題時，我們 可以人工或設置自動切換到從服務器繼續(xù)提供服務，此時從服務器的數據和宕機時的主數據庫幾乎是一致的。
這類似NFS存儲數據通過inotify+rsync同步到備份的NFS服務器，只不過MySQL的復制方案是其自帶的工 具。
利用MySQL的復制功能做備份時，在硬件故障、軟件故障的場景下，該數據備份是有效的，但對于人為地 執(zhí)行drop、delete等語句刪除數據的情況，從庫的備份功能就沒有用了，因為從服務器也會執(zhí)行刪除的語 句。

  • 應用場景2:主從服務器實時讀寫分離，從服務器實現負載均衡

主從服務器架構可通過程序(PHP、Java等)或代理軟件(mysql-proxy、Amoeba)實現對用戶(客戶 端)的請求讀寫分離，即讓從服務器僅僅處理用戶的select查詢請求，降低用戶查詢響應時間及讀寫同時在 主服務器上帶來的訪問壓力。對于更新的數據(例如update、insert、delete語句)仍然交給主服務器處理，確保主服務器和從服務器保持實時同步。

  • 應用場景3:把多個從服務器根據業(yè)務重要性進行拆分訪問

可以把幾個不同的從服務器，根據公司的業(yè)務進行拆分。例如:有為外部用戶提供查詢服務的從服務器， 有內部DBA用來數據備份的從服務器，還有為公司內部人員提供訪問的后臺、腳本、日志分析及供開發(fā)人員 查詢使用的從服務器。這樣的拆分除了減輕主服務器的壓力外，還可以使數據庫對外部用戶瀏覽、內部用 戶業(yè)務處理及DBA人員的備份等互不影響。

1.2 優(yōu)點與解決的問題

  • 主從復制的優(yōu)點
    1.如果主庫出現問題，可以快速切換到從庫提供服務。
    2.可以在從庫執(zhí)行查詢操作，降低主庫的訪問壓力。
    3.可以在從庫進行備份，以免備份期間影響主庫的服務。

  • 主從復制解決的問題（重點）

    1.數據分布 (Data distribution )
    2.負載平衡(load balancing)
    3.數據備份(Backups) ，保證數據安全
    4.高可用性和容錯行(High availability and failover)
    5.實現讀寫分離，緩解數據庫壓力

注意:由于 mysql 實現的異步復制，所以主庫和從庫數據之間存在一定的差異，在從庫執(zhí)行查詢 操作需要考慮這些數據的差異，一般只有更新不頻繁和對實時性要求不高的數據可以通過從庫查詢，實行要求高的仍要從主庫查詢。

2. 主從復制原理

MySQL主從復制涉及到三個線程，一個運行在主節(jié)點(log dump thread)，其余兩個(I/O thread, SQL thread)運行在從節(jié)點，如下圖所示

主從節(jié)點.png

3個節(jié)點介紹

  • 主節(jié)點 log dump 線程

當從節(jié)點連接主節(jié)點時，主節(jié)點會為其創(chuàng)建一個log dump 線程，用于發(fā)送和讀取bin-log的內容。在讀取 bin-log中的操作時，log dump線程會對主節(jié)點上的bin-log加鎖，當讀取完成，在發(fā)送給從節(jié)點之前，鎖會 被釋放。主節(jié)點會為自己的每一個從節(jié)點創(chuàng)建一個log dump 線程。

  • 從節(jié)點 I/O線程

當從節(jié)點上執(zhí)行 start slave 命令之后，從節(jié)點會創(chuàng)建一個I/O線程用來連接主節(jié)點，請求主庫中更新的bin-log。I/O線程接收到主節(jié)點的blog dump進程發(fā)來的更新之后，保存在本地relay-log(中繼日志)中。

  • 從節(jié)點 SQL線程
  • SQL線程負責讀取relay-log中的內容，解析成具體的操作并執(zhí)行，最終保證主從數據的一致性。

對于每一個主從連接，都需要這三個進程來完成。
當主節(jié)點有多個從節(jié)點時，主節(jié)點會為每一個當前連接 的從節(jié)點建一個log dump 進程，而每個從節(jié)點都有自己的I/O進程，SQL進程。
從節(jié)點用兩個線程將從主 庫拉取更新和執(zhí)行分成獨立的任務，這樣在執(zhí)行同步數據任務的時候，不會降低讀操作的性能。
比如，如 果從節(jié)點沒有運行，此時I/O進程可以很快從主節(jié)點獲取更新，盡管SQL進程還沒有執(zhí)行。
如果在SQL進程 執(zhí)行之前從節(jié)點服務停止，至少I/O進程已經從主節(jié)點拉取到了最新的變更并且保存在本地relay日志中，當 服務再次起來之后，就可以完成數據的同步。

重點：
要實施復制，首先必須打開Master 端的binary log(bin-log)功能，否則無法實現。

因為整個復制過程實際上就是Slave 從Master 端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。如下圖所示:
執(zhí)行順序.png

2.1 復制的基本過程

  • 1.在從節(jié)點上執(zhí)行sart slave命令開啟主從復制開關，開始進行主從復制。從節(jié)點上的I/O 進程連接主節(jié) 點，并請求從指定日志文件的指定位置(或者從最開始的日志)之后的日志內容;
  • 2.主節(jié)點接收到來自從節(jié)點的I/O請求后，通過負責復制的I/O進程(log dump 線程)根據請求信息讀取 指定日志指定位置之后的日志信息，返回給從節(jié)點。返回信息中除了日志所包含的信息之外，還包括 本次返回的信息的bin-log file 的以及bin-log position(bin-log中的下一個指定更新位置);
  • 3.從節(jié)點的I/O進程接收到主節(jié)點發(fā)送過來的日志內容、日志文件及位置點后，將接收到的日志內容更新 到本機的relay-log(中繼日志)的文件(Mysql-relay-bin.xxx)的最末端，并將讀取到的binary log(bin-log)文件名和位置保存到master-info 文件中，以便在下一次讀取的時候能夠清楚的告訴 Master“我需要從某個bin-log 的哪個位置開始往后的日志內容，請發(fā)給我”;
  • 4.Slave 的 SQL線程檢測到relay-log 中新增加了內容后，會將relay-log的內容解析成在主節(jié)點上實際執(zhí)行 過SQL語句，然后在本數據庫中按照解析出來的順序執(zhí)行，并在relay-log.info中記錄當前應用中繼日志 的文件名和位置點。

3.主從復制備份

不同類型的數據庫備份，所能應付的情況是不一樣的， 而且，數據庫的備份同時也還具有其他很多的作 用。相信每個人對數據庫備份作用的理解都會有差別。
1. 數據丟失應用場景
(1)人為操作失誤造成某些數據被誤操作;
(2)軟件BUG造成數據部分或全部丟失;
(3)硬件故障造成數據庫數據部分或全部丟失;
(4)因安全漏洞，入侵者將數據惡意破壞。

2. 非數據丟失應用場景
(1)特殊應用場景下基于時間點的數據恢復;
(2)開發(fā)測試環(huán)境數據庫搭建;
(3)相同數據庫的新環(huán)境搭建;
(4)數據庫或數據遷移。

注：啰嗦點話：

上面所列出的只是一些常見的應用場景，除了這幾種場景，數據庫備份還會有很多其他應用場景。
沒有哪一種數據庫備份能夠解決以上列舉的所有場景，即使僅只是數據丟失的各種場景都無法通過某一種 數據庫 備份完美解決，當然就更不用說能夠解決所有備份的應用場景了。比如:

  1. 當我們遇到磁盤故障，丟失了整個數據庫的所有數據，并且無法從已經出現故障的硬盤上面恢復出來 的時候，就可能必須通過一個實時或有短暫時間差的復制備份數據庫來進行恢復。當然如果沒有這樣 的一個數據庫，就必須有最近時間點的整個數據庫的物理或邏輯備份數據，并且有該備份之后的所有 物理或邏輯增量備份，以期望盡可能地將數據恢復到出現故障之前最近的時間點。
  2. 而當我們遇到操作失誤造成數據被誤操作時，就要有一個能恢復到錯誤操作時間點之前的瞬間備份， 當然這個備份可能是整個數據庫的備份，也可以僅僅是被誤操作的表的備份。
  3. 而當我們要做跨平臺的數據庫遷移時，則需要一個邏輯的數據庫備份，因為平臺的差異可能使物理備 份的文件格式在兩個平臺上無法兼容。
    既然沒有哪一種數據庫備份能夠完美地解決所有應用場景的需要，而每個數據庫環(huán)境要面對的數據庫備份 應用場景又可能各不一樣，也許只是須要面對很多種場景中的某種或兒種， 那么就非常有必要指定一個合 適的備份方案和備份策略，通過最簡單的技術和最低廉的成本來滿足我們的需求。

3.1 冷備份與恢復

3.1.1 邏輯備份
邏輯備份可以說是最簡單，也是目前中小型系統(tǒng)最常使用的備份方式。
1.mysqldump
2.mydumper

2. 在從服務上通過連接主服務器上的數據庫，通過mysqldump備份數據到從數據庫中

在主服務器上，設置讀鎖定有效，這個操作為了確保沒有數據庫操作，以便獲得一致性的快照。

flush tables with read lock;

然后在從服務器上進行數據的備份，并同步導入備份數據。

在數據備份完成之后這個時候就可以恢復主數據庫的寫操作執(zhí)行命令如下:

unlock tables;
3.1.2 物理備份

最暴力的備份：停止主庫，然后復制主庫中的data放到從庫中。

3.1.3 使用mydumper

mydumper是一個針對MySQL和drizzle的高性能多線程的備份和恢復工具。此工具的開發(fā)人員分別來自 MySQL、facebook、skysql公司、目前已經有一些大型產 品業(yè)務測試并使用了該工具。我們在恢復數據庫 時也可使用myloader工具。

特性

  • 采用輕量級C語言寫的代碼。
  • 相比于mysqldump，其速度快了近10倍。
  • 具有事務性和非事務性表一致的快照(適用于0.2.2+)。
  • 可快速進行文件壓縮(File compression on-the-fly)。 · 支持導出binlog。
  • 可多線程恢復(適用于0.2.1+)。
  • 可以用守護進程的工作方式，定時掃描和輸出連續(xù)的二進制日志。

剩下的可以自己百度

3.2 熱備份與恢復

熱備份的方式也是直接復制數據物理文件，和冷備份一樣，但熱備份可以不停機直接復制，一般用于7×24小時不間斷的重要核心業(yè)務。
注：有很多其他熱備份的工具，MySQL社區(qū)版的熱備份 工具ImnoDB Hot Backup是付費的所以不考慮這個了。用一下這個，Percona公司發(fā)布了一個xtrabackup熱備份工具。

安裝：

yum localinstall percona-xtrabackup-80-8.0.14-1.el7.x86_64.rpm
xtrabackup

常用命令：

中主要包含兩個工具: xtrabackup:是用于熱備innodb，xtradb表中數據的工具，不能備份其他類型的表，也不能備份數 據表結構;
innobackupex:是將xtrabackup進行封裝的perl腳本，提供了備份myisam表的能力。
常用選項:
--host 指定主機
--user 指定用戶名
--password 指定密碼
--port 指定端口
--databases 指定數據庫
--incremental 創(chuàng)建增量備份
--incremental-basedir 指定包含完全備份的目錄
--incremental-dir 指定包含增量備份的目錄
--apply-log 對備份進行預處理操作 一般情況下，在備份完成后，數據尚且不能用于恢復操作，因 為備份的數據中可能會包含尚未提交的事務或已經提交但尚未同步至數據文件中的事務。 因此，此 時數據文件仍處理不一致狀態(tài)?！皽蕚洹钡闹饕饔谜峭ㄟ^回滾未提交的事務及同步已經提交的事 務至數據文件也使得數據文件處于一致性狀態(tài)。
--redo-only 不回滾未提交事務
--copy-back 恢復備份目錄

開始進行備份操作,進入 主庫 中

xtrabackup --defaults-file=/etc/my.cnf --user=root --password=root -- port=3306 --backup --target-dir=/home/master_slave
//找到備份的文件，進行備份：
scp -r /home/laravel-shop/ root@192.168.153.127:/home/laravel-shop

然后呢進入 從庫中：

//
xtrabackup --defaults-file=/etc/my.cnf --copy-back --target- dir=/home/mysql_php/mysql_php
chown -R mysql:mysql /usr/local/mysql/data

4. 主從復制實現方式

4.1.1 Master節(jié)點配置

單MySQL問題:

  1. 性能問題
  2. 數據備份問題

多MySQL好處

  1. 性能問題--不一定提高;
  2. 數據冗余

對于MySQL的主從復制來說最重要的主要就是binlog日志，所以我們就需要開啟binlog日志，并設置server- id的值。需要重啟服務器之后才生效 二進制日志，也就是我們常說的binlog。

二進制日志記錄了MySQL所有修改數據庫的操作，然后以二進制的形式記錄日志在日志文件中，其中還包 括沒調語句所 執(zhí)行的時間和消耗的資源，以及相關的事務信息。默認情況下二進制日志功能是沒有開啟 的，啟動可以配置log-bin[=file_name]開啟，

show global variables like '%log_bin%';

日志作用就是:

  1. 增量備份(不是所有數據備份，而是最近的寫操作)
  2. 用于MySQL主從復制
vi /etc/my.cnf
//主要就是下配置文件中添加如下配置
log-bin=mysql-bin 
server-id=1

4.1.2 Slave節(jié)點配置

要先明確配置的架構Master-slave

  1. 配置主節(jié)點 1.1 配置賬號 1.2 開啟binlog日志
  2. 配置從節(jié)點 2.1 配置同步日志 2.2 指定主節(jié)點的ip， 端口， 用戶.. 2.3 啟動從節(jié)點
    修改配置
find / -name my.cnf /etc/my.cnf
vi /etc/my.cnf
find / -name mysqld /etc/rc.d/init.d/mysqld/www/server/mysql/bin/mysqld
/etc/rc.d/init.d/mysqld restart

在配置文件中添加:

# 配置從節(jié)點
server-id = 2
relay_log = /usr/local/mysql/data/mysql-relay-bin 
relay_log-index = /usr/local/mysql/data/mysql-relay-bin.index log_slave_updates = 1
read_only = 1

參數介紹:

  1. server_id:這是服務id系統(tǒng)會自動命名的，但如果機器名邊畫畫肯能回答導致問題。可以講你主庫和備庫 上的log-bin設置為相同的值。
  2. relay_log:指定 中繼日志的位置和命名

指定主節(jié)點的ip，端口，用戶

change master to master_host='192.168.29.102',master_port=3306,master_user='slave',master_password='slav e',master_log_file='mysqlbin.000002',master_log_pos=155;

start slave;
show slave status \G;

對于我們來說其中的信息主要是關注：
reset slave all 清楚slave信息 測試的方法就是在主服務器中，添加一些數據測試觀察從服務其中的數據變化 情況。

可以看一下另一篇主從復制文章：http://www.itdecent.cn/p/5ba7770a952f

?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容