MySQL基于gtid特性與xtrabackup的數(shù)據(jù)恢復(fù)

一埋凯、gtid特性介紹:

GTID(global transaction identifier)是MySQL 5.6的新特性,可以唯一的標(biāo)識一個(gè)事務(wù)惭蹂,由UUID+TID組成:

  • UUID是MySQL實(shí)例的唯一標(biāo)識
  • TID是該實(shí)例上已提交的事務(wù)的數(shù)量

在主從復(fù)制中槽地,GTID代替了classic的復(fù)制方法烧栋,不再使用binlog+pos開啟復(fù)制,而是使用master_auto_postion = 1的方式自動匹配GTID斷點(diǎn)進(jìn)行復(fù)制苇倡。

要開啟GTID富纸,只需在MySQL參數(shù)文件中添加以下參數(shù):

shellgtid-mode = ON
enforce_gtid_consistency = 1

二、數(shù)據(jù)恢復(fù)需求:

需要將MySQL(以下簡稱A庫)恢復(fù)到一天前的凌晨12:00左右的狀態(tài)
需要具備的前提條件如下:

  1. 開啟GTID
  2. 有A庫昨天凌晨12:00前的xtra備份文件
  3. 開啟binlog日志(廢話)

三旨椒、恢復(fù)操作:

在另一臺MySQL(B庫)上進(jìn)行數(shù)據(jù)的恢復(fù)晓褪,這樣可以避免影響線上業(yè)務(wù)

1. 將B庫data目錄移走,拷貝A庫備份文件到B庫:
mv data data_20160716                  #移走B庫data
mv A_back_20160714 data                #移入A庫備份文件
chown -R mysql12300.mysql data/
2. 開啟B庫综慎,配置主從查看data目錄下xtrabackup_binlog_info文件中記錄的GTID:
[root@service-test1 data]$ cat xtrabackup_binlog_info 
mysql-bin.000012    46455554    8133046e-4282-11e6-848e-026ca51d284c:1-4920155

在B庫(slave)設(shè)置@@global.gtid_purged跳過備份包含的GTID涣仿,并執(zhí)行change master to指定A庫為主庫:

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";
Query OK, 0 rows affected (0.00 sec)
mysql> change master to Master_Host ='10.11.21.14',Master_Port=3306,Master_User='replica',Master_Password='XXXXXXXXX',MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

注意: xtrabackup_binlog_info中的GTID有時(shí)不止一個(gè),設(shè)置@@global.gtid_purged時(shí)指定多個(gè)即可示惊,以逗號隔開好港。

四、在A庫binlog中找到恢復(fù)點(diǎn)并進(jìn)行恢復(fù)

需要特別注意的是米罚,在上述操作后钧汹,不要直接start slave,否則B庫也又會跑到當(dāng)前A庫的狀態(tài)

將A庫binlog轉(zhuǎn)換為sql語句:

mysqlbinlog -vv mysql-bin.000011 > mysql-bin.000011.sql

找到前一天凌晨12:00左右的位置并記錄GTID:

# at 561467475
#160521 0:24:31 server id 212177500 end_log_pos 561467523 CRC32 0x216072ca GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '542ef021-9a64-11e5-bc49-025d3d22c211:1348360'/*!*/;

在B庫開啟slave并指定恢復(fù)到的位置:

mysql> start slave until SQL_BEFORE_GTIDS='542ef021-9a64-11e5-bc49-025d3d22c211:1348360';
Query OK, 0 rows affected (0.00 sec)

當(dāng)執(zhí)行到了指定的GTID阔拳,SQL線程便會停止崭孤,但I(xiàn)O線程還會繼續(xù)復(fù)制:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.30.21.11
                  Master_User: replica
                  Master_Port: 7500
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000011
          Read_Master_Log_Pos: 810203081
               Relay_Log_File: relay-bin.000002
                Relay_Log_Pos: 5707357
        Relay_Master_Log_File: mysql-bin.000011
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 561467475
              Relay_Log_Space: 254443161
              Until_Condition: SQL_BEFORE_GTIDS
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 21117500
                  Master_UUID: 63f38fe7-9e3b-11e5-9554-02eeb2c1042f
             Master_Info_File: /data1/mysql10070/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 542ef021-9a64-11e5-bc49-025d3d22c211:1341313-1368005
            Executed_Gtid_Set: 44226252-9e38-11e5-9540-02212401d46f:1,
