基于GTID的復制

Ⅰ、GTID的介紹

  • global transaction id identifier 全局事務id
  • gtid = server_uuid + transaction_id
  • server_uuid是全局唯一的,5.6開始才有,表示當前實例的uuid,保存在數據目錄中的auto.conf文件中
  • transaction_id是自增的
  • gtid的作用是替代filename + position

主:show master status;

(root@localhost) [test]> show master status;
+------------+----------+--------------+------------------+----------------------------------------+
| File       | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                      |
+------------+----------+--------------+------------------+----------------------------------------+
| bin.000006 |      408 |              |                  | d565cde8-0573-11e8-89b2-525400a4dac1:1 |
+------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)
Executed_Gtid_set:server_id:1-xxxx     表示產生了xxx個事務

從:show master status;
Retrieved_Gtid_Set: d565cde8-0573-11e8-89b2-525400a4dac1:1
Executed_Gtid_Set: d565cde8-0573-11e8-89b2-525400a4dac1:1
也能看到事務號

tips:
如果做了A和B做了雙主,B上一直在同步A上數據,這時候在B上寫入一個事務

A上看下Executed_Gtid_set,會發現有兩個值

一個是自己做主當前的事務號,一個是同步的從上的事務號

Ⅱ、GTID的意義

之前的復制基于(file,pos),當主從發生宕機,切換的時候有問題

slave保存的是原master上的(file,pos),無法直接指向新master上的(file,pos)

mha通過relay log來判斷(非常有技術性)

gtid實現了真正的全局唯一位置(所有機器上都是統一的)

更容易進行failover操作

舉例:

a是master,b c d是slave,a掛了,b做主,c d做change master

此時c d 上的pos卻還是a上面的pos,和b沒有對應關系,文件名,文件大小,position完全不一樣,change不起來

使用gtid的話,b上保存著c和d回放的位置G_a、G_b(b是通過選舉出來的,保存著最多的日志)

Ⅲ、gtid配置

[mysqld]
log_bin
gtid_mode = ON
log_slave_updates = 1          5.6必須開,5.7可以不開
enforce-gtid-consistency = 1

tips:

  • MySQL5.6必須開啟參數log_slave_updates,5.7.6開始無需配置
  • MySQL5.6升級到gtid模式需要停機重啟
  • MySQL5.7.6版本開始可以在線升級gtid模式
  • 5.6中gtid用的比較少,最重要的原因在于gtid要么開要么不開,不能做到非gtid升級到gtid
  • gtid是一切高可用基礎(gr,mha),強烈建議打開,5.6就有了,很成熟了
5.7的gtid_mode可選值
ON                      完全打開GTID,如果打開狀態的備庫接受到不帶GTID的事務,則復制中斷
ON_PERMISSIVE           可以認為是打開gtid前的過渡階段,主庫在設置成該值后會產生GTID,同時備庫依然容忍帶GTID和不帶GTID的事務
OFF_PERMISSIVE          可以認為是關閉GTID前的過渡階段,主庫在設置成該值后不再生成GTID,備庫在接受到帶GTID和不帶GTID事務都可以容忍
                        主庫在關閉GTID時,執行事務會產生一個Anonymous_Gtid事件,會在備庫執行:set @@session.gtid_next='anonymous'
OFF                     徹底關閉GTID,如果關閉狀態的備庫收到帶GTID的事務,則復制中斷
之前只有ON和OFF

平滑開啟gtid
set global gtid_mode = 'off_permissive';
set global gtid_mode = 'on_permissive';
set global enforce_gtid_consistency = 'on'
set global gtid_mode = 'ON';

平滑關閉gtid
stop slave;
set global gtid_mode = 'on_permissive';
set global gtid_mode = 'off_permissive';
change master to master_auto_position = 0;
set global gtid_mode = 'OFF';
set global enforce_gtid_consistency = 'off'
start slave;

主從上都依次敲下來

Ⅳ、簡單說下搭建過程

大同小異,全備+binlog

開啟gtid后,mysqldump備份單庫時會報warning,意思是gtid包含所有事務,只備份了單庫,忽略即可

用mydumper備份,看下metadata文件,找到gitd:xxxxxx:x-xxx

這玩意等同于mysqldump備份文件中set @@global.gtid_purged='xxxx:x-xxx';

表示這部分gtids對應的事務已經在備份中了,slave在還原備份后復制時,需要跳過這些gtids

reset master;   清空@@GLOBAL.GTID_EXECUTED,不然執行下一步會報錯
SET @@GLOBAL.GTID_PURGED = '找出來的位置'
以上操作mysqldump出來的文件導入無需操作,mydumper要手動,因為myloader不執行這個

最后一把change master送給大家
change master to master_host='127.0.0.1', master_port=3306, master_user='rpl', master_password='123', MASTER_AUTO_POSITION=1;
start slave;

tips:

  • binlog文件中會有兩個關于gtid的event——Previous_gtids和Gtid
  • 通過掃描binlog中的gtid值,可以知道gtid與filename-pos的對應關系,如果binlog很大,掃描量也很大,所以用Previous_gtid來記錄之前一個binlog文件中最大的gtid
  • 如果要找的gtid比previous_gtids大,就掃描當前文件,反之掃之前的文件,依次類推
  • binlog在rotate的時候,是知道當前最大gtid的,將該值,寫入下個binlog的文件頭,即previous_gtids

Ⅴ、GTID復制中處理報錯小技巧

這里模擬一個1062錯誤即可,不演示

報錯會告訴你對應的gtid

操作步驟如下:

  • 我們將gtid_next指向報錯的gtid

報錯中沒有gtid,則用Retrieved_Gtid_Set和Executed_Gtid_Set對比一下就知道哪個事務執行出錯了

(root@localhost) [(none)]> set gtid_next='xxxxxx:xxxx';  # 設置為之前失敗的那個GTID的值
Query OK, 0 rows affected (0.00 sec)
  • 執行一個空事務
(root@localhost) [(none)]> begin;commit;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)
  • 將gtid_next還原為automatic
(root@localhost) [(none)]> set gtid_next="automatic";
Query OK, 0 rows affected (0.00 sec)

(root@localhost) [(none)]> stop slave;
Query OK, 0 rows affected (0.01 sec)
(root@localhost) [(none)]> start slave;
Query OK, 0 rows affected (0.07 sec)

該操作類似于sql_slave_skip_counter,只是跳過錯誤,不能保證數據一致性,需要人工介入,固強烈建議從機開啟read_only=1

Ⅵ、GTID的限制

  • 在開啟GTID后,不能在一個事物中使用創建臨時表的語句,需要使得 autocommit=1;才可以。5.7開始直接創建臨時表已經可以創建了
  • 在開啟GTID后,不能使用create table select ... 的語法來創建表了,因為這其實是多個事物了,GTID沒法對應
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,748評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,165評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 175,595評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,633評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,435評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,943評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,035評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,175評論 0 287
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,713評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,599評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,788評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,303評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,034評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,412評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,664評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,408評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,747評論 2 370

推薦閱讀更多精彩內容