MySQL基於gtid特性與xtrabackup的資料恢復
一、gtid特性介紹:
GTID(global transaction identifier)是MySQL 5.6的新特性,可以唯一的標識一個事務,由UUID+TID組成:
- UUID是MySQL例項的唯一標識
- TID是該例項上已提交的事務的數量
在主從複製中,GTID代替了classic的複製方法,不再使用binlog+pos開啟複製,而是使用master_auto_postion = 1的方式自動匹配GTID斷點進行復制。
要開啟GTID,只需在MySQL引數檔案中新增以下引數:
gtid-mode = ON
enforce_gtid_consistency = 1
二、資料恢復需求:
需要將MySQL(以下簡稱A庫)恢復到一天前的凌晨12:00左右的狀態
需要具備的前提條件如下:
- 開啟GTID
- 有A庫昨天凌晨12:00前的xtra備份檔案
- 開啟binlog日誌(廢話)
三、恢復操作:
在另一臺MySQL(B庫)上進行資料的恢復,這樣可以避免影響線上業務
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)設定@@global.gtid_purged跳過備份包含的GTID,並執行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有時不止一個,設定@@global.gtid_purged時指定多個即可,以逗號隔開。
四、在A庫binlog中找到恢復點並進行恢復
需要特別注意的是,在上述操作後,不要直接start slave,否則B庫也又會跑到當前A庫的狀態
將A庫binlog轉換為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並指定恢復到的位置:
mysql> start slave until SQL_BEFORE_GTIDS='542ef021-9a64-11e5-bc49-025d3d22c211:1348360';
Query OK, 0 rows affected (0.00 sec)
當執行到了指定的GTID,SQL執行緒便會停止,但IO執行緒還會繼續複製:
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)
好啦,想看昨天凌晨的哪些資料呀?都在B庫裡啦~~~
附:常見問題
在設定@@global.gtid_purged時,可能會遇到報錯:
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的@@GLOBAL.GTID_EXECUTED並不是空的,執行以下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)
相關推薦
MySQL基於gtid特性與xtrabackup的資料恢復
一、gtid特性介紹: GTID(global transaction identifier)是MySQL 5.6的新特性,可以唯一的標識一個事務,由UUID+TID組成: UUID是MySQL例項的唯一標識 TID是該例項上已提交的事務的數量 在主從
Mysql的增量備份 及基於時間點與位置的恢復
pre school 主從架構 http 二進制 全備 etc 復數 根據 增量備份的優點是沒有重復數據,備份量不大,時間短。缺點也很明顯,需要上次完全備份及完全備份之後所有的增量備份才能恢復,反推恢復,操作較為繁瑣。 Mysql沒有提供增量備份的方法,但是可以通過二進制日
MySQL增量備份恢復和基於時間點與位置的恢復
local 間接 恢復 efault posit 創建 val etc 節點 為什麽使用增量備份? 完全備份有兩種方式,一種是使用tar打包數據文件,另一種是使用mysqldump進行完全備份。完全備份存在的問題很容易看到,每次都是把所有的數據內容進行備份,備份數據中有大量
MySQL 基於時間點與位置恢復
開始 mark 文本 zhang map bin 完全 slave -o 基於時間點與位置恢復 利用二進制日誌可以實現基於時間與位置的恢復,例如由於誤操作刪除了一張表,這時候完全恢復是沒用的,因為日誌裏面還是存在錯誤語句,我們需要的是恢復到誤操作之前的狀態,然後跳過誤操作數
MySQL--------基於GTID半同步搭建主從
mysql gtid dba 1. 背景 * GTID: 全局事物ID(Global Transaction ID),在整個事務架構中每一個事務ID號是全局唯一的,不止是在一個節點上而是整個主從復制架構中每任何兩個事務的ID號都不會相同。 * GTID就是由當前節點的UUID(一個128位
MySQL 基於GTID復制
避免 連續 標識 logs 獲取 row ssi tran ike GTID Replication:在MySQL 5.6.5以上的版本中,MySQL新增了一種基於GTID的復制方式。通過 GTID 保證了每個在主數據庫上提交的事務在集群中有一個唯一的ID,這種方式強化了數
配置MYSQL基於GTID 主從復制詳細解析及步驟
spec sys tran allow ... ext mat mar 安裝 GTID的概念 全局事務標識:global transaction identifiers GTID是一個事務一一對應,並且全局唯一ID GTID在一個服務器上只執行一次,避免重復執行導致數據混
Percona XtraBackup 資料恢復工具安裝 ubuntu 16.04
來源: https://www.percona.com/doc/percona-xtrabackup/LATEST/installation/apt_repo.html Installing Percona XtraBackup on Debi
mysql儲存過程以及日誌和資料恢復
MySQL儲存過程 Mysql儲存過程是一組為了完成特定功能的SQL語句集,經過編譯之後儲存在資料庫中, 當需要使用該組SQL語句時使用者只需要通過指定儲存過程的名字並給定引數就可以呼叫執行它了 簡而言之就是一組已經寫好的命令,需要使用的時候拿出來用就可以了。 \d //(修改語句結
48、mysql基於GTID的主從複製實戰
MySQL 5.6引入的GTID(Global Transaction IDs)使得其複製功能的配置、監控及管理變得更加易於實現,且更加健壯。 要在MySQL 5.6中使用複製功能,其服務配置段[mysqld]中於少應該定義如下選項: binlog-format:二進位制日誌的格式,有row、st
ZT:mysql資料庫誤刪除後的資料恢復操作說明
在日常運維工作中,對於mysql資料庫的備份是至關重要的!資料庫對於網站的重要性使得我們對mysql資料的管理不容有失! 然後,是人總難免會犯錯誤,說不定哪天大腦短路了來個誤操作把資料庫給刪除了,怎麼辦??? 下面,就mysql資料庫誤刪除後的恢復方案進行說明。
MySQL-插入、更新與刪除資料
資料庫通過插入、更新和刪除等方式來改變表中的記錄。插入資料是向表中插入新的記錄,通過insert語句來實現。更新資料時改變表中已經存在的資料,使用update語句來實現。刪除資料是刪除表中不再使用的資料,通過delete語句來實現。 插入資料 插入資料是向表中插入新的記錄。
Mysql資料庫修復,Ibdata1檔案刪除資料恢復成功
Mysql資料庫Ibdata1檔案刪除資料恢復成功 【客戶描述】 一RAID1網站伺服器,存放Mysql資料庫目錄被惡意刪除,計算機重啟後,Mysql服務啟動後自動建立了Ibdata及系統庫,後又被刪除 【恢復過程】 因資料庫有以前的老備份,檢視備份發現數據庫
Mysql基於GTID搭建主從同步
版本 格式 數據不一致 產生 使用 eat love one set 一、GTID的概念 1、全局事務標識:global transaction identifiers。2、GTID是一個事務一一對應,並且全局唯一ID。3、一個GTID在一個服務器上只執行一次,避免重復執行
MySQL 資料庫增量備份與恢復資料命令實戰
1. 備份單個數據庫練習 mysqldump 命令多種引數的使用 1.1 調整 MySQL 客戶端及服務端字符集為建庫建表時預設的 latin1,避免備份時的亂碼問題 [[email protected] ~]# vi /etc/my.cnf [[email protected] ~
Mysql----資料備份與資料恢復
資料備份(mysqldump,在linux終端操作) 1)命令格式: mysqldump -u使用者名稱 -p 源庫名 > 路徑[
mysql 雙主配置 基於docker 測試 及資料恢復測試
基於docker 1.10.3 映象地址:https://hub.docker.com/_/mysql/ docker 相關的我就不介紹了,如果不是docker 也沒有關係,自己裝兩個mysql 命
基於Xtrabackup及可傳輸表空間實現多源資料恢復
開發十年,就只剩下這套架構體系了! >>>
基於GTID的MySQL多源復制配置
復制 多主一從 gtid 多源復制 多源復制的意義 1.可以在一個從庫上對多個服務器的數據庫進行匯總,或者對一個數據庫的分庫分表進行匯總。 2.集約使用從庫服務器的硬件資源,畢竟弱一個數據庫業務量較小確占用整個服務器資源是不經濟的。 3.更方便的對個業務庫進行數據備份,優化數據庫備
mysql之 MySQL 主從基於 GTID 復制原理概述
發送 重要 導致 ora 允許 減少 自動同步 一次 插入數據 一、 什麽是GTID ( Global transaction identifiers ):MySQL-5.6.2開始支持,MySQL-5.6.10後完善,GTID 分成兩部分,一部分是服務的UUid,UUID