542ef021-9a64-11e5-bc49-025d3d22c211:1-1348359,
63f38fe7-9e3b-11e5-9554-02eeb2c1042f:1
                Auto_Position: 1
1 row in set (0.00 sec) 

好啦,想看昨天凌晨的哪些數(shù)據(jù)呀糊肠?都在B庫里啦~~~

附:常見問題

在設(shè)置@@global.gtid_purged時(shí)辨宠,可能會遇到報(bào)錯(cuò):

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

這是因?yàn)檫@臺MySQL的@@GLOBAL.GTID_EXECUTED并不是空的,執(zhí)行以下reset master操作就好了:

mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000002 |      191 |              |                  | 3857c25c-2caa-11e6-b61b-021feddc3827:1-14 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
mysql> reset master;
Query OK, 0 rows affected (0.01 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      151 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)  
mysql> SET GLOBAL gtid_purged="8133046e-4282-11e6-848e-026ca51d284c:1-4920155";
Query OK, 0 rows affected (0.00 sec)
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末货裹,一起剝皮案震驚了整個(gè)濱河市嗤形,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌弧圆,老刑警劉巖赋兵,帶你破解...
    沈念sama閱讀 217,509評論 6 504
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異搔预,居然都是意外死亡霹期,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,806評論 3 394
  • 文/潘曉璐 我一進(jìn)店門拯田,熙熙樓的掌柜王于貴愁眉苦臉地迎上來历造,“玉大人,你說我怎么就攤上這事】圆” “怎么了侣监?”我有些...
    開封第一講書人閱讀 163,875評論 0 354
  • 文/不壞的土叔 我叫張陵,是天一觀的道長臣淤。 經(jīng)常有香客問我橄霉,道長,這世上最難降的妖魔是什么邑蒋? 我笑而不...
    開封第一講書人閱讀 58,441評論 1 293
  • 正文 為了忘掉前任姓蜂,我火速辦了婚禮,結(jié)果婚禮上医吊,老公的妹妹穿的比我還像新娘覆糟。我一直安慰自己,他們只是感情好遮咖,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,488評論 6 392
  • 文/花漫 我一把揭開白布滩字。 她就那樣靜靜地躺著,像睡著了一般御吞。 火紅的嫁衣襯著肌膚如雪麦箍。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,365評論 1 302
  • 那天陶珠,我揣著相機(jī)與錄音挟裂,去河邊找鬼。 笑死揍诽,一個(gè)胖子當(dāng)著我的面吹牛诀蓉,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播暑脆,決...
    沈念sama閱讀 40,190評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼渠啤,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了添吗?” 一聲冷哼從身側(cè)響起沥曹,我...
    開封第一講書人閱讀 39,062評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎碟联,沒想到半個(gè)月后妓美,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,500評論 1 314
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡鲤孵,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,706評論 3 335
  • 正文 我和宋清朗相戀三年壶栋,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片普监。...
    茶點(diǎn)故事閱讀 39,834評論 1 347
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡贵试,死狀恐怖丧没,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情锡移,我是刑警寧澤,帶...
    沈念sama閱讀 35,559評論 5 345
  • 正文 年R本政府宣布漆际,位于F島的核電站淆珊,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏奸汇。R本人自食惡果不足惜施符,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,167評論 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望擂找。 院中可真熱鬧戳吝,春花似錦、人聲如沸贯涎。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,779評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽塘雳。三九已至陆盘,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間败明,已是汗流浹背隘马。 一陣腳步聲響...
    開封第一講書人閱讀 32,912評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留妻顶,地道東北人酸员。 一個(gè)月前我還...
    沈念sama閱讀 47,958評論 2 370
  • 正文 我出身青樓,卻偏偏與公主長得像讳嘱,于是被迫代替她去往敵國和親幔嗦。 傳聞我的和親對象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,779評論 2 354

推薦閱讀更多精彩內(nèi)容