MySQL備份,恢復方案,mysqlbinlog,mysqldump,主從,主主複製

  DBMS數據庫管理系統的三層模型:物理層,邏輯層以及視圖層。

  物理層:決定數據的存儲形式。

  邏輯層:是一張有一張的表,一行行的數據記錄。

  視圖層:讓用戶看起來更方便,可有可無。

  存儲引擎:使邏輯層中sql語句轉換成能在磁盤上存儲的物理形式,連接邏輯層與物理層。

  常用MySQL存儲引擎:

    MyISAM:

      最經典的MySQL存儲引擎,但如果數據庫一旦崩潰,再重啓時需要對錶進行修復,但MyISAM

    存儲引擎無法保證安全修復,且其不支持事務的進行。支持表級鎖。

    Innodb:

      Innodb存儲引擎,支持事務,數據庫的存儲,是以表空間的方式存儲,支持MVCC的高併發,

    支持四種隔離級別,read-uncommitted讀未提交,read-committed讀提交,repeatable-read幻讀

    serializable串行化。支持行級鎖,間隙鎖。

    Aria:

      Aria存儲引擎數據庫一旦崩潰,能夠對數據庫安全修復增強版MyISAM存儲引擎。

    Memory:

      內存級存儲引擎,支持自適應hash索引,查詢能力十分強大。

    MRG_MyISAM:

      將多張表邏輯層連接在一起,使用戶就像使用一張表一樣。

    PERFORMANCE_SCHEMA:

      展示數據庫運行時的狀態參數和統計數據。

    CSV:

      基於文件的文件存儲數據存儲引擎。

    ARCHIVE:

      歸檔存儲引擎,通常用於做數據倉庫。

  

  MySQL的日誌:

  ①查詢日誌:

     general_log {ON|OFF} :查詢日誌是否開啓關閉。

     general_log_file hostname.log :該變量的生效,需要在log_output爲FILE時才能生效。

     log_output  FILE:

      FILE:表示將日誌記錄於文件系統中的文件;

      TABLE:表示將日誌記錄於MySQL中指定的表;

      NONE:表示不將日誌記錄輸出出去;

  ②慢查詢日誌:

     運行時間超過某指定時長的操作。

     定義查詢超時時長的變量:

       long_query_time   10.000000

     慢查詢日誌是否開啓:

      log_slow_queries    OFF    

     

     slow_query_log_file hostname.log :該變量的生效,需要在log_output爲FILE時才能生效。

     log_output  FILE:

      FILE:表示將日誌記錄於文件系統中的文件;

      TABLE:表示將日誌記錄於MySQL中指定的表;

      NONE:表示不將日誌記錄輸出出去;

  ③錯誤日誌

      log_error:保存了錯誤日誌的文件路徑;

      log_warnings  {ON|OFF}:是否將mysqld運行過程中產生的"Warning"類的信息一併記錄到錯誤日誌中;

  ④二進制日誌

     用於記錄引起數據庫改變的SQL語句,可以通過備份二進制日誌中的指定內容來達到數據庫備份,還原的目的

   這一部分操作,在後邊有示例。

     需要在/etc/my.cny配置文件中設置log_bin路徑。

     mysql>show master|binary logs:顯示當前數據庫中所有二進制日誌列表。

     mysql>show master status:顯示當前數據庫中正在使用的數據庫列表,可以對指定日誌的position,datetime進行備份還原。

     mysql>show binlog events in '日誌path':顯示對應二進制日誌文件的內容。

  數據庫備份方式:

    數據庫備份作爲一種重要的數據保存手段,需要根據不同環境採取不同的備份操作,最大限度保證數據的安全,畢竟數據

  纔是一個企業生存的根本

  ①LVM實現MYSQL物理備份,恢復

   首先,在主機中加入一塊硬盤充當MYSQL的數據存放的邏輯卷,以及備份數據的存儲源

   #fdisk /dev/sdb

   因實驗需要,所以只配置了一個擴展分區,及一個邏輯分區,將邏輯分區類型更改爲8e即可;

   創建邏輯卷:

     #pvcreate /dev/sdb5

     #vgcreate myvg /dev/sdb5

     #lvcreate -L 5G -n mylv myvg

   對邏輯捲進行格式化:

     #mke2fs -t ext4 /dev/myvg/mylv

   創建數據庫存放的路徑

     #mkdir -pv  /mysql/data

   修改數據庫配置文件/etc/my.cnf

    QQ截圖20180104182739.jpg

    並在當前啓動mysql用戶家目錄下創建.my.cnf文件,否則無法正常啓動mysql

    QQ截圖20180104183405.jpg

    

   到這裏mysql服務就會在我們指定的邏輯卷中運行,lvm的備份方式主要是溫備份,但

   也可以說是幾乎熱備份,只要對數據庫加鎖,解鎖的過程夠快,一般幾秒鐘即可,就

   不會引起數據的錯亂;

   對所有表進行加鎖操作:

   MariaDB [hellodb]> flush tables with read lock;

   

   緊接着拍攝快照,針對於該邏輯卷:

   [root@zabbix-agent4 ~]# lvcreate -L 5G -s -n snap /dev/myvg/mylv


   再對數據庫中的表進行解鎖操作:

   MariaDB [hellodb]> unlock tables;

   

   對二進制日誌進行備份操作,備份當前運行的位置

   mysql -e "show master status" > /path

   (這樣在需要還原數據時可以得知在備份那個時間段後我們執行了哪些操作,從二進制日誌文件可以看出,從而進行還原)


   速度夠快的話就不會產生多大的數據損失,緊接着將快照卷掛載到指定目錄下,對數據進行打包壓縮,卸載快照卷即可將數據庫備份;

   QQ截圖20180104184202.jpg

   

  ②select語句進行邏輯備份

    創建一個同classes表中數據結構一樣的表;

    QQ截圖20180104184627.jpg

    使用select將數據保存在文件中,並導入到test表當中對數據庫進行備份

    QQ截圖20180104185156.jpg

     QQ截圖20180104185248.jpg


  ③使用mysqldump對數據庫進行備份

      mysqldump -uroot -p password 數據庫名 --lock-tables --flush-logs --master-data=2 > /path.sql

      使用上述方式對指定數據庫中的所有表進行加鎖,--flush-logs對二進制日誌文件僅刷新一次,而不是重複刷新

      --master-data將二機制日誌文件名和其所用到的時間的位置標識,追加到備份文件中,1爲不註釋,2爲註釋;

     

      保存在/path.sql路徑下後,只需要進入指定備份的數據庫,並使用source /path.sql即可還原備份數據;

      

      注意:上述方式需要事先創建同名數據庫,然後進入該數據庫執行source操作;

      可使用另一種musqldump格式,可將數據庫的數據格式也備份下來,這樣就無需創建數據庫進行還原

      如:

         mysqldump -uroot -p password --database 數據庫名 --lock-tables --flush-logs --master-data=2 > /path.sql


      對二進制日誌進行備份操作,備份當前運行的位置

        mysql -e "show master status" > /path

      (這樣在需要還原數據時可以得知在備份那個時間段後我們執行了哪些操作,從二進制日誌文件可以看出,從而進行還原)


  ④percona xtrabackup實現數據庫備份

       xtrabackup是一款由percona提供的世界上唯一一款開源實現innodb數據庫熱備份的工具

     其備份過程快速可靠,不會打斷正在執行的事務,還原速度快,能夠實現自動檢驗;

     MYISAM完全備份

     MYISAM因爲不不支持事務,所以只能實現溫備份,即在只讀不可寫的狀況下的數據庫備份,無法進行增量備份

     只能進行完全備份

     熱備份:可讀可寫;

     溫備份:只讀不可寫;

     冷備份:不可讀不可寫;

     安裝xtrabackup,在阿里雲中的epel源中

     #yum install -y percona xtrabackup

    

     使用innobackupex進行備份

       --user:指定備份數據庫所用的用戶;

       --password:備份數據庫用戶所用的密碼;

       --host:備份數據庫所在的主機;

       --socket:指定備份數據庫所用的socket路徑;

       如:

       戰盟圖片1515153854.jpg

         因爲之前有更改過數據庫文件的默認路徑,所以需要指定socket

       最後的路徑爲完全備份存儲的路徑,innobackex命令如果不特別指定格式的話,會以日期的形式將完全備份

       存儲在該目錄下

        #mkdir -pv /mysql/backup2

        #chown mysql:mysql /mysql/backup2

       戰盟圖片1515154224.jpg

        進行還原準備操作,因爲數據庫在進行還原時,需要考慮在備份數據庫時是否有事務在進行卻尚未提交,是否有事務

      已經提交,但尚未同步到數據庫當中,我們需要針對這類型的數據進行一致化操作,"準備"的主要作用正是通過回滾

      未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。

      戰盟圖片1515155774.jpg

       備份存儲好之後,將數據全部刪除,驗證備份數據

       使用--copy-back選項即可,不管是完全備份,還是完全備份+增量備份的還原都是該選項進行

       戰盟圖片1515154361.jpg

       

      注意:備份還原操作,需要在原數據庫文件全部刪除,mysqld進程不在運行的條件下執行

      且備份後的數據庫文件權限均爲root,需要更改爲mysql

      戰盟圖片1515154530.jpg

      啓動服務,數據庫完好無損。


      INNODB完全備份+增量備份

      Innodb存儲引擎支持事務,其可支持溫備份以及熱備份;這也是innobackupex的一大特點;

      增量備份是基於上一次備份後產生的數據差別進行的備份;

      首先將數據庫進行幾次修改,並逐一進行完全備份,增量備份操作

      首次完全備份

      戰盟圖片1515156178.jpg

      增量備份:

      戰盟圖片1515156200.jpg

      戰盟圖片1515156229.jpg

      準備操作:

      戰盟圖片1515156440.jpg

      戰盟圖片1515156453.jpg

      戰盟圖片1515156464.jpg

      --redo-only:在最後一次增量備份時不使用

      戰盟圖片1515156007.jpg

      準備結束後就可執行還原操作,刪除原數據庫內容,關閉數據庫服務

      戰盟圖片1515156735.jpg

      戰盟圖片1515156782.jpg

     採用增量備份的方式,分兩次添加了ClassID9,10數據

      戰盟圖片1515156924.jpg

     

  MySQL主從複製:

    在MySQL中,支持單項,異步複製,而主從複製,則是由至少兩臺MySQL服務器實現,由一臺MySQL

  作爲主服務器,進行寫入操作,而由另一臺MySQL服務器作爲從服務器進行讀操作,主數據庫中的數據

  會自動備份到從服務器,可以進行讀寫分離操作,以增強數據庫的讀寫性能。而兩臺服務器之間使用不同

  的硬盤,當主服務器的硬盤損壞時,從服務器的數據就保留下來,進行數據恢復。

    主從服務器搭建的原理是,從服務器開啓數據庫線程sql_thread,io_thread並在/etc/my.cnf中構建中繼

  日誌,用於存放從主服務器複製過來的數據,io_thread線程是向主服務器之間搭建數據複製的橋樑,當主

  服務器中數據庫的數據改變時,會寫入二進制日誌當中,由io_thread讀取,並複製,需要由主服務器指定

  執行復制操作的數據庫用戶,並授權,在從服務器配置相關master,指定主服務器IP,複製數據庫用戶的

  賬號,密碼,由哪一個二進制日誌文件開始複製,從該二進制文件當中的哪個位置開始複製等。當io_thread

  取回複製的數據庫內容後,就存放在從服務器的中繼日誌當中,由sql_thread線程將中繼日誌中的數據寫入

  到執行存儲引擎,備份成功!

    主服務器配置:IP,172.16.25.101

    配置二進制文件,設置server_id

    QQ截圖20180108130514.jpg

    

    對用戶進行授權,設置用戶複製權限

    QQ截圖20180108130717.jpg

    

    主從複製需要將主服務器中的數據庫完全備份到從服務器,否則會報錯,無法進行主從複製

     主服務器:

     QQ截圖20180108131154.jpg

     從服務器:

     QQ截圖20180108131439.jpg

     

    從服務器配置:

      配置 relay_log中繼日誌,server_id在/etc/my.cnf中

   QQ截圖20180108131628.jpg

   配置從服務器中的master指向

   QQ截圖20180108131758.jpg

  master_host:主服務器IP.

  master_user:主服務器上進行復制的數據庫用戶。

  master_password:主服務器上進行復制的數據庫用戶密碼。

  master_log_file:從主服務器上的哪個二進制日誌文件開始複製。這裏我選定的是最後一個二進制日誌。

  master_log_pos:從主服務器上的指定二進制日誌文件的哪個位置開始複製。


  這個時候可以使用show slave status\G查看

  QQ截圖20180108132207.jpg

  兩個線程均沒有開啓,現在開啓線程則主從複製啓用

  QQ截圖20180108132323.jpg

  

  在主服務器數據庫中插入一條數據,在查看從哪個服務器看是否進行了複製操作

  主服務器:

  QQ截圖20180108132510.jpg

  從服務器:

  查看數據是否複製:

  QQ截圖20180108132644.jpg

 

  MySQL主從複製之半同步:

    半同步複製,在對主從複製的基礎上進行延伸,如主從複製時,主服務器在向從服務器傳輸數據時,從服務器

  突然宕機,則數據的傳輸會有兩種情況,

     1.事務還未發送到從服務器上。

     2.事務已發到從服務器上,但客戶端會接受到事務傳送失敗的消息,重新發送事務。

    所以針對於以上情況,MySQL數據庫推出了全新的半同步機制,在從服務器宕機後,會有一段延遲時間讓主服

  務器去聯繫從服務器,若沒有聯繫上就寫入主服務器自身,待從服務器聯繫上了再寫入從服務器,這種異步加同

  步的操作就稱之爲半同步。

     半同步需要對主從服務器加載特殊的插件,插件保存在/usr/lib64/mysql/plugin中

   QQ截圖20180109124102.jpg

   主服務器/etc/my.cnf

   QQ截圖20180109130855.jpg

   從服務器/etc/my.cnf

   QQ截圖20180109130909.jpg

   半同步複製則需要semisync_master.so,semisync_slave.so兩種插件,分別加載到主從服務器

   主:

   QQ截圖20180109130420.jpg

   從:

   QQ截圖20180109130441.jpg

   將主從服務器的同步機制開啓:

     QQ截圖20180109130707.jpg

     QQ截圖20180109130723.jpg

     將從服務器進行授權,指定master

     QQ截圖20180109131041.jpg

     在從服務器上設置只讀,read_only開啓,並開啓另一個MySQL會話並執行

     mysql>flush tables with read lock;

     只要該會話不關閉則讀鎖一直存在。

     

   如何查看半同步是否成功:

   rpl_semi_sync_master_clients爲1

   QQ截圖20180109131958.jpg

   看nakahcehur在主服務器處進行寫操作查看是否同步到從服務器上

     QQ截圖20180109131315.jpg

     從服務器:

     QQ截圖20180109131328.jpg

    當關閉從服務器線程時

    主服務器再次寫入數據,延遲十秒

    QQ截圖20180109131458.jpg

    這是因爲主服務器上的同步延遲設置爲十秒,當十秒內無法聯繫上從服務器,就寫入自身,如:

    QQ截圖20180109131739.jpg

    timeout設置爲10000毫秒,即爲10s

    

    

  MySQL主主複製:

    主主複製,至少兩臺的數據庫服務器 ,都作爲主服務器,每一臺服務器既是主服務器,也是對面主服務器

  的從服務器,實現原理同上,不同的是每一臺服務器都需要有中繼日誌和二進制日誌,因爲每一臺服務器都

  作爲主服務器以及從服務器。主主複製相較於主從複製來說,多了一個mysql入口,相當於mysql的高可用

  但卻需要考慮ID增長的問題。

    主主複製相對於主從複製,需要注意的是

    1.數據不一致,比如,一臺服務器在進行更新操作,將35歲包括以上人的工資上調3000元,當數據庫複製

    到另一臺服務器,數據進行重寫,寫入到這臺服務器時,如果這臺服務器執行了給每一個員工增加1歲時

    這樣剛巧有些人從34歲到了35歲的年齡的話,該數據就會不一致。目前只能使用一些數據恢復軟件來進

    行排錯.

    2.主鍵,當兩臺服務器同時都插入數據時,一些自動增長的如ID的屬性可能會重合,這樣會導致衝突,數

    據插入刪除修改也將會失敗。所以需要設置auto_incremental_incremental以及auto_incremental_offset

    用於設置每次自動增長的量,以及初次增長的基數。一般設置爲奇數偶數相對應,這樣就不會重合。

    

  主主服務器配置:

    主服務器1:IP 172.16.25.101

    /etc/my.cnf

    QQ截圖20180108143205.jpg

    設置爲奇數增長,針對於那些auto_increment的字段


    授權,指定master爲172.16.25.102

    QQ截圖20180108130717.jpg

    QQ截圖20180108143652.jpg

    

    主服務器2:IP 172.16.25.102

    /etc/my.cnf

    QQ截圖20180108143758.jpg

    

    授權,指定master爲172.16.25.101

    QQ截圖20180108143957.jpg

    QQ截圖20180108144110.jpg

   

   分別爲兩臺服務器開啓線程

   mysql>start slave;

  

   分別從兩臺服務器進行讀寫操作:

   主服務器1插入一條數據到classes中

    QQ截圖20180108144445.jpg

    因爲設置的是奇數增長所以由11增長到13

  

    到主服務器2進行查看,並插入一條數據:

    QQ截圖20180108144731.jpg

    由圖可知複製成功,再在主服務器2中插入一條數據,並在主服務器1中可見。

    主主複製成功!

   

 

  

   

   

     







   

   

   

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