mysql Innodb表空間卸載、遷徙、裝載的應用辦法。本站提示廣大學習愛好者：（mysql Innodb表空間卸載、遷徙、裝載的應用辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql Innodb表空間卸載、遷徙、裝載的應用辦法正文
前提：
2台辦事器：A和B，須要A辦事器上的表遷徙到B辦事器。
Innodb表：sysUser，記載數：351781。
以下測試在MySQL 5.5.34中停止。
開端處置：
1：在B辦事器上樹立sysUser表，而且履行：
zjy@B : db_test 09:50:30>alter table sysUser discard tablespace;
2：把A辦事器表的表空間（ibd）復制到B辦事器的響應數據目次。
3：修正復制過去的ibd文件權限：
chown mysql:mysql sysUser.ibd
4：最初就開端加載：
zjy@B : db_test 10:00:03>alter table sysUser import tablespace;
ERROR 1030 (HY000): Got error -1 from storage engine
報錯了，檢查毛病日記：
10:05:44 InnoDB: Error: tablespace id and flags in file './db_test/sysUser.ibd' are 2428 and 0, but in the InnoDB
InnoDB: data dictionary they are 2430 and 0.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
10:05:44 InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `db_test`.`sysUser`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE
當碰到這個的情形：A辦事器上的表空間ID 為2428，而B辦事器上的表空間ID為2430。所以招致這個毛病產生，處理方法是：讓他們的表空間ID分歧，即：B找出表空間ID為2428的表（CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;），修正成和sysUser表構造一樣的的表，再import。要不就把A辦事器的表空間ID增長到年夜於等於B的表空間ID。（須要新建刪除表來增長ID）
如果A的表空間ID年夜於B的表空間ID，則會有：
11:01:45 InnoDB: Error: tablespace id and flags in file './db_test/sysUser.ibd' are 44132 and 0, but in the InnoDB
InnoDB: data dictionary they are 2436 and 0.
InnoDB: Have you moved InnoDB .ibd files around without using the
InnoDB: commands DISCARD TABLESPACE and IMPORT TABLESPACE?
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
11:01:45 InnoDB: cannot find or open in the database directory the .ibd file of
InnoDB: table `db_test`.`sysUser`
InnoDB: in ALTER TABLE ... IMPORT TABLESPACE
這時候的情形：A辦事器上的表空間ID 為44132，而B辦事器上的表空間ID為2436。（由於A是測試機子，常常做復原操作，所以表空間ID曾經很年夜了，正常情形下。表空間ID弗成能這麼年夜。
既然表空間ID纰謬招致這個毛病報出，那我們手動的讓B的表空間ID追上A的表空間ID。
須要樹立的表數目：44132-2436 = 41696個，能力追上。由於他自己就須要再樹立一個目的表，所以須要樹立的表數目為：41695。不外平安起見，最好也不要跨越41695，以防B的表空間ID跨越了A，則好比設置平安的值：41690，即便B沒有達到A表空間ID的值，也應當差不多了，可以再手動的去增長。用一個劇本跑（須要樹立的表比擬多），少的話完整可以本身手動行止理：
#!/bin/env python
# -*- encoding: utf-8 -*-
import MySQLdb
import datetime
def create_table(conn):
query = '''
create table tmp_1 (id int) engine =innodb
'''
cursor = conn.cursor()
cursor.execute(query)
conn.commit()
def drop_table(conn):
query = '''
drop table tmp_1
'''
cursor = conn.cursor()
cursor.execute(query)
conn.commit()
if __name__ == '__main__':
conn = MySQLdb.connect(host='B',user='zjy',passwd='123',db='db_test',port=3306,charset='utf8')
for i in range(41690):
print i
create_table(conn)
drop_table(conn)
也能夠開啟多線程行止理，加速效力。
當履行完以後，再從新依照下面的1-3步調停止一次，最初再裝載：
zjy@B : db_test 01:39:23>alter table sysUser import tablespace;
Query OK, 0 rows affected (0.00 sec)
如果再提醒A表空間ID年夜於B表的話，就再手動的依照劇本外面的辦法來增長ID，這時候候就只須要增長個位數便可以追上A的表空間ID了。
總結：
下面只是一個辦法，固然可以遷徙Innodb，然則出成績以後能夠會引其Innodb的頁破壞，所以最平安的照樣直接用mysqldump、xtrabackup等停止遷徙。
5.6 可以不消斟酌這些tablespace id，可以直接import 出去。
2013-11-12 15:25:09 2378 [Note] InnoDB: Sync to disk
2013-11-12 15:25:09 2378 [Note] InnoDB: Sync to disk - done!
2013-11-12 15:25:09 2378 [Note] InnoDB: Phase I - Update all pages
2013-11-12 15:25:09 2378 [Note] InnoDB: Sync to disk
2013-11-12 15:25:09 2378 [Note] InnoDB: Sync to disk - done!
2013-11-12 15:25:09 2378 [Note] InnoDB: Phase III - Flush changes to disk
2013-11-12 15:25:09 2378 [Note] InnoDB: Phase IV - Flush complete
