zabbix运行一段时间之后,会留下大量的历史 数据,会发现zabbix的数据库一直在增大。运行3个月后笔者的数据库达到了5.7G,可能造成系统性能下降,查看历史数据时查询速度缓慢。 zabbix里面最大的表就是历史记录的表了,网上很多人都是写全部清空这些表的数据,其实我们可以按时间来删除里面的历史记录。
今天我们的zabbix-server机器根空间不够了,我一步步排查结果发现是/var/lib/mysql/下的libdata1文件过大,已经达到了41G。我立即想到了zabbix的数据库原因,随后百度、谷歌才知道zabbix的数据库他的表模式是共享表空间模式,随着数据增长,ibdata1 越来越大,性能方面会有影响,而且innodb把数据和索引都放在ibdata1下。
作者 | Micah Lerner 译者 | 明知山 策划 | 蔡芳芳 本文对论文“Druid:一个实时分析数据存储系统”进行了概括总结,对 Druid 的架构、存储格式、查询 API 等进行了简要介绍。如需深入了解更多的细节,请查看论文原文。 这篇论文研究的是什么 Druid 是一个开源数据库,可以实现低延迟的近实时和历史数据分析。Druid 最初是由广告技术公司 MetaMarkets 开发的,后来被 Snap 收购,现在已被 Netflix、Confluent 和 Lyft 等公司应
Logstash与Elasticsearch的安装就不多说了,我之前有两篇文章写的比较详细了ElasticSearch + Logstash + Kibana 搭建笔记 和 Filebeat+Logstash+ElasticSearch+Kibana搭建Apache访问日志解析平台。
DBA经常会遇到需定期对数据进行归档和清除,可利percona的pt-archiver工具能完成这一功能,使得数据归档变得方便简单。pt-archiver可以很轻松的将生产环境的历史数据归档到文件或者直接删除,还可以不同主机间同步数据,而不用将数据落盘,实现的功能有点类似Oracle的数据泵和dblink;pt-archiver一款非常好用的数据归档及清理历史数据的工具,工作中可以起到事半功倍的效果;
操作步骤: 1.首先对mysql5.7的表数据和结构做全量备份 2.删除mysql5.7,清除log=/var/log/mysqld.log和Datadir=/var/lib/MySQL的数据,其中log、datadir的路径在/etc/my.cnf中可以找到; 3.安装数据库mysql8.0 4.数据回导,把步骤一备份的数据导入新的数据库中。
(2)删除mysql5.7,清除log=/var/log/mysqld.log和Datadir=/var/lib/MySQL的数据 依次执行:
背景: 业务发展需要,需要复用历史的表,并且通过表里面原来一个未使用的字段来区分不同的业务。 于是想到通过default来修改列的默认值: alter table A modify column biz default 'old' comment '业务标识 old-老业务, new-新业务' 现象: 上线几天之后,业务反馈旧业务的相关数据查询不到了。找后台运维查生产数据库,发现历史数据的biz字段还是null 原因: 自己在本地mysql数据库试了下,好像的确是default没法修改历史数据为null
系统版本表是SQL:2011标准中首次引入的功能。系统版本表存储所有更改的历史数据,而不仅仅是当前时刻有效的数据。举个例子,同一行数据一秒内被更改了10次,那么就会保存10份不同时间的版本数据。就像《源代码》电影里的平行世界理论一样,你可以退回任意时间里。从而有效保障你的数据是安全的,DBA手抖或程序BUG引起的数据丢失,在MariaDB10.3里已成为过去。
SELECT TABLE_NAME AS "Table", round(((data_length + index_length) / 1024 / 1024), 2) AS Size_in_MB FROM information_schema.TABLES WHERE table_schema = 'zabbix' ORDER BY Size_in_MB DESC LIMIT 10;
数据库优化有很多可以讲,按照支撑的数据量来分可以分为两个阶段:单机数据库和分库分表,前者一般可以支撑500W或者10G以内的数据,超过这个值则需要考虑分库分表。另外,一般大企业面试往往会从单机数据库问起,一步一步问到分库分表,中间会穿插很多数据库优化的问题。本文试图描述单机数据库优化的一些实践,数据库基于mysql,如有不合理的地方,欢迎指正。
随着业务的发展,当然现在比较流行的微服务无非就是业务垂直拆分+功能水平拆分,应用加节点是比较简单的,但是每个业务的单库单表扛不住了;数据库分库分表相对来说更复杂一点,但是分区表可以继续支持业务发展两三年,人手有限的情况下,我觉得分布表更合适一点。架构的终极目标是用最小的人力成本来满足就构建维护系统的需求。
Maxwell允许您将数据“引导”到流中。这将执行 select * from table和将结果输出到您的流中,从而允许您从头开始播放流来重新创建整个数据集。
Zabbix 数据库在没有使用分区分表功能,默认使用Housekeeping(管家功能)进行删除历史数据和趋势历史记录,如果zabbix数据库使用了分区分表功能需要把Housekeeping(管理功能)关闭。Housekeeping功能监控数据量少可以使用,但监控数据量多每次执行删除旧数据会降低MySQL数据库性能,并且还会产生很多空间碎片。经常会出现警报" Zabbix housekeeper processes more than 75% busy"的告警。(zabbix_server.conf配置文件两个参数进行历史记录数据删除:间隔多久删除一次,默认单位小时HousekeepingFrequency=1,一次删除多少数据,默认单位行MaxHousekeeperDelete=5000)。
《高性能MySQL》中:分区的一个主要目的是将数据按照一个较粗的粒度分在不同的表中,这样做可以将相关的数据放在一起,另外,如果想一次批量删除整个分区的数据也会变得很方便。
Making AJAX behave better in the browser 翻译:我要去桂林
Zabbix支持多种数据库引擎,你可以在MySQL,MySQL的分支,MariaDB,Oracle,PostgreSQL ,IBM DB2之中选择。以上是五大核心数据库引擎。但是此外,你也可以在历史数据存储方面利用Elasticsearch的功能。还有一个新的Timescale数据库,也是PostgreSQL类型,内置有分区的功能。
在项目中经常会遇到系统完全更换后的历史数据迁移问题,以示对客户历史工作的尊重,何况很多数据仍有保留的必要。
纪成,携程数据开发总监,负责金融数据基础组件及平台开发、数仓建设与治理相关的工作。对大数据领域开源技术框架有浓厚兴趣。
本文是对两大开源关系型数据库MySQL、PostgreSQL做了详细的对比,欢迎大家在评论区发表自己的见解。
对用户来说,分区表是一个独立的逻辑表,但是底层由多个物理子表组成。实现分区的代码实际上是对一组底层表的句柄对象的封装。
根据用户特征,重新排序热度榜,之后根据两种推荐算法计算得到的产品相关度评分,为每个热度榜中的产品推荐几个关联的产品
zabbix监控中有时会根据需要对zabbix服务器进行迁移,zabbix迁移是非常简单的,因为zabbix的前端所有的操作都存在zabbix数据库里。所以zabbix迁移只需对zabbix库中相应的表进行导出导进即可。
“增删改查”都是查找问题,因为你都得先找到数据才能对数据做操作。那存储系统性能问题,其实就是查找快慢问题。
今天有个同学问我一个问题,也是一个实际的案例,我简单分析了一下,发现还是有很多可以考究的地方。仅做参考。 问题是,系统里目前有一个大表,因为历史数据的沉淀,目前有60多亿的数据,不是分区表,现在得到反馈说insert的操作比较满,想优化一下,同时把部分历史数据需要做一些清理。 对于这类操作,要求停机时间尽可能短,有什么好的办法。 对于这个问题看起来问题似乎是很明显的。 目前反应出的问题是Insert慢,可能有下面的几个原因。 1.表索引巨大,索引维护管理要复杂一些 2.表中可能含有一些冗余索引,或者多个索引
Lambda架构设计目的在于提供一个满足大数据系统关键特性的架构。整合离线计算和实时计算,融合不可变性、读写分离和复杂性隔离等原则。
Zabbix 5.2.6 数据库共有170张表,Zabbix 数据表的名称都是复数。资源之间的关联关系是通过外键来完成的。比如host和item的关联关系,就是在items表中使用hostid与hosts表中的资源进行关联。
该文介绍了MySQL中表分区功能的使用,包括RANGE分区、LIST分区、HASH分区、KEY分区以及分区表的操作和优化。针对不同的分区类型,介绍了不同的应用场景和优缺点。同时,还提供了一些分区表SQL操作优化的建议。
在工业自动化领域,我们经常使用第三方关系数据库作为历史数据存储的容器,以备后期数据维护,历史查询,历史趋势的获取,我们常用的第三方关系数据库有:ORCALE数据库,SQL Server数据库,MYSQL数据库。
昨天处理了一个业务同学的数据需求,简单来说就是对一张大表做一下数据清理,数据量在8千万左右,需要保留近一个月的数据,大概是400万左右。
最近做一个oracle项目迁移工作,跟着spark架构师学着做,进行一些方法的总结。
升级期间,不会影响到现有的系统,系统将保持正常的运行,升级完成后,将进行一段时间的可用性测试,待系统稳定后将替换生产上的监控。
我们经常遇到一张表里面保存了上亿甚至过十亿的记录,这些表里面保存了大量的历史记录。 对于这些历史数据的清理是一个非常头疼事情,由于所有的数据都一个普通的表里。所以只能是启用一个或多个带where条件的delete语句去删除(一般where条件是时间)。 这对数据库的造成了很大压力。即使我们把这些删除了,但底层的数据文件并没有变小。面对这类问题,最有效的方法就是在使用分区表。最常见的分区方法就是按照时间进行分区。
Zabbix监控运行一段时间以后,会留下大量的历史监控数据,Zabbix数据库一直在增大;可能会造成系统性能下降,查看历史数据室查询速度缓慢。
使用起来和不分区是一样的,看起来只有一个数据库,其实有多个分区文件,比如我们要插入一条数据,不需要指定分区,MySQL会自动帮我们处理
Zabbix运维工程师,熟悉Zabbix开源监控系统的架构。乐于分享Zabbix运维经验,个人公众号“运维开发故事”。
近期也总结了几篇关于巡检的内容,很多同学也很期待,说业务巡检是一个新概念,想做成什么样子,或者说怎么样做起来更好一些。
Linux监控平台介绍 监控存在的原因 站点出了问题,没有人知道,等用户发现了,才提醒供应商;对公司影响很大 常见开源监控软件 cacti、nagios、zabbix、smokeping、open-falcon等等,其中nagios、zabbix流行度非常高 cacti、smokeping偏向于基础监控,成图非常漂亮,适合监控网络设备 cacti监控网络的设备 cacti、nagios、zabbix服务端监控中心,需要php环境支持(用Apache的php,用nginx的php都可以),其中zabbi
这几年一直是MONGODB使用者,从3.2 到4.0 ,在使用中也一直充分的感受到MONGODB 这几年的飞速的发展以及功能的扩展,偶然在极客时间里面看到有MONGODB 的 终极玩家 唐建法 老师的关于MONGODB的课,其中有一段内容以前是不大敢想的, 就是ORACLE TO MONGODB。
采用技术为:spring,springMVC,Mybatis,Activiti5,(Activiti可视化设计器基于IE,火狐,谷歌,360等浏览器),Solr4.10,Mysql,Redis,Ehcache,服务器监控模块,tk压缩,Extjs6.2 ,BootStrap,Junit单元测试,Logback,同时融入了Hessian,数据库读写分离,MQ消息中间件等技术。
最近工作中经常使用clickhouse数据库,总结了一些常用的语法,想着分享一下,大家肯定能够用到,内容有点难度,第一遍看不懂,可以收藏后面再看,欢迎收藏点赞。
TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库,结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL,支持无限的水平扩展,具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。
数据采集的设计,几乎完全取决于数据源的特性,毕竟数据源是整个大数据平台蓄水的上游,数据采集不过是获取水源的管道罢了。 在数据仓库的语境下,ETL基本上就是数据采集的代表,包括数据的提取(Extract)、转换(Transform)和加载(Load)。在转换的过程中,需要针对具体的业务场景对数据进行治理,例如进行非法数据监测与过滤、格式转换与数据规范化、数据替换、保证数据完整性等。 但是在大数据平台下,由于数据源具有更复杂的多样性,数据采集的形式也变得更加复杂而多样,当然,业务场景也可能变得迥然不同。下图展现
一种可靠的方式是 使用解压后的备份文件(必须是Xtrabackup的物理备份)来估算当前数据库的体积。 mysqldump这种逻辑备份的方式,不便于直观的比对数据库体积的增长。
随着3.4版本的发布,迎来了一大波新功能,社区特此推出#3.4版本新功能介绍及实践#专栏,一一盘点。敬请期待。
一、监控基础 1、监控处理过程 采样---->存储----->报警---->展示 (1)、采样 采样的监控数据采集方法:ssh/telnet、SNMP、Protocol v3、IPMI(智能平台管理接口)、TLS。 (2)、数据存储 数据类型:历史数据(nvps)、趋势数据。 数据存储系统:rrd(轮询数据库); SQL(关系型数据库,MySQL/PostgreSQL); NoSQL(反关系型数据库,Redis/MangoDB); 时间序列存储。 (3)、主机的四种监控接口:zbx、snmp、jmx、ipmi。 2、常用的开源监控工具 (1)、cacti:强大的【数据展示】功能。 cacti是基于php来编写的; 利用SNMP协议采集样本数据; 利用rrdtool进行数据存储; 报警机制有限。 (2)、nagios:强大的【报警机制】。 nagios不支持历史数据和趋势数据保存; 数据展示功能有限。 (3)、zabbix:集cacti、nagios优点。 强大的数据展示功能; 强大的报警机制; 支持历史数据和趋势数据的存储; 支持脚本实现故障的数据修复。 (4)、ganglia:用于集群监控。 ganglia用于集群监控时,可以实现多台主机的多种集合数据的集中展示。 二、zabbix -----------www.zabbix.com Zabbix功能特点 概述 Zabbix是一个高度集成的网络监控解决方案,一个简单的安装包中提供多样性的功能。 数据收集 可用性和性能检查 支持SNMP(包括主动轮训和被动获取),IPMI,JMX,VMware监控 自定义检查 按照自定义的间隔收集需要的数据 通过server/proxy+agents来执行 灵活的阀值定义 您可以非常灵活的定义问题阈值,称之为触发器,触发器从后端数据库获取参考值 高度可配置化的告警 可根据递增机制,接收方和媒介类型自定义发送告警通知 使用宏变量可以使告警通知更加高效有用 自动相应动作可包含远程命令 实时图表绘制 使用内置图表绘制功能可以将监控项的内容实时绘制成图表 Web监控功能 Zabbix可以追踪模拟鼠标在Web网站上的点击操作,来检查Web的功能和响应时间 丰富的可视化选项 支持创建自定义的图表,一个试图集中展现多个监控项 网络拓扑图 以仪表盘的样式自定义大屏展现和幻灯片轮询播放 报表 监控内容的高级(业务)视图 历史数据存储 数据库数据 可配置历史数据 内置数据管理机制(housekeeping) 配置简单 将被监控对象添加为主机 在数据库中获取主机进行监视 应用模板来监控设备 使用模板 在模板中分组检查 模板可以关联其他模板 网络发现 自动发现网络设备 监控代理自动注册 发现文件系统,网络接口和SNMP OID值 快捷的Web界面 PHP Web前端 可从任何地方访问 你可以定制自己的操作方式 审核日志 Zabbix API Zabbix API为Zabbix 提供了对外的可编程接口,用于批量操作,第三方软件集成和其他目的 权限管理系统 安全用户认证 特定用户可以限制访问特定的视图 功能强大,易于扩展的agent 部署在被监控对象上 支持Linux和Windows 二进制代码 为了性能和更少内存的占用,用C语言编写 便于移植 为复杂环境准备 使用Zabbix proxy代理服务器,使得远程监控更简单 结构 Zabbix由几个主要的软件组件构成,这些组件的功能如下。 Server Zabbix server 是agent程序报告系统可用性、系统完整性和统计数据的核心组件,是所有配置信息、统计信息和操作数据的核心存储器。 数据库存储 所有配置信息和Zabbix收集到的数据都被存储在数据库中。 Web界面 为了从任何地方和任何平台都可以轻松的访问Zabbix, 我们提供基于Web的Zabbix界面。该界面是Zabbix Server的一部分,通常(但不一定)跟Zabbix Server运行在同一台物理机器上。 如果使用SQLite,Zabbix Web界面必须要跟Zab
贴源层,一般来说抽取的是源系统的数据,是一个数据缓冲区,和源系统保持一致,但并不是说贴源层的数据就可原来的一模一样不变了
某医药集团信息中心数据库组组长,13 年数据库行业从业经历,Oracle OCM,关注 Oracle、MySQL、Redis、MongoDB、Oceanbase、Tidb、Polardb-X、TDSQL、CDH、Clickhouse、Doris、Databend 等多方面的关键领域技术,服务过传统通信、电力,互联网、移动互联网等行业。
写在开篇不管zabbix的后端数据库是oracle还是mysql,当zabbix监控的量级达到了一定程度后,那么对数据库的性能是一个非常严峻的挑战。特别是对历史数据的查询,将会变得非常非常的慢,别告诉我可以建索引优化,当量级达到一定的程度的时候,索引真的没啥效果了。如果再不继续寻找合适的解决方案,那么就一定会引发数据库层面的问题,最终导致服务不可用。当监控数据越来越大的时候,存储不足的时候,怎么办?那就删历史数据呗,但如果要求至少要保存半年甚至1年以上的历史数据,且又高端存储磁阵紧缺面临扩容难题的时候怎么办
领取专属 10元无门槛券
手把手带您无忧上云