ibdata1文件非常大，怎麽讓ibdata單獨存儲
阿新 • • 發佈：2018-03-21
ibdata1文件非常大 ibdata單獨存儲 MySQL MyISAM表引擎，會分別創建三個文件：表結構、表索引、表數據空間。可以直接把數據庫目錄移動到其他服務器運行的。
MySQL InnoDB表引擎，默認會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中：ibdata1。ibdata1文件不會自動收縮，備份也麻煩，一般使用mysqldump導出。
這種情況處理只能是是建一個新的Slave從主庫上Dump出來，然後在Dump到從庫中，動作較大。
對於InnoDB Hot Backup備份的操作（或是直接冷備），每次需要CP的文件比較大。如果現在有180G的表空間，但實際數據只有50多G，那麽我們將面對每次需要拷180G的數據。
這種方式也許mysqldump是一個好的處理方式了。
2、獨立表空間（推薦）
優點：
（1）每個表都有自已獨立的表空間。
（2）每個表的數據和索引都會存在自已的表空間中。
（3）可以實現單表在不同的數據庫中移動。
（4）空間可以回收（除drop table操作處，表空不能自已回收）
a) Drop table操作自動回收表空間，如果對於統計分析或是日值表，刪除大量數據後可以通過:alter table TableName engine=innodb;回縮不用的空間。
b) 對於使innodb-plugin的Innodb使用turncate table也會使空間收縮。
c) 對於使用獨立表空間的表，不管怎麽刪除，表空間的碎片不會太嚴重的影響性能，而且還有機會處理。
結論：
共享表空間在Insert操作上少有優勢。其它都沒獨立表空間表現好。當啟用獨立表空間時，請合理調整一 下：innodb_open_files 。
實際遇到的問題
最近發現zabbix服務器ibdata1文件很大，高達12GB。
網上查閱了zabbix的數據庫存儲原理,發現zabbix庫是使用的innodb引擎的共享表空間,innodb把數據和索引都放在ibdata1下,隨著數據增長,ibdata1會越來越大。性能方面會有影響。
原來默認情況下innodb會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中ibdata1,而且增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成為問題。
所以決定將innodb的共享表空間改成獨立表空間。
MySQL InnoDB表引擎，默認會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中：ibdata1。ibdata1文件不會自動收縮，備份也麻煩，一般使用mysqldump導出。
共享表結構和獨立表結構對比（互聯網分享）
1、共享表空間（默認）
優點：
可以放表空間分成多個文件存放到各個磁盤上（表空間文件大小不受表大小的限制，如一個表可以分布在不同步的文件上）。數據和文件放在一起方便管理。
缺點：
所有的數據和索引存放到一個文件中以為著將有一個很常大的文件，雖然可以把一個大文件分成多個小文件，但是多個表及索引在表空間中混合存儲，這樣對於一個表做了大量刪除操作後表空間中將會有大量的空隙，特別是對於統計分析，日值系統這類應用最不適合用共享表空間。
這種情況處理只能是是建一個新的Slave從主庫上Dump出來，然後在Dump到從庫中，動作較大。
對於InnoDB Hot Backup備份的操作（或是直接冷備），每次需要CP的文件比較大。如果現在有180G的表空間，但實際數據只有50多G，那麽我們將面對每次需要拷180G的數據。
這種方式也許mysqldump是一個好的處理方式了。
2、獨立表空間（推薦）
優點：
（1）每個表都有自已獨立的表空間。
（2）每個表的數據和索引都會存在自已的表空間中。
（3）可以實現單表在不同的數據庫中移動。
（4）空間可以回收（除drop table操作處，表空不能自已回收）
a) Drop table操作自動回收表空間，如果對於統計分析或是日值表，刪除大量數據後可以通過:alter table TableName engine=innodb;回縮不用的空間。
b) 對於使innodb-plugin的Innodb使用turncate table也會使空間收縮。
c) 對於使用獨立表空間的表，不管怎麽刪除，表空間的碎片不會太嚴重的影響性能，而且還有機會處理。
缺點：
單表增加過大，如超過100個G。
結論：
共享表空間在Insert操作上少有優勢。其它都沒獨立表空間表現好。當啟用獨立表空間時，請合理調整一 下：innodb_open_files 。
實際遇到的問題
最近發現zabbix服務器ibdata1文件很大，高達12GB。
網上查閱了zabbix的數據庫存儲原理,發現zabbix庫是使用的innodb引擎的共享表空間,innodb把數據和索引都放在ibdata1下,隨著數據增長,ibdata1會越來越大。性能方面會有影響。
原來默認情況下innodb會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中ibdata1,而且增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成為問題。
所以決定將innodb的共享表空間改成獨立表空間。
方法一（清空history等大表數據，然後備份數據庫、修改參數、還原數據庫）
1、查看是否開啟了獨立表空間，並且查看哪些表占用了空間
MariaDB [(none)]> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | OFF | +-----------------------+-------+ 1 row in set (0.00 sec) MariaDB [(none)]> select table_name, (data_length+index_length)/1024/1024 as total_mb, table_rows from information_schema.tables where table_schema='zabbix'; +----------------------------+---------------+------------+ | table_name | total_mb | table_rows | +----------------------------+---------------+------------+ | acknowledges | 0.06250000 | 0 | | actions | 0.04687500 | 14 | | alerts | 5.67187500 | 8314 | | application_discovery | 0.04687500 | 0 | | application_prototype | 0.04687500 | 1 | | application_template | 2.37500000 | 13963 | | applications | 1.96875000 | 14024 | | auditlog | 18.54687500 | 102648 | | auditlog_details | 0.42187500 | 1948 | | autoreg_host | 0.03125000 | 0 | | conditions | 0.03125000 | 61 | | config | 0.04687500 | 1 | | corr_condition | 0.03125000 | 0 | | corr_condition_group | 0.03125000 | 0 | | corr_condition_tag | 0.01562500 | 0 | | corr_condition_tagpair | 0.01562500 | 0 | | corr_condition_tagvalue | 0.01562500 | 0 | | corr_operation | 0.03125000 | 0 | | correlation | 0.04687500 | 0 | | dbversion | 0.01562500 | 1 | | dchecks | 0.03125000 | 1 | | dhosts | 0.03125000 | 0 | | drules | 0.04687500 | 1 | | dservices | 0.04687500 | 0 | | escalations | 0.03125000 | 154 | | event_recovery | 14.10937500 | 15170 | | event_tag | 0.03125000 | 0 | | events | 41.09375000 | 48127 | | expressions | 0.03125000 | 6 | | functions | 10.78125000 | 56183 | | globalmacro | 0.03125000 | 1 | | globalvars | 0.01562500 | 0 | | graph_discovery | 0.03125000 | 88 | | graph_theme | 0.03125000 | 2 | | graphs | 6.09375000 | 17348 | | graphs_items | 12.20312500 | 73151 | | group_discovery | 0.03125000 | 0 | | group_prototype | 0.06250000 | 7 | | groups | 0.03125000 | 19 | | history | 2138.18750000 | 20528213 | | history_log | 1.03125000 | 33 | | history_str | 1.45312500 | 4150 | | history_text | 1.03125000 | 718 | | history_uint | 3719.29687500 | 43986021 | | host_discovery | 0.04687500 | 2 | | host_inventory | 0.01562500 | 0 | | hostmacro | 0.03125000 | 0 | | hosts | 0.48437500 | 707 | | hosts_groups | 0.15625000 | 806 | | hosts_templates | 0.15625000 | 777 | | housekeeper | 0.01562500 | 204 | | httpstep | 0.03125000 | 3 | | httpstepitem | 0.04687500 | 9 | | httptest | 0.07812500 | 3 | | httptestitem | 0.04687500 | 9 | | icon_map | 0.04687500 | 0 | | icon_mapping | 0.04687500 | 0 | | ids | 0.01562500 | 43 | | images | 1.53125000 | 232 | | interface | 0.18750000 | 924 | | interface_discovery | 0.03125000 | 0 | | item_application_prototype | 0.04687500 | 1 | | item_condition | 0.21875000 | 1399 | | item_discovery | 0.75000000 | 5326 | | items | 47.15625000 | 105674 | | items_applications | 17.21875000 | 119577 | | maintenances | 0.04687500 | 0 | | maintenances_groups | 0.04687500 | 0 | | maintenances_hosts | 0.04687500 | 0 | | maintenances_windows | 0.04687500 | 0 | | mappings | 0.03125000 | 143 | | media | 0.04687500 | 15 | | media_type | 0.03125000 | 6 | | opcommand | 0.03125000 | 4 | | opcommand_grp | 0.04687500 | 0 | | opcommand_hst | 0.04687500 | 4 | | opconditions | 0.03125000 | 0 | | operations | 0.03125000 | 29 | | opgroup | 0.04687500 | 1 | | opinventory | 0.01562500 | 0 | | opmessage | 0.03125000 | 23 | | opmessage_grp | 0.04687500 | 5 | | opmessage_usr | 0.04687500 | 15 | | optemplate | 0.04687500 | 1 | | problem | 5.45312500 | 20859 | | problem_tag | 0.04687500 | 0 | | profiles | 0.35937500 | 1626 | | proxy_autoreg_host | 0.03125000 | 0 | | proxy_dhistory | 0.03125000 | 0 | | proxy_history | 0.03125000 | 0 | | regexps | 0.03125000 | 5 | | rights | 0.04687500 | 19 | | screen_user | 0.04687500 | 0 | | screen_usrgrp | 0.04687500 | 0 | | screens | 0.04687500 | 14 | | screens_items | 0.03125000 | 51 | | scripts | 0.06250000 | 3 | | service_alarms | 0.04687500 | 0 | | services | 0.03125000 | 0 | | services_links | 0.04687500 | 0 | | services_times | 0.03125000 | 0 | | sessions | 2.01562500 | 6514 | | slides | 0.04687500 | 1 | | slideshow_user | 0.04687500 | 0 | | slideshow_usrgrp | 0.04687500 | 0 | | slideshows | 0.04687500 | 1 | | sysmap_element_url | 0.03125000 | 0 | | sysmap_url | 0.03125000 | 0 | | sysmap_user | 0.04687500 | 0 | | sysmap_usrgrp | 0.04687500 | 0 | | sysmaps | 0.07812500 | 1 | | sysmaps_elements | 0.09375000 | 1 | | sysmaps_link_triggers | 0.04687500 | 0 | | sysmaps_links | 0.06250000 | 0 | | task | 0.01562500 | 0 | | task_close_problem | 0.01562500 | 0 | | timeperiods | 0.01562500 | 0 | | trends | 73.68750000 | 822417 | | trends_uint | 36.59375000 | 496174 | | trigger_depends | 0.04687500 | 65 | | trigger_discovery | 0.03125000 | 106 | | trigger_tag | 0.03125000 | 0 | | triggers | 18.31250000 | 46005 | | users | 0.03125000 | 10 | | users_groups | 0.04687500 | 11 | | usrgrp | 0.03125000 | 12 | | valuemaps | 0.03125000 | 17 | +----------------------------+---------------+------------+ 127 rows in set (12.41 sec) history（2052萬行，2.1GB）、history_unit（4300萬行，3.7G） trends（73萬行）、trends_uint（36萬行）
由於數據量太大，按照普通的方式delete數據的話基本上不太可能。決定直接采用truncate table的方式來快速清空這些表的數據，再使用mysqldump導出數據，刪除共享表空間數據文件，重新導入數據。
2、停止相關服務，避免改造時寫入數據
[root@localhost ~]# systemctl stop zabbix-server [root@localhost ~]# systemctl stop httpd
3、清空歷史數據
mysql > use zabbix;
mysql > truncate table history;
mysql > optimize table history;
mysql > truncate table history_uint;
mysql > optimize table history_uint;
mysql > truncate table trends;
mysql > optimize table trends;
mysql > truncate table trends_uint;
mysql > optimize table trends_uint;
MariaDB [(none)]> use zabbix; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed MariaDB [zabbix]> truncate table history; Query OK, 0 rows affected (0.60 sec) MariaDB [zabbix]> optimize table history; +----------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +----------------+----------+----------+-------------------------------------------------------------------+ | zabbix.history | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.history | optimize | status | OK | +----------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.33 sec) MariaDB [zabbix]> truncate table history_uint; Query OK, 0 rows affected (0.15 sec) MariaDB [zabbix]> optimize table history_uint; +---------------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------------+----------+----------+-------------------------------------------------------------------+ | zabbix.history_uint | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.history_uint | optimize | status | OK | +---------------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.15 sec) MariaDB [zabbix]> truncate table trends; Query OK, 0 rows affected (0.02 sec) MariaDB [zabbix]> optimize table trends; +---------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +---------------+----------+----------+-------------------------------------------------------------------+ | zabbix.trends | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.trends | optimize | status | OK | +---------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.01 sec) MariaDB [zabbix]> truncate table trends_uint; Query OK, 0 rows affected (0.01 sec) MariaDB [zabbix]> optimize table trends_uint; +--------------------+----------+----------+-------------------------------------------------------------------+ | Table | Op | Msg_type | Msg_text | +--------------------+----------+----------+-------------------------------------------------------------------+ | zabbix.trends_uint | optimize | note | Table does not support optimize, doing recreate + analyze instead | | zabbix.trends_uint | optimize | status | OK | +--------------------+----------+----------+-------------------------------------------------------------------+ 2 rows in set (0.02 sec)
4、備份數據
[root@localhost ~]# mysqldump -u root -p --databases zabbix |gzip>201803211714.sql.gz
5、停止數據庫
[root@localhost mysql]# systemctl stop mariadb.service
6、刪除共享表空間數據文件
[root@localhost ~]# cd /var/lib/mysql/ [root@localhost mysql]# rm -rf ibdata1 ib_logfile0 ib_logfile1
7、增加innodb_file_per_table獨立表空間參數
[root@localhost mysql]# vi /etc/my.cnf # vi /etc/my.cnf 在[mysqld]下添加一行 innodb_file_per_table=1
8、啟動MySQL
[root@localhost mysql]# systemctl start mariadb.service
9、查看參數是否生效
MariaDB [(none)]> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+-------+ 1 row in set (0.00 sec)
10、重新導入數據和確認
[root@localhost ~]# gunzip 201803211714.sql.gz [root@localhost ~]# mysql -uroot -p zabbix <201803211714.sql
數據庫目錄innodb表應該有.ibd各自的文件
備註：另外推薦使用獨立表空間的原因
從性能上對比共享表空間和獨立表空間：
共享表空間在Insert操作有優勢。其它都沒獨立表空間表現好。這裏也有一個TIPS當啟用獨立表空間時，請合理調整一下：innodb_open_files 。
從Linux系統處理上出發：
所以對於大量更新操作的系統不太適合用共享表空間
方法二（先備份數據庫、修改參數、刪除ibdata1等文件、還原數據庫）---沒試過，因為我不想要歷史數據。
1.查看是否開啟
mysql> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | OFF | +-----------------------+---
2、編輯my.cnf配置文件[mysqld]加入下面這些行
innodb_file_per_table = 1
3、備份數據庫
[root@localhost ~]# mysqldump -u root -p --databases zabbix |gzip>201803211702.sql.gz
4、停止數據庫
[root@localhost ~]# mysqladmin --host=localhost --user=root --password shutdown
5、刪除相關文件
ibdata1
ib_logfile*
6、啟動mysql服務
[root@localhost ~]# systemctl start mariadb.service
7、還原數據
[root@localhost ~]# systemctl stop zabbix-server [root@localhost ~]# gunzip 201803211702.sql.gz [root@localhost ~]# mysql -uroot -p zabbix <20180309.sql
8、驗證獨享空間是否開啟
mysql> show variables like '%per_table%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_file_per_table | ON | +-----------------------+---
ibdata1文件非常大，怎麽讓ibdata單獨存儲