zabbix数据量大如何备份数据库

最新推荐文章于 2024-05-28 09:56:05 发布
VIP文章 最新推荐文章于 2024-05-28 09:56:05 发布
阅读量1k 收藏 4
点赞数
分类专栏： linux 文章标签： linux zabbix mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/david3ddafsd/article/details/107046594
版权

zabbix数据数据量大如何备份

由于线上zabbix的数据较大，data目录将近1.7T的数据，但这些数据主要都是一些历史数据

查看zabbix的各个表的大小：

mysql -uzabbix -p
MariaDB [zabbix]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| zabbix             |
+--------------------+
2 rows in set (0.000 sec)

MariaDB [zabbix]> SELECT TABLE_NAME,DATA_LENGTH,INDEX_LENGTH,(DATA_LENGTH+INDEX_LENGTH) as length,TABLE_ROWS,concat(round((DATA_LENGTH+INDEX_LENGTH)/1024/1024,3), 'MB') as total_size FROM information_schema.TABLES WHERE TABLE_SCHEMA='zabbix' order by length desc;
+----------------------------+--------------+--------------+--------------+------------+--------------+
| TABLE_NAME                 | DATA_LENGTH  | INDEX_LENGTH | length       | TABLE_ROWS | total_size   |
+----------------------------+--------------+--------------+--------------+------------+--------------+
| history_uint               | 314004586496 | 219262763008 | 533267349504 | 5157074500 | 508563.375MB |
| history                    | 236318736384 | 170171023360 | 406489759744 | 3919360397 | 387658.844MB |
| history_text               | 383274565632 |   7263895552 | 390538461184 |  252181395 | 372446.500MB |
| trends_uint                | 142742749184 |            0 | 142742749184 | 1630448517 | 136130.094MB |
| trends                     |  83559415808 |            0 |  83559415808 |  967417853 | 79688.469MB  |
| history_log                |  16248700928 |    386727936 |  16635428864 |   13777815 | 15864.781MB  |
| alerts                     |   2275393536 |    510099456 |   2785492992 |    2071400 | 2656.453MB   |
| history_str                |   1230585856 |    729366528 |   1959952384 |   19407623 | 1869.156MB   |
| sessions                   |    270532608 |    325058560 |    595591168 |    3507460 | 568.000MB    |
| auditlog                   |    278724608 |    169197568 |    447922176 |    3584870 | 427.172MB    |
| events                     |    171655168 |    116768768 |    288423936 |    1380775 | 275.063MB    |
| items                      |     79282176 |     60014592 |    139296768 |     301355 | 132.844MB    |
| housekeeper                |     89784320 |            0 |     89784320 |    1658125 | 85.625MB     |
| event_recovery             |     39927808 |     30474240 |     70402048 |     728272 | 67.141MB     |
| items_applications         |     26689536 |     31293440 |     57982976 |     361339 | 55.297MB     |
| triggers                   |     35192832 |     14172160 |     49364992 |     180716 | 47.078MB     |
| item_discovery             |     22593536 |     18841600 |     41435136 |     210868 | 39.516MB     |
| item_rtdata                |     31965184 |            0 |     31965184 |     321620 | 30.484MB     |
| problem                    |     20496384 |     11059200 |     31555584 |      85546 | 30.094MB     |
| functions                  |     11026432 |     17891328 |     28917760 |     185402 | 27.578MB     |
| graphs                     |      7880704 |      8454144 |     16334848 |      50587 | 15.578MB     |
| graphs_items               |      8929280 |      7372800 |     16302080 |     114126 | 15.547MB     |
| trigger_discovery          |      7864320 |      4702208 |     12566528 |     136780 | 11.984MB     |
| item_preproc               |      6832128 |      3653632 |     10485760 |      86456 | 10.000MB     |
| application_template       |      1572864 |      2998272 |      4571136 |      24629 | 4.359MB      |
| event_tag                  |      2637824 |      1589248 |      4227072 |      34345 | 4.031MB      |
| auditlog_details           |      3686400 |       442368 |      4128768 |      15647 | 3.938MB      |
| graph_discovery            |      2588672 |      1490944 |      4079616 |      36381 | 3.891MB      |
| applications               |      1589248 |      1589248 |      3178496 |      26506 | 3.031MB      |
| images                     |      1589248 |        16384 |      1605632 |        138 | 1.531MB      |
| profiles                   |       524288 |       606208 |      1130496 |       5014 | 1.078MB      |
| hosts                      |       409600 |       540672 |       950272 |       2024 | 0.906MB      |
| widget_field               |       278528 |       524288 |       802816 |       3068 | 0.766MB      |
| hosts_templates            |       311296 |       376832 |       688128 |       5401 | 0.656MB      |
| autoreg_host               |       327680 |       262144 |       589824 |       2880 | 0.563MB      |
| item_condition             |       360448 |       114688 |       475136 |       3916 | 0.453MB      |
| interface                  |       212992 |       262144 |       475136 |       2090 | 0.453MB      |
| hosts_groups               |       131072 |       196608 |       327680 |       2171 | 0.313MB      |
| hostmacro                  |       131072 |       114688 |       245760 |       1422 | 0.234MB      |
| trigger_depends            |        98304 |       131072 |       229376 |       1340 | 0.219MB      |
| problem_tag                |       114688 |        98304 |       212992 |       1426 | 0.203MB      |
| actions                    |       131072 |        32768 |       163840 |        103 | 0.156MB      |
| opmessage                  |       114688 |        16384 |       131072 |        251 | 0.125MB      |
| items_part1                |        16384 |        98304 |       114688 |         52 | 0.109MB      |
| escalations                |        65536 |        49152 |       114688 |        407 | 0.109MB      |
| sysmaps_elements           |        16384 |        81920 |        98304 |          2 | 0.094MB      |
| httptest                   |        16384 |        65536 |        81920 |         22 | 0.078MB      |
| media                      |        49152 |        32768 |        81920 |        193 | 0.078MB      |
| sysmaps                    |        16384 |        65536 |        81920 |          0 | 0.078MB      |
| rights                     |        49152 |        32768 |        81920 |        382 | 0.078MB      |
| mappings                   |        65536 |        16384 |        81920 |        707 | 0.078MB      |
| lld_macro_path             |        49152 |        16384 |        65536 |        276 | 0.063MB      |
| users                      |        49152 |        16384 |        65536 |        106 | 0.063MB      |
| scripts                    |        16384 |        49152 |        65536 |          3 | 0.063MB      |
| event_suppress             |        16384 |        49152 |
最低0.47元/天 解锁文章
DavidIans
关注
  • 0
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
运维之道 | Zabbix使用shell脚本定期自动化清理数据库历史数据
01-07
前言 zabbix运行一段时间之后，会留下大量的历史数据，会发现zabbix的数据库一直在增大。运行3个月后笔者的数据库达到了5G，可能造成系统性能下降，查看历史数据时查询速度缓慢。 zabbix里面最大的表就是历史记录的表了，网上很多人都是写全部清空这些表的数据，其实我们可以按时间来删除里面的历史记录。 一、查看数据库中zabbix的存储 1、登录数据库 [root@zabbix ~]# mysql -uroot -p 2、查看数据库zabbix库中的存储 MariaDB [(none)]> show databases; +--------------------+ | Databas
zabbix进行数据库备份以及表分区的方法
01-20
由于测试环境上面使用的zabbix服务器配置比较低，经常会遇到性能瓶颈（主要是数据库和磁盘I/O等），于是倒逼我使用了一些方式来缓解这些问题。 主要是以前使用的那个备份数据库的脚本是对zabbix数据库进行全备的，使用的又是mysql自带的工具mysqldump，当数据量大了之后进行全备所花的时间比较长，这样将会造成数据库的锁读。。。从而使zabbix服务以为mysql死掉了，产生一大堆的报警。 后来发现原来造成数据库数据量大量增加的是zabbix数据库中的一些存储数据的大表导致的。于是备份数据库的时候可以选择跳过这些表进行备份，这样，将大大减少数据库备份所花的时间（PS：之前备份数据库所花
zabbix数据库备份和Zabbix的高可用
NancyLCL的博客
09-28 814
1. Zabbix的高可用问题：对于一个监控系统都存在的一个问题就是知网来盗控自己，如果当身发生成周会导致全部监控实效，并且也无法发送报警消息。这就需要实现Zabbix系统的高可用，至少在监控系统出现故障时能够及时发送报警消息。1. 备份Zabbix数据库可以防止数据库因意外损坏而导致所有的配置数据丢失，备份的目的是灾难恢复。这里选择对单表备份，而非全部备份。排除以下的表（原因是这几个表的数据为监控的历史展示数据，非配置类数据）。
Zabbix的history相关数据表数据太大，执行表分区操作过程
苦苦的潜行者
07-02 1502
转载自 https://www.cnblogs.com/sunshine-long/p/12121434.html 一、查询zabbix数据库大小 mysql> select table_schema, concat(truncate(sum(data_length)/1024/1024,2),' mb') as data_size,concat(truncate(sum(index_length)/1024/1024,2),'mb') as index_size from infor..
zabbix数据库history相关数据占用空间太大解决
zhaixing
11-26 6456
zabbix数据库history相关数据占用空间太大解决 今天有台服务器磁盘报警，使用du -sh * （当前文件夹下的文件大小）一步步排查，发现/var/lib/mysql/zabbix/这个目录占用磁盘空间较大 [root@localhost mysql]# pwd /var/lib/mysql [root@localhost mysql]# du -sh zabbix 5.9G zabbix 在进入到zabbix中，进一步看到是其中history_uint.ibd和history.ibd两个表的数据
zabbix数据库备份
weixin_33720452的博客
01-12 132
zabbix前端的所有操作都是存在数据库里的，在数据库里都会有对应的表，所以对zabbix备份，只需备份zabbix数据库就行了。使用最广泛的备份方法还是使用mysqldump。一：全库备份[root@zhu1 ~]# mysqldump -uroot -p123456 --opt zabbix | bzip2 > zabbix.sql.bz2 [root@zhu1 ~...
Zabbix-Server数据库mysql的libdata1 mysqllog文件过大
weixin_34032779的博客
06-06 364
今天我们的zabbix-server机器上线半年时间，占用了500G空间，我一步步排查结果发现是/var/lib/mysql/下的libdata1文件过大，已经达到了300G。我立即想到了zabbix的数据库原因，zabbix的数据库他的表模式是共享表空间模式，随着数据增长，ibdata1 越来越大，性能方面会有影响，而且innodb把数据和索引都放在ibda...
zabbix优化记一次惨痛的zabbix数据库优化
weixin_33909059的博客
06-19 1112
最近负责公司的zabbix项目，由于前期缺少整体性能架构的规划,导致后期出一系列的问题，玩zabbix的兄弟都知道，zabbix最大的瓶颈本身不在zabbix服务，而在mysql数据库的压力上，因此，优化zabbix其实就是优化zabbix的配置以及zabbix的mysql了;Zabbix 数据库常见的优化处理方法有两种：01. 优化数据库,对数据库进行分表处理;02. 清空...
zabbix数据库占用磁盘空间较大的处理方法
weixin_30399821的博客
11-07 1950
du -h /* |sort -nr 使用此命令一步步排查发现/var/lib/mysql/zabbix/这个目录占用磁盘空间较大 发现history_log.ibd这个文件最大，达到了38G，此文件对应的是zabbix库里的history_log表 找到问题原因后就好解决，进入zabbix，删除history_log表较早的数据即可 进入MySQL的zabbix库 delete fro...
zabbix server扩容改造方案之一
02-12
中涉及数据库读写的部分，包括zabbixserver和webapi，都需要重写，好在大 部分可以参考已有的代码。 本方案设计基于zabbix3.0.10版本。本文只论及对zabbixserver的改造方 案，对webapi的修改方案将另文讨论，本文不...
zabbix.js:zabbix API客户端
05-07
当前存在一个错误，当Zabbix的数据库关闭时，客户端将崩溃。 这是因为Zabbix从API返回HTML页面，而不是返回正确的JSONRPC API错误响应。 我已经在Zabbix票证跟踪器上创建了一个票证，直到它被修复为止，我将实现一...
MassMailer:C＃Windows服务，用于发送大量电子邮件
05-14
结构邮件系统由两个主要部分组成：一个用于以一组存储过程的形式存储邮件任务，模板，数据，历史记录，DB API的数据库，以及一个执行发送，DKIM字母签名和记录结果的服务部分。数据库主数据库表是ActiveQueue表-它...
ZABBIX历史记录占用磁盘过大清理方法
weixin_43674090的博客
08-15 5235
ZABBIX历史记录占用磁盘过大清理方法
Zabbix数据备份和恢复
zhouzhijin1990的专栏
04-21 1261
zabbix维护数据备份和恢复
027.Zabbix的定期备份
weixin_30915275的博客
11-15 235
一 数据库备份及恢复 1.1：全库备份 1 [root@zabbix01 ~]# mysqldump -uroot -p123456 --opt zabbix > zabbix.sql 2 [root@zabbix01 ~]# scp zabbix.sql root@192.168.1.206:/tmp 注意：若数据库过大，建议采用bzip2压缩进行备份。 ...
zabbix数据库备份脚本及导入数据库
weixin_34185512的博客
03-10 739
#!/bin/bash#sadoc.blog.51cto.com#备份zabbix数据库,不备份监控历史数据HOST=127.0.0.1SQL_PORT=3306SQL_USER=zabbixSQL_PASS=123456DATABASE_NAME=zabbixDUMP_PATH=/backup/mysql_backupDATE=$(date '+%Y-%m-%d:%H:%M...
利用zabbix监控mysqldump定时备份数据库是否成功 乐维君
qq_40907977的博客
04-02 759
转载来源 ： 利用zabbix监控mysqldump定时备份数据库是否成功 ： https://www.jianshu.com/p/a8a23fb704c3 场景需求 大部分企业都会存在测试数据库。然而，这些公司的运维人员普遍的做法是编写一个shell脚本通过mysqldump，这个mysql数据库备份工具结合linux的crontab这个定时任务命令，实现每周或者每月对数据库进行备份,如果不监...
linux 之dma_buf (4)- mmap
最新发布
z20230508的博客
05-28 603
前面几篇都是在 kernel space 对 dma-buf 进行访问的，本篇我们将一起来学习，如何在 user space 访问 dma-buf。当然，user space 访问 dma-buf 也属于 CPU Access 的一种。
zabbix数据库可以用hadoop备份吗
03-27
是的，Zabbix数据库可以使用Hadoop进行备份。Hadoop是一个分布式的大数据处理框架，可以对大量数据进行存储和处理。备份Zabbix数据库到Hadoop集群中可以提高备份的可靠性和容错性。可以使用Hadoop的分布式文件系统...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值