copying file-per-table tablespaces to another server transportable tablespace examples transportable tablespace internals
大家先來回顧一下,如果要将innodb中的一個表 moving or copying 到另外一台(machine|instance)上,如何做?
mysql enterprise backup (no need consider) copying data files (cold backup method) export and import (mysqldump,mydumper,mysqlpump)
現在我們有第四種方案
transportable tablespaces
to run reports without putting extra load on a production server to set up identical data for a table on a new slave server to restore a backed-up version of a table or partition after a problem or mistake as a faster way of moving data around than importing the results of a mysqldump command. the data is available immediately, rather than having to be re-inserted and the indexes rebuilt to move a file-per-table tablespace to a server with storage medium that better suits system requirements. for example, you may want to have busy tables on an ssd device, or large tables on a high-capacity hdd device 新備份(類似myisam的備份)
必須開啟 innodb_file_per_table 當這個表處于quiesced狀态,甚至不能被select 兩邊執行個體的page size 一緻 5.7 版本之前,不支援分區表transport 外鍵相關的表,必須設定 foreign_key_checks=0 才能成功 alter table ... import tablespace 不需要.cfg metadata file . 但是,這樣的話,mysql就不會對schema進行verificate 5.6以及更高版本,import&export 版本必須在同一個series 在replication環境中,master & slave 都必須開啟 innodb_file_per_table 對于innodb general tablespace,不支援discard & import tablespace 如果兩邊伺服器的table row_format設定的不一樣,會導緻schema mismatch error 加密過的innodb tablespace 必須要拷貝.cfp 檔案
這個例子示範了一個regular innodb table的傳輸過程
在source server a上,建立一個表
在destination server b上,也建立同樣的表結構
在destination server b上,discard 該表(這一步是必須的)
在source server a上,執行 flush tables ... for export , 該表這時候處于quiesce狀态,隻讀,且建立.cfg metadata檔案
拷貝.ibd & .cfg 從source server a 到 在destination server b
在source server a, 執行unlock tables 來釋放flush tables ... for export 加的locks
在destination server b上,導入tablespace
alter table ... discard tablespace internals
flush tables ... for export internals
unlock tables
alter table ... import tablespace
flush tables .. for export需要注意什麼
flush tables .. for export 會加鎖,這時候,千萬不能退出終端或session,否則加鎖無效且.cfg檔案自動删除。
如果沒有.cfg檔案,還能夠import成功嗎
可以,但是這樣就沒辦法認證schema了
level
code
message
warning
1810
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)
如果discard了,還能select嗎
很不幸,是不可以被select的
error 1814 (hy000): tablespace has been discarded for table 't'
discard 是什麼意思,我就不能對其做任何操作了嗎
discard的意思就是從資料庫detached,會删除ibd檔案,保留frm檔案。
也就意味着,你可以對frm檔案操作,比如:rename table,drop table ,但是不能對ibd檔案操作,比如:dml
這樣傳輸表的速度快嗎?對io負載大嗎?
這幾步中,最慢的是import,其他幾乎是瞬間完成。比較import做的事情也很多嗎,anyway,都比mysqldump要快很多很多倍。
至于io負載,當然是有的,但是還是要優于mysqlimport很多很多哇。
如果兩邊表結構不一緻,可以導入過來嗎?
很遺憾,會報錯
是以,這裡也有一個缺陷就是,如果你有ibd檔案,還不一定能夠恢複,你必須還要知道該表的表結構才行
<code>特别注意: 必須使用.cfg來幫助認證schema,否則很可能導緻mysql卡死</code>
原始表結構如下:
root:test> show create table t_2;
table
create table
t_2
create table <code>t_2</code> (
<code>id</code> int(11) default null
參考文獻
<a href="http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.html">http://dev.mysql.com/doc/refman/5.7/en/tablespace-copying.html</a>