zabbix數據庫備份整理

 

zabbix數據庫備份整理

zabbix數據庫備份整理

zabbix的所有操作都是存在數據庫裏，在數據庫裏都會有對應的表，所以對zabbix備份，只需備份數據庫就行了。

採用mysqldump進行數據庫備份如下：

mysqldump -uroot -p --opt zabbix |bzip2 > zabbix.sql.bz2

但是進行此操作時，發現備份需要很長時間，zabbix的MySQL備份文件異常龐大，查看下zabbix的數據庫表，發現mysql系統文件下zabbix目錄本身並不是很大，也就幾百行，但發下同目錄下得ibdata1文件異常龐大，達到10多個G

查看了zabbix數據庫的存儲原理，zabbix數據庫是使用的InnoDB引擎的共享空間，InnoDB把數據庫和索引都放在ibdata1下，隨着數據的增長，ibdata1會越來越大。性能方面會有影響。 

然後就很好奇zabbix爲什麼會使用innodb的共享表空間存儲數據,網上查看到一段資料寫到

—————————————————————————————-

使用過MySQL的同學，剛開始接觸最多的莫過於MyISAM表引擎了，這種引擎的數據庫會分別創建三個文件：表結構、表索引、表數據空間。我們可以將某個數據庫目錄直接遷移到其他數據庫也可以正常工作。

然而當你使用InnoDB的時候，一切都變了。InnoDB 默認會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中：ibdata1，這樣就感覺不爽，增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成爲問題。通常只能將數據使用mysqldump 導出，然後再導入解決這個問題。

在MySQL的配置文件[mysqld]部分，增加innodb_file_per_table參數，可以修改InnoDB爲獨立表空間模式，每個數據庫的每個表都會生成一個數據空間。 

獨立表空間

優點：

1.每個表都有自已獨立的表空間。

2.每個表的數據和索引都會存在自已的表空間中。

3.可以實現單表在不同的數據庫中移動。

4.空間可以回收（drop/truncate table方式操作表空間不能自動回收）

5.對於使用獨立表空間的表，不管怎麼刪除，表空間的碎片不會太嚴重的影響性能，而且還有機會處理。 

缺點：

單表增加比共享空間方式更大。 

結論：

共享表空間在Insert操作上有一些優勢，但在其它都沒獨立表空間表現好。

當啓用獨立表空間時，請合理調整一下 innodb_open_files 參數。

—————————————————————————————-

原來默認情況下innodb會將所有的數據庫InnoDB引擎的表數據存儲在一個共享空間中ibdata1,而且增刪數據庫的時候，ibdata1文件不會自動收縮，單個數據庫的備份也將成爲問題。 

所以決定將innodb的共享表空間改成獨立表空間,然後以後單獨備份zabbix數據庫時就不會備份整個數據庫文件,導致系統資源浪費,最後再做一個定期的清理zabbix歷史記錄腳本,這樣就不會擔心以後備份文件過大,導致服務器硬盤容量緊張. 

1、查看bdata1文件大小

cd /data1/mysql

du -sh *

2、登陸MySQL查看哪些表佔用了空間

# mysql -uroot -p

mysql> select table_name, (data_length+index_length)/1024/1024 as total_mb, table_rows from information_schema.tables where table_schema=‘zabbix’;

發現history表記錄已達到8個G左右，8千多萬行數據，還有history_unit也比較大，還有以下一些表也存在一些數據：

trends,trends_uint，event等等

4、做了如下操作，首先將配置表導出，zabbix數據庫中有很多的表，大體上分爲存放監控數據的表和配置的表兩種。數據表有：

alerts auditlog events historyhistory_log history_str history_str_sync history_sync history_text history_uint history_uint_sync node_cksum proxy_dhistory proxy_history service_alarms services_times trends trends_uint

其它的表便是zabbix的配置信息表：

# mysqldump -uroot -p --databases zabbix --ignore-table=zabbix.alerts --ignore-table=zabbix.auditlog --ignore-table=zabbix.events --ignore-table=zabbix.history --ignore-table=zabbix.history_log --ignore-table=zabbix.history_str --ignore-table=zabbix.history_str_sync --ignore-table=zabbix.history_sync --ignore-table=zabbix.history_text --ignore-table=zabbix.history_uint --ignore-table=zabbix.history_uint_sync --ignore-table=zabbix.node_cksum --ignore-table=zabbix.proxy_dhistory --ignore-table=zabbix.proxy_history --ignore-table=zabbix.service_alarms --ignore-table=zabbix.services_times --ignore-table=zabbix.trends --ignore-table=zabbix.trends_uint > zabbix_config.sql

# ls /data1/

lost+found  mysql  nginx  pool-content  share.d00  share.sinajs  zabbix_config.sql  

然後停止相關服務：

# /etc/init.d/zabbix_server stop

# /etc/init.d/httpd stop

登陸MySQL：

# mysql -uroot -p 

mysql > use zabbix;

mysql > truncate table history;

mysql > optimize table history;

mysql > truncate table history_str;  # 未輸入

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;

mysql > truncate table events;   # 未輸入

mysql > optimize table events;   # 未輸入\

# mysqldump -uroot -p --opt zabbix |bzip2 > zabbix.sql.bz2

?? 最後重新導入數據庫，

mysqldump -uroot -p zabbix < zabbix.sql 

然後發現之前的數據以丟失，以上方法步驟應該不對，

！！應該是先使用mysqldump導出數據，然後刪除共享表空間數據文件，再重新導入數據

參考網址：

http://www.kankanews.com/ICkengine/archives/66531.shtml

http://www.kankanews.com/ICkengine/archives/108576.shtml