Mysql數據庫的備份和恢復

MySQL數據庫的備份和恢復

備份和恢復（數據）

備份：
        存儲的數據副本
        原始數據持續改變
    恢復：
        把副本應用到線上系統
        僅能恢復至備份操做時刻的數據狀態
    時間點恢復：
        binary logs
    爲何備份？
        災難恢復：硬件故障（冗餘）、軟件故障（bug）、天然災害、黑客攻擊、誤操做、測試

備份時應該注意事項

能容忍最多丟失多少數據；
        恢復數據須要在多長時間內完成；
        須要恢復哪些數據；
        作恢復演練：
            測試備份的可用性；
            加強恢復操做效率；

備份須要考慮因素

鎖定資源多長時間？
        備份過程的時長？
        備份時的服務器負載？
        恢復過程的時長？

備份什麼？

數據
        二進制日誌、innodb的事務日誌；
        代碼（存儲過程、存儲函數、觸發器、事件調度器）
        服務器的配置文件

備份的分類

1）從物理與邏輯的角度，備份能夠分爲物理備份和邏輯備份。
        1》物理備份：對數據庫操做系統的物理文件（如數據文件、日誌文件等）的備份。物理備份又可分爲脫機備份（冷備份）和聯機備份（熱備份）。
        2》邏輯備份：對數據庫邏輯組件（如表等數據庫對象）的備份，也就是從數據庫導出數據另存在一個或多個文件中。
    2）從數據庫的備份策略角度，備份可分爲徹底備份、差別備份和增量備份。
        1》徹底備份：
            每次對數據進行完整的備份
            對整個數據庫的備份、數據庫結構和文件結構的備份。保存的是備份完整時刻的數據庫，是差別備份與增量備份的基礎。
            優勢：備份與恢復操做簡單方便
            缺點：數據存在大量的重複，佔用大量的空間，備份與恢復時間長
        2》差別備份：
            僅備份自上一次徹底備份以來變化的那部數據
            備份的時間節點是從上次完整備份起，備份數據量會愈來愈大。
            恢復數據時，只需恢復上次的徹底備份與最近的一次差別備份。
        3》增量備份：
            僅備份自上一次徹底備份或增量備份以來變化的那部數據
            以上次備份或上次的增量備份的時間爲時間點，僅備份這之間的完整備份起到最後一次增量備份依次恢復，如中間某次的備份數據損壞，將致使數據的丟失。
    3）按備份的數據集的範圍：
        徹底備份和部分備份
            徹底備份：整個數據集；
            部分備份：數據集的一部分，好比部分表；
    4）根據數據服務是否在線
        冷備份：
            是在關閉數據庫的時候進行的。
        熱備份：
            數據庫處於運行狀態時進行的，這種備份方法依賴於數據庫的日誌文件。
            讀寫操做都可進行的狀態下所作的備份，MyISAM不支持熱備，InnoDB支持熱備。
        溫備份：
            數據庫鎖定表格（不可寫但可讀）的狀態下進行的。

備份策略

全量+差量 + binlogs
    全量+增量 + binlogs
    備份策略機制：
        xtrabackup：
            全量+差別+binlog
            全量+增量+binlog
        mysqldump：
            全量+binlog
            邏輯備份工具，基於mysql客戶端協議
            徹底備份、部分備份；
                innodb：熱備或溫備；
                myisam：溫備；
            二次封裝工具：
                mydumper
                phpmyadmin

一致性

數據的一致性
        一般指關聯數據之間的邏輯關係是否正確和完整。
    數據庫的一致性
        一般指數據庫從一個一致性狀態變成另外一個一致性狀態
    保持數據的一致性
        1》備份開始時對全部表加鎖，在備份結束以前不能修改數據庫，這樣作保持數據不變且一直處於同一個一致狀態中，明顯的缺點就是不能對數據庫進行寫操做。
        2》在備份開始是對全部數據進行一個快照，快照記錄的是開始備份那一刻全部數據的樣子，因此在快照範圍內的讀取的數據具備一致性。
            備份時保證全部備份操做放在一個事務中，且將事務隔離級別設爲「可重讀」，備份只是讀取操做而沒有更新操做因此不會出現「幻讀」，因此數據對某個時間點來講就是一致的。
            注：當事務處於可重讀隔離級別時，並不意味着此時快照已經創建，而是當事務中第一查詢語句執行時，快照纔會創建。mysql爲咱們提供了個能夠啓動可重讀事務的語句：start transaction with consistent snapshot

