MySQL 備份恢復單個innodb表

在實際環境中,時不時需要備份恢復單個或多個表(注意:這裏除非明確指定,所說的表一律指InnoDB表),而對於innodb引擎恢復單個表需要整體的恢復,xtrabackup也可以單個表恢復,只不過是用的正則過濾的,不知最新版本是否支持表空間傳輸特性。本文將要說說怎麼移動或複製部分或全部的表到另一臺服務器上,而所要用到的技術點就是transportable tablespace特性,這就意味着MySQL5.6.6以及以上版本才支持。

表空間傳輸特性允許表空間從一個實例移動到另一個實例上。這在以前版本上,這對InnoDB表空間是不可能的,因爲所有的表數據都是系統表空間的一部分。

在MySQL5.6.6以及更改版本,FLUSH TABLES ... FOR EXPORT 語法準備將InnoDB表複製到另一臺服務器,然後在另一臺服務器上執行ALTER TABLE ... DISCARD TABLESPACE 和 ALTER TABLE ... IMPORT TABLESPACE 將數據導入。將.cfg 和 .ibd 文件複製過去,用於在導入時更新表元數據,如空間ID。

使用限制和說明

  • innodb_file_per_table必須設置爲on,在 MySQL5.6.6版本默認是開啓的。居留在共享系統表空間的表不能靜默。

  • 當表靜默時,只有只讀事務被允許。

  • 當導入表空間時,頁面大小必須與導入實例的頁面大小相符合。

  • DISCARD TABLESPACE 不支持分區表,也就意味着transportable tablespaces 也不支持分區表。如果在分區表上執行ALTER TABLE ... DISCARD TABLESPACE 將會返回下面的錯誤信息:ERROR 1031 (HY000): Table storage engine for 'part' doesn't have this option.

  • 當foreign_key_checks=1時,DISCARD TABLESPACE 不支持主鍵外鍵約束關係。操作這些表時需要設置爲foreign_key_checks。

  • ALTER TABLE ... IMPORT TABLESPACE 不強制外鍵約束。如果表之間有外鍵約束,所有的表應該在同一個時間點被導出。

  • ALTER TABLE ... IMPORT TABLESPACE 導入表空間不要求.cfg元數據文件。然而在導入時缺少了.cfg文件元數據檢查就無法完成,或返回下面的信息:InnoDB: IO Read error: (2, No such file or directory) Error opening '.\test\t.cfg', will attempt to import without schema verification 1 row in set (0.00 sec) 。
    當沒有不匹配的表結構時,導入沒有.cfg文件可能會更方便。此外,在元數據不能從.ibd文件中收集的故障恢復時,導入沒有.cfg可能更有用的。

  • 導出導入的MySQL版本需要相同。否則,文件必須要在導入的服務器上創建。

  • 在複製架構中,主和從必須設置innodb_file_per_table=1。

  • windows中,文件是不區分大小寫的,而Linux和unix是區分大小寫的,在跨平臺導入導出時,需要設置lower_case_table_names=1。

將表空間複製到另一臺上

此過程將演示如何從一個運行的MySQL服務器實例上將表空間複製到另一臺上。假設源實例爲server_A,目的實例爲server_B。

  1. 在server_A上

    1

    2

    mysql> use test;

    mysql> CREATE TABLE ttlsa(id INT) engine=InnoDB;

  2. 在server_B上

    1

    2

    mysql> use test;

    mysql> CREATE TABLE ttlsa(id INT) engine=InnoDB;

  3. 在server_B上
    放棄現有的表空間。在表空間導入前,InnoDB必須丟棄已連接到接受表的表空間。

    1

    mysql> ALTER TABLE ttlsa DISCARD TABLESPACE;

  4. 在server_A上
    執行FLUSH TABLES ... FOR EXPORT語句靜默表並生成.cfg元數據文件。FLUSH TABLES ... FOR EXPORT 這個執行之後,會話不能退出,否則cfg自動消失。

    1

    2

    mysql> use test;

    mysql> FLUSH TABLES ttlsa FOR EXPORT;


    文件.cfg創建在InnoDB數據目錄。

  5. 在server_A上
    複製.ibd和.cfg文件到server_B上

    1

    shell> scp /path/to/datadir/test/ttlsa.{ibd,cfg} destination-server:/path/to/datadir/test


    文件.ibd和.cfg必須在釋放共享鎖之前複製。

  6. 在server_A上
    釋放FLUSH TABLES ... FOR EXPORT語句鎖

    1

    2

    mysql> use test;

    mysql> UNLOCK TABLES;

  7. 在server_B上
    導入表空間

    1

    2

    mysql> use test;

    mysql> ALTER TABLE ttlsa IMPORT TABLESPACE;

Transportable Tablespace 內幕

以下說明在表空間傳輸過程中的內部和錯誤日誌信息。

  1. 當在server_B上執行ALTER TABLE ... DISCARD TABLESPACE
    該表鎖定在X模式下
    表空間從該表分離

  2. 當在server_A上執行FLUSH TABLES ... FOR EXPORT
    表鎖定在共享模式下
    purge coordinator 線程停止
    髒頁被同步到磁盤上
    表元數據寫入到二進制.cfg文件中
    日誌信息如下:

    1

    2

    3

    4

    [Note] InnoDB: Sync to disk of '"test"."ttlsa"' started.

    [Note] InnoDB: Stopping purge

    [Note] InnoDB: Writing table metadata to './test/ttlsa.cfg'

    [Note] InnoDB: Table '"test"."ttlsa"' flushed to disk

  3. 當在server_A上執行UNLOCK TABLES
    二進制.cfg文件將刪除
    共享鎖將釋放,purge coordinator 線程將重啓
    日誌信息如下:

    1

    2

    [Note] InnoDB: Deleting the meta-data file './test/ttlsa.cfg'

    [Note] InnoDB: Resuming purge

  4. 當在server_B上執行ALTER TABLE ... IMPORT TABLESPACE
    每個表空間頁面將檢查損壞
    每個空間ID和日誌序號(LSN)將更新
    標誌有效的和LSN更新頭頁
    Btree頁將更新
    頁面狀態被設置爲髒將被寫入到磁盤
    日誌信息如下:

    1

    2

    3

    4

    5

    6

    [Note] InnoDB: Importing tablespace for table 'test/ttlsa' that was exported from host 'ubuntu'

    [Note] InnoDB: Phase I - Update all pages

    [Note] InnoDB: Sync to disk

    [Note] InnoDB: Sync to disk - done!

    [Note] InnoDB: Phase III - Flush changes to disk

    [Note] InnoDB: Phase IV - Flush complete

下文實際操作。理論弄清楚了,實際操作就知道是咋麼一回事了。還是那句話,死磕手冊。


轉載於:http://www.ttlsa.com/mysql/mysql-backup-recovery-innodb-table/


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