備份工具1：mysqldump（重要）

1）介紹：
        mysqldump 是採用SQL級別的備份機制，它將數據表導成 SQL 腳本文件，在不一樣的 MySQL 版本之間升級時相對比較合適也是最經常使用的備份方法。
        mysqldump是mysql服務自帶的邏輯備份工具，能實現徹底和部分備份，不支持增量備份。
        mysqldump針對innodb類型的能夠熱備，針對myisam類型的能夠溫備：
    2）備份原理：
        經過協議鏈接到mysql數據庫，將須要備份的數據查詢出來並轉換成對應的insert語句。
        當咱們須要還原這些數據時，就只需執行這些insert語句，就可將對應的數據還原。
    3）優勢：
        可直接使用文本處理工具對備份數據進行處理。
    4）缺點：
        由於其過程是讀取-轉換-插入，沒有索引等信息，因此還原後須要重建索引。
        當數據爲浮點型時，會出現精度問題。
        備份過程爲串行化，不能並行備份，因此速度慢，不適合數據量大時使用。
    5）進行備份：
        mysqldump [OPTIONS] database [tables] > /PATH/TO/BACKUP/NAME-DATE.sql                                              # 備份單庫，能夠只備份其中的一部分表（部分備份）；
        mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]  > /PATH/TO/BACKUP/NAME-DATE.sql         # 備份多庫；
        mysqldump [OPTIONS] --all-databases [OPTIONS]  > /PATH/TO/BACKUP/NAME-DATE.sql                              # 備份全部庫；
        將全量備份後，發生數據更改的二進制日誌重定向到一個文件中
            mysqlbinlog -j 245 bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
        
    6）選項：
        myisam存儲引擎：
            支持溫備，備份時要鎖定表；
            -x, --lock-all-tables：鎖定全部庫的全部表，讀鎖；
            -l, --lock-tables：鎖定指定庫全部表；
        innodb存儲引擎：
            支持溫備和基於事務進行熱備；
            --single-transaction：建立一個事務，基於此快照執行熱備份；
            解釋：
                使用上述選項後，mysqldump會自動將備份會話中的事務隔離級別設爲可重讀，並開啓一個事務，且事務開啓那一刻建立了快照，來保證一致性。
                若是開啓二進制日誌，也定要設置--master-data選項。
    7）其它，若無特殊狀況，如下都須要一併添加：
            -r, --routines：備份指定庫的存儲過程和存儲函數；
            --triggers：備份指定庫的觸發器；
            -e, --events：事件表會被備份；
             --master-data[=#]：是否添加二進制日誌文件到輸出
                非0狀況下都記錄對應二進制日誌文件位置
                1：記錄爲change master to語句，此語句不被註釋；
                2：記錄爲change master to語句，此語句被註釋，方便恢復時進行時間點的恢復；
            --flush-logs：鎖定表完成後，即進行日誌刷新操做；
            
    8）備份思路：
        1>按期實施備份，指定備份計劃或策略，並嚴格遵照
        2>除了徹底備份，開啓msyql服務器的日誌功能也是很重要的（徹底備份加上日誌，能夠對mysql進行最大化壓力）
        3>使用統一和容易理解的備份名稱，推薦使用庫名或表名加上命令規則
    
    9）備份數據的恢復
        1>登陸數據庫進行恢復
            1》使用管理員登陸mysql
            2》關閉當前會話的二進制日誌記錄
                set sql_log_bin=off;
                緣由：
                    由於備份文件的格式就是些insert的語句，因此恢復數據時會執行大量的insert操做，這些操做會被記錄到二進制日誌中，因此爲避免大量日誌記錄就需關閉二進制日誌記錄。但記得恢復完後再次開啓。
            3》執行source 備份的sql腳本路徑
                mysql>source /PATH/TO/BACKUP/NAME.sql
            4》時間點恢復
                備份時所在時間點以後的數據恢復就須要經過二進制日誌來進行。
                1——從二進制日誌中提取時間點以後對應的sql語句。開啓位置爲備份時刻的位置，結束位置差很少爲進行數據庫恢復時刻的位置，特別要注意語句的特性。
                2——對提取的sql語句進行操做。
                mysql>soure BINLOG.sql
                or 
                mysql -uroot -p< BINLOG.sql
        2>不登陸進行恢復，通常用於腳本
            1》關閉二進制日誌記錄
            2》執行sql腳本恢復
                mysql -u用戶名 -p[密碼] < 庫備份腳本的路徑
                mysql -u用戶名 -p[密碼] 庫名 < 表備份腳本的路徑
        示例：
            1》備份myisam表
                mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --extended-insert=false --triggers -R --hex-blob -x db_name > db_name.sql
            2》備份innodb表
                mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --extended-insert=false --triggers -R --hex-blob --single-transaction db_name > db_name.sql
            3》若是想要實如今線備份，還可使用 --master-data 參數來實現
                mysqldump -uuser_name -ppassword --default-character-set=utf8 --opt --master-data=1 --single-transaction --flush-logs db_name > db_name.sql
                    它只是在一開始的瞬間請求鎖表，而後就刷新binlog了，然後在導出的文件中加入change master 語句來指定當前備份的binlog位置，若是要把這個文件恢復到slave裏去，就能夠採用這種方法來作。
                    注意：–extended-insert 須要根據實際狀況決定是否啓用或關閉 ，會對數據恢復速度產生較大影響。
            4》使用mysql客戶端來還原
                mysql -uuser_name -ppassword  db_name < db_name.sql
            5》用source語法來還原，這個也是mysql客戶端提供的功能
                SOURCE /tmp/db_name.sql;
                這裏須要指定文件的絕對路徑，而且必須是 mysqld 運行用戶(例如 nobody)有權限讀取的文件。

備份工具2：xtrabackup（重要）

1）介紹
        xtrabackup由percona提供，是個開源的物理備份工具。
        xtrabackup支持對innodb進行熱備，全量備份、增量備份和差量備份。
        xtrabackup支持對myisam進行溫備，全量備份，備份myisqm表時會提早添加讀鎖。
        xtrabackup和mysqldump同樣都須要經過協議鏈接到mysql服務器，都是客戶端工具，鏈接以後讀取並複製innodb底層的」數據塊」，完成「物理備份」。
    2）備份原理
        1》物理備份的原理
            innodb存儲引擎的邏輯單元從大到小分別是：
                tablespace（表空間），segment（段），extent（區），page（頁），row（行）
            每一個大的邏輯單元包含N個小的邏輯單元。
            數據存於row中，row存於page中，備份時就是讀取page並進行備份的。
        2》增量備份的原理
            每一個page都有本身的LSN號碼，LSN是一個全局遞增的號碼。當每次對page中的記錄進行修改時，都會在page中記錄本次有LSN，且這個號碼會愈來愈大。
            xtrabackup就是經過LSN來實現對innodb表進行增量備份的。每次備份開始時，會記錄下當前備份到的LSN，當下線進行增量備份時，就會備份大於上次記錄的LSN的page。
            備份中的LSN大於當前page中的，說明這個page自從上次備份夠後沒有進行修改，反之，則就是進行了修改。
        3》備份恢復整個過程
            xtrabackup備份開始時，會同時進行兩個線程。
                一個是負責備份innodb中的page，另個是負責備份innodb的事務日誌（redo log）。
                那麼備份結束後會獲得兩份文件，一份是不可用的備份文件，一份是事務日誌。
            page的備份就是物理備份和增量備份，之因此被認爲不可用，是由於有一部分不肯定的數據是可能存在與事務日誌中的，且熱備過程當中數據也是可能會發生變化的，而事務備份就是這部分不肯定數據的的備份。
                因此咱們恢復過程當中須要經過這兩個文件製做成一份可用的備份，而這個製做過程也就是「prepare」，爲恢復工做作準備。
            備份開始時，有些事務已經存在於事務日誌中，這些日誌可能已經提交但尚未同步到數據文件中，那麼這部分事務日誌就須要在prepare過程當中就須要replayed（重放）。
                而有些事務可能還未提交，這部分未提交的就須要在prepare過程當中roolback（回滾）。
            在有增量備份的狀況下進行preparee恢復準備，是須要把全部增量都合併到以前的全量上，而這時只須要將已經提交的事務同步到數據文件便可，未提交的事務就不一樣進行回滾了。
                這是由於增量備份時，這些事務可能已經提交了，只須要在最後一份增量上對未提交的事務回滾。
            再進行細分些，xtrabackup對innodb類的是作熱備，對myisam類的作溫備。
                溫備過程是須要對錶添加讀鎖的，因此溫備的表數據是一致的，而在實際中數據庫每每是兩個類型都存在的，因此備份過程當中是以myisam的一致性時間點做爲最終備份的一致性時間點的。
                這樣咱們就能想到，在備份時是先備份innodb存儲引擎的數據，以後再進行備份其餘包括myisam存儲引擎的數據。
                而在備份恢復時的prepare過程當中，就只操做innodb類的數據便可，prepare完成後，全部數據的一致性時間點是相同的。
    3）xtrabackup的版本和安裝
        xtrabackup的2.3版本前是有兩個主要備份工具xtrabackup（C程序）和innobackupex（perl腳本）。
        xtrabackup只能備份innodb和xtradb的表，而innobackupex均可以進行備份，但兩個運行是會致使bug。
        xtrabackup的2.3版本及其以後仍是兩個工具但都是C程序，做用還和之前同樣，因此通常使用innobackupex命令進行備份。
        可能在2.4版本後只保留xtrabackup。
        安裝時，須要從官方下載，有源碼和rpm包，會依賴到不少包，因此提早配置好yum的base和epel源倉庫。
        https://www.percona.com/downloads/XtraBackup/LATEST/
            percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm
    4）xtrabackup全量備份和恢復
        備份：
            innobackupex --default-file=/PATH/TO/DEFAULT --host=ID ADDR --user=USER_NAME -P PASSWORD /PATH/TO/BACKUP
                --default-file：指定備份時，從那個配置文件中讀取配置信息。默認是使用的mariadb-libs的/etc/my.cnf，此時能夠不寫
                --host：指定數據庫服務ip地址。默認爲localhost，此時可不寫
                --user：指定鏈接數據庫服務的用戶。默認爲root，此時可不寫
                -p：指定用戶密碼，登陸mysql時用的密碼
                /PATH/TO/BACKUP：備份文件存放目錄
                注意：
                    completed OK！字樣，有它才說明備份成功，innobackupex會把備份過程完整輸出到屏幕。
            binlog備份，全量備份或機器毀壞後的操做備份，時間點備份
                mysqlbinlog -j 245(N) bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
        備份後的目錄文件
            在你所指定的備份目錄下能夠找到以當前時間命令的備份文件
                [root@localhost backup]#ls
                2017-11-18_19-39-17
                [root@localhost backup]#ll 2017-11-18_19-39-17/
                total 18460
                -rw-r----- 1 root root      417 Nov 18 19:39 backup-my.cnf
                -rw-r----- 1 root root 18874368 Nov 18 19:39 ibdata1
                drwxr-x--- 2 root root     4096 Nov 18 19:39 mysql/
                drwxr-x--- 2 root root     4096 Nov 18 19:39 performance_schema/
                drwxr-x--- 2 root root       78 Nov 18 19:39 Syslog/
                -rw-r----- 1 root root       19 Nov 18 19:39 xtrabackup_binlog_info
                -rw-r----- 1 root root      113 Nov 18 19:39 xtrabackup_checkpoints
                -rw-r----- 1 root root      448 Nov 18 19:39 xtrabackup_info
                -rw-r----- 1 root root     2560 Nov 18 19:39 xtrabackup_logfile
            文件介紹
                backup-my.cnf：
                    此文件中包含my.cnf中的設置信息，只包含了備份時須要的信息。
                ibdata1：
                    這是個innodb的共享表空間文件
                xtrabackup_binlog_info:
                    此文件記錄了備份開始時二進制日誌文件的位置（position）
                xtrabackup_checkpoints:
                    此文件記錄這次備份屬於那種類型的備份等信息
                xtrabackup_info:
                    此文件記錄了備份的概要信息
                xtrabackup_logfile
                    此文件記錄了備份過程當中的日誌，在對數據進行prepare時須要經過日誌將數據還原成一致的可用備份數據
            查看備份狀況
                cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints 
                backup_type = full-backuped
                from_lsn = 0
                to_lsn = 1947282
                last_lsn = 1947282
                compact = 0
                recover_binlog_info = 0
        恢復：
            在須要還原的服務器上安裝xtrabackup。
            把備份的整個目錄拷貝到須要還原的服務器上。
            兩個服務器上的mysql版本須要相同（不相同的沒試過）
            prepare：
                innobackupex --apply-log /PATH/TO/BACKUP/dir-quan
                --apply-log：將目錄中的日誌應用到備份數據中
                --use-memory=N：默認爲100M，若備份數據量大且有足夠的空閒內存時，能夠用來指定大小的內存來工做，單位可使用G,M....。
                注意：
                    completed OK！字樣
            開始恢復：
                確保服務中止
                    systemctl stop  mariadb
                數據目錄必須爲空目錄
                    rm -rf  /PATH/TO/DATADIR/*
                        數據目錄通常爲/var/lib/mysql/
                恢復
                    innobackupex --datadir=/PATH/TO/DATADIR/ --copy-back  /PATH/TO/BACKUP/dir-quan
                修改權限
                    chown -R mysql:  /PATH/TO/DATADIR/ 
                啓動服務
                    systemctl start mariadb
                注意：
                    實際還原時，最好將對應的配置文件也都還原，也就是把原服務器上的配置拷貝下，確保配置仍是原來的。
                    上述恢復並無進行時間點的還原，實際工做中，須要進行。
                時間點恢復，binlog恢復
                    mysql>soure BINLOG.sql
                    or 
                    mysql -uroot -p< BINLOG.sql
    5）xtrabackup增（差）量備份及恢復
            全量備份是差量備份與增量備份的基礎。
            差量備份只能針對上一次全量備份。
            增量備份能夠針對上一次任務一種備份。
            通俗地來講：全部增量備份加到一塊兒就是差量備份了。
            增量和差量備份都是針對innodb表來講的，對myisam表來講即便執行了增量備份，其實也是全量備份。
            注意：如下常說成增量，你們注意增量和差量間的區別就行。
        增（差）量備份：
            innobackupex -pPASSWORD --incremental /PATH/TO/BACKUP --incremental-basedir=/PATH/TO/BACKUP/last-backup-file
            --incremental /PATH/TO/BACKUP：表示本次備份是一個增量備份（若針對的上次備份爲一個全量備份，這裏也能夠認爲是個差量備份）
            --incremental-basedir=/PATH/TO/BACKUP/last-backup-file：指定本次增量備份針對的是那個備份（能夠是上個增量，也能夠是上個全量）
            
            binlog備份，增量備份或機器毀壞後的操做備份，時間點備份
                mysqlbinlog -j 245 bin-log.xxxxxxxx > /PATH/TO/BINLOG.sql
        查看備份狀況
            cat /backup/2017-11-20_03-43-15/xtrabackup_checkpoints 
            backup_type = incremental
            from_lsn = 1947282
            to_lsn = 2073366
            last_lsn = 2073366
            compact = 0
            recover_binlog_info = 0
            cat /backup/2017-11-20_03-51-32/xtrabackup_checkpoints 
            backup_type = incremental
            from_lsn = 2073366
            to_lsn = 2084330
            last_lsn = 2084330
            compact = 0
            recover_binlog_info = 0
        恢復：
            在須要還原的服務器上安裝xtrabackup。
            把備份的整個目錄拷貝到須要還原的服務器上。
            兩個服務器上的mysql版本須要相同。
            prepare：
                對全量備份作準備工做
                    innobackupex --apply-log --redo-only  /PATH/TO/BACKUP/dir-quan
                    --redo-only：表示進行準備（應用日誌）工做時，只進行redo操做，只會重作已提交但未應用的事務，不會回滾未提交的事務。緣由是後面還有個增量備份，未提交的可能在後面增量備份時進行提交。
                對增（差）量備份作準備工做
                    innobackupex --apply-log [--redo-only] /PATH/TO/BACKUP/dir-quan --incremental-dir= /PATH/TO/BACKUP/dir-zeng
                    --redo-only：若只有一個增量備份或是最後那個增量備份文件，那麼不須要這個選項，緣由同上。也就是說這個選項不能用於最後一個增量備份進行prepare。
                    --incremental-dir=：此選項對應的目錄爲增量備份文件的目錄
                查看prepare狀況
                    若不是對最後一個增量備份進行prepare，那麼查看全量備份文件中的xtrabackup_checkpoints，可看到log-applied，LSN有所變化，能夠和增量備份對比下。
                        cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints 
                        backup_type = log-applied
                        from_lsn = 0
                        to_lsn = 2073366
                        last_lsn = 2073366
                        compact = 0
                        recover_binlog_info = 0
                    如果以及對最後一個增量備份進行了prepare，那麼查看全量備份文件中的xtrabackup_checkpoints，可看到full-prepared，LSN有所變化
                        cat /backup/2017-11-18_19-39-17/xtrabackup_checkpoints 
                        backup_type = full-prepared
                        from_lsn = 0
                        to_lsn = 2084330
                        last_lsn = 2084330
                        compact = 0
                        recover_binlog_info = 0
                注意：
                    prepared中可使用--user-memory=選項來加快速度，前提是你有空閒的內存可用。
                    --redo-only這個選項須要多加註意，它不能用於最後那個增量備份的prepared，且必須用於其餘增量備份的prepared。緣由是後面還有增量備份的，未提交的可能在後面增量備份時進行提交。
            開始恢復：
                確保服務中止
                    systemctl stop  mariadb
                數據目錄必須爲空目錄
                    rm -rf  /PATH/TO/DATADIR/*
                        數據目錄通常爲/var/lib/mysql/
                恢復
                    innobackupex --datadir=/PATH/TO/DATADIR/ --copy-back  /PATH/TO/BACKUP/dir-quan
                修改權限
                    chown -R mysql:  /PATH/TO/DATADIR/ 
                啓動服務並查看是否恢復
                    systemctl start mariadb
                注意：
                    實際還原時，最好將對應的配置文件也都還原，也就是把原服務器上的配置拷貝下，確保配置仍是原來的。
                    上述恢復並無進行時間點的還原，實際工做中，須要進行。
                時間點恢復，binlog恢復
                    mysql>soure BINLOG.sql
                    or 
                    mysql -uroot -p< BINLOG.sql

其餘備份工具

1）mysqlhotcopy：幾乎冷備
        它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 來快速備份數據庫。它是備份數據庫或單個表的最快的途徑，但它只能運行在數據庫文件（包括數據表定義文件、數據文件、索引文件）所在的機器上。mysqlhotcopy 只能用於備份 MyISAM，而且只能運行在類Unix 和 NetWare 系統上。
        1》mysqlhotcopy 支持一次性拷貝多個數據庫，同時還支持正則表達。
            示例：
            mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name /tmp (把數據庫目錄 db_name 拷貝到 /tmp 下)
            mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name_1 ... db_name_n /tmp
            mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name./regex/ /tmp
            注意，想要使用 mysqlhotcopy，必需要有 SELECT、RELOAD(要執行 FLUSH TABLES) 權限，而且還必需要可以有讀取 datadir/db_name 目錄的權限。
        2》mysqlhotcopy 備份出來的是整個數據庫目錄，使用時能夠直接拷貝到 mysqld 指定的 datadir 目錄下便可，同時要注意權限的問題。
            示例：
            cp -rf db_name /usr/local/mysql/data/
            chown -R nobody:nobody /usr/local/mysql/data/ (將 db_name 目錄的屬主改爲 mysqld 運行用戶)
            
    2）select語句：
        備份：select cluase into outfile 'filename';
        恢復：create table 
        導入：load data 
    3）cp和tar
        直接打包數據庫文件，如.../mysql/data或/var/lib/mysql
            備份
                tar -Jcf mysql_all-$(date +%F).tar.xz  /須要備份文件的路徑/需備份的文件 
            模擬數據丟失
                mv /var/lib/mysql/* /bak
            數據恢復
                cd /var/lib/mysql
                tar -xf mysql_all-???.tar.xz
        
    4）基於lvm2的備份：
        快照（請求一個全局鎖），以後當即釋放鎖，達到幾乎熱備的效果，物理備份；
        注意：不能僅備份數據文件，要同時備份事務日誌。
        前提：要求數據文件和事務日誌位於同一個邏輯卷。
        前提：要求數據文件和事務日誌位於同一個邏輯卷；
        (1）請求鎖定全部表；
            mysql> flush tables with read lock;
        (2) 記錄二進制文件事件位置；
            mysql> flush logs;
            mysql> show master status;
            mysql  -e  'show master status;' >> /path/to/some_pos_file
        (3) 建立快照卷
            lvcreate  -l # -s -p r - snam-name /dev/vg-name/lv-name 
        (4) 釋放鎖
            mysql> unlock tables
        (5) 掛載快照卷，並執行備份，備份完成後刪除快照卷；
        (6) 週期性備份二進制日誌；

binlog

mysql的binlog間接實現增量備份
    1）msyql增量備份概念
        使用mysqldump進行徹底備份，備份的數據中有重複數據，備份時間與恢復時間長。
        而增量備份就是備份自上次備份以後增長或改變的文件或內容。
        mysql沒有提供直接的備份方法，能夠經過mysql提供的二進制日誌（binary logs）間接實現增量備份。
        二進制日誌保存了全部更新或者可能更新數據庫的操做。
        增量備份的特色：
            沒有重複數據，備分量不大，時間短
            恢復麻煩，須要上次徹底備份及徹底備份以後全部的增量備份才能恢復，並且要對全部增量備份進行反推恢復。
    2）mysql增量備份的實現
        二進制日誌在啓動mysql服務器後開始記錄，並在文件達到max_binlog_size所設置的大小或者接收到flush logs命令後從新建立新的日誌文件。
        因此只需定時執行flush logs方法從新建立新的日誌，生成二進制文件序列，並及時把這些日誌保存到安全的地方就完成了一個時間段的增量備份。
            cat /etc/my.cnf |grep max_binlog_size
        要進行mysql增量備份，首先就是要確保開啓二進制日誌功能。
        1》在mysql主配置文件my.cnf中[mysqld]項中加入log-bin=/文件存放路徑/文件前綴，如log-bin=mysql-bin，而後重啓mysql的服務。實際上默認此配置存在。
                [mysqld]
                log-bin=mysql-bin ##最好寫絕對路徑
        2》使用mysqld --login-bin=/文件存放路徑/文件前綴，重啓mysql的服務，每週選擇服務器負載較輕的時間段，或者用法訪問較少的時間段進行備份。
    3）mysql增量備份恢復
        1》應用場景
            人爲的sql語句破壞了數據庫，在進行下一次全備以前發生系統故障致使數據庫數據丟失，在主從架構中，主庫數據發生了故障。
        2》增量恢復的方法
            1>通常的恢復：
                備份的二進制日誌所有恢復
                mysqlbinlog [--no-defaults] 二進制日誌文件
            2>基於時間點的恢復：
                便於跳過某個發生錯誤的時間點實現數據恢復
                從日誌開頭截至到某個時間點的恢復：
                    mysqlbinlog [--no-defaults] --stop-datetime='年-月-日 小時：分鐘：秒' 二進制日誌
                從某個時間點到日誌結尾的恢復：
                    mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小時：分鐘：秒' 二進制日誌
                從某個時間點到某個時間點的恢復：
                    mysqlbinlog [--no-defaults] --start-datetime='年-月-日 小時：分鐘：秒' 二進制日誌  --stop-datetime='年-月-日 小時：分鐘：秒' 二進制日誌
            3>基於位置的恢復：
                可能在同一時間點既有錯誤的操做也有正確的操做，基於位置進行恢復更加精準。
                mysqlbinlog --stop-position='操做 id' 二進制日誌 
                mysqlbinlog --stop-position='操做 id' 二進制日誌