我的ceph集群中有4台服务器,16个osd,因为某些原因,集群中的数据都不要了,但是集群要保留给新的应用使用,集群现有的osd情况如下 [root@ceph-host-01 ~]# cat /etc/hosts 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1         localhost localhost.localdomain localhost6 localhost

前言 如果看到标题,你是不是第一眼觉得写错了,这个怎么可能,完全就是两个不相关的东西,最开始我也是这么想的,直到我发现真的是这样的时候,也是很意外,还是弄清楚下比较好,不然在某个操作下,也许就会出现意想不到的情况 定位 如果你看过我的博客,正好看过这篇 <<ceph在centos7下一个不容易发现的改变>> ,那么应该还记得这个讲的是centos 7 下面通过udev来实现了osd的自动挂载,这个自动挂载就是本篇需要了解的前提 [root@lab101 ~]# df -h|grep

前言 之前看过一个朋友一篇文章,讲述的是Vsan为什么使用的是两副本,而ceph则大多数情况下需要三副本,当时个人观点是这个并不是关键点,但是在仔细考虑了问题的出发点以后,这个也可以说是其中的一个点 一个集群数据丢失可以从多方面去看 发生丢失数据的事件,这个来说,出现这个事件的概率是一致的,同等硬件情况下没有谁的系统能够说在两副本情况下把这个出现坏盘概率做的比其他系统更低 发生坏盘事件以后,数据丢失波及的范围,这个就是那个朋友提出的一个观点,对于Vsan来说因为文件的不拆分,也就是在丢了的情况下

在Ceph的osd节点上,启动osd进程失败,查看其日志/var/log/ceph/ceph-osd.{osd-index}.log日志,报错如下: 2017-02-14 16:26:13.558535 7fe3883f58c0 0 filestore(/var/lib/ceph/osd/ceph-1) mount: enabling WRITEAHEAD journal mode: checkpoint is not enabled 2017-02-14 16:26:13.558712 7fe

直接上干货: ceph自动挂载原理 系统启动后,ceph 通过扫描所有磁盘及分区的 ID_PART_ENTRY_TYPE 与自己main.py中写死的osd ready 标识符来判断磁盘(及其分区)是否准备好自动挂载(journal ,block, osd 同是一个道理) main.py中记载的状态标志 /usr/lib/python2./site-packages/ceph_disk/main.py 'osd': { 'ready': '4fbd7e29-9d25-41b8-afd0-062c

正常状态:

ceph osd 批量删除,注意删除的是当前节点正在使用的osd,数据删除有风险,所以最后一步没有去format磁盘,给你留下一剂后悔药. #!/bin/bash osd_list=`mount|grep osd|awk '{print $3}'|awk -F'-' '{print $2}'` for var in $osd_list; do echo "ceph osd out $var" ceph osd out $var echo "service ceph-osd s

1  调高osd的日志等级 加上红框那一行就可以了 osd的日志路径:/var/log/ceph/ceph-osd.3.log 注意:加上了这一行后日志会刷很多,所以要特别注意日志容量的变化,以防把var目录写满了 2  缺少osdmap或者错误的osdmap 从osd日志中发现这两种错误都是属于osdmap不正常,可以从其它正常osd上拷贝osdmap到对应启动错误的osd上,假设不正常的osdmap序号是816,上图的是27601和671651 如以下图: 在一个正常osd上如osd.4上用

正常状态: 故障状态: 实施更换步骤: (1)关闭ceph集群数据迁移: osd硬盘故障,状态变为down.在经过mod osd down out interval 设定的时间间隔后,ceph将其标记为out,并开始进行数据迁移恢复.为了降低ceph进行数据恢复或scrub等操作对性能的影响,可以先将其暂时关闭,待硬盘更换完成且osd恢复后再开启: for i in noout nobackfill norecover noscrub nodeep-scrub;do ceph osd set $

前言 本篇来源于群里一个人的问题,有没有办法让ceph的磁盘不自动挂载,一般人的问题都是怎样让ceph能够自动挂载,在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的,这个我之前也写过两篇文章<ceph在centos7下一个不容易发现的改变>和<Ceph数据盘怎样实现自动挂载>,来讲述这个自动挂载的 这里讲下流程: 开机后 udev 匹配 95-ceph-osd.rules 规则,触发 ceph-disk trigger,遍历磁盘,匹配到磁盘的标记后就触

前言 这个工具我第一次看到是在填坑群里面看到,是由研发-北京-蓝星同学分享的,看到比较有趣,就写一篇相关的记录下用法 火焰图里面也可以定位内存方面的问题,那个是通过一段时间的统计,以一个汇总的方式来查看内存在哪个地方可能出了问题 本篇是另外一个工具,这个工具的好处是有很清晰的图表操作,以及基于时间线的统计,下面来看下这个工具怎么使用的 本篇对具体的内存函数的调用占用不会做更具体的分析,这里是提供一个工具的使用方法供感兴趣的研发同学来使用 环境准备 目前大多数的ceph运行在centos7系列上面

前言 前段时间看到豪迈的公众号上提到了这个离线转换工具,最近看到群里有人问,找了下没什么相关文档,就自己写了一个,供参考 实践步骤 获取代码并安装 git clone https://github.com/ceph/ceph.git cd ceph git submodule update --init --recursive ./make-dist rpm -bb ceph.spec 生成rpm安装包后进行安装,这个过程就不讲太多,根据各种文档安装上最新的版本即可,这个代码合进去时间并不久,大

前言 之前有一篇文章介绍的是,在centos7的jewel下面如果自己做的分区如何处理自动挂载的问题,当时的环境对journal的地方采取的是文件的形式处理的,这样就没有了重启后journal的磁盘偏移的问题 如果采用的是ceph自带的deploy去做分区的处理的时候,是调用的sgdisk去对磁盘做了一些处理的,然后deploy能够识别一些特殊的标记,然后去做了一些其他的工作,而自己分区的时候,是没有做这些标记的这样就可能会有其他的问题 我们看下如何在部署的时候就处理好journal的uuid的

本期内容 : Spark Streaming数据清理原理和现象 Spark Streaming数据清理代码解析 Spark Streaming一直在运行的,在计算的过程中会不断的产生RDD ,如每秒钟产生一个BachDuration同时也会产生RDD, 在这个过程中除了基本的RDD外还有累加器.广播变量等,对应Spark Streaming也有自己的对象.源数据及数据清理机制, 在运行中每个BachDuration会触发了Job ,由于会自动产生对象.数据及源数据等运行完成后肯定要自动进行回收 

Spark Streaming揭秘 Day16 数据清理机制 今天主要来讲下Spark的数据清理机制,我们都知道,Spark是运行在jvm上的,虽然jvm本身就有对象的自动回收工作,但是,如果自己不进行管理的,由于运行过程中大量产生对象,内存很快就会耗尽.我们可以认为数据清理就是SparkStreaming自己的"GC". 从DStream开始 RDD是在DStream中产生的,RDD的操作也是在DStream中进行的,所以DStream会负责RDD数据的生命周期. 在DStream中

垃圾数据清理,简单的说,就是删除不需要的那些数据,释放存储空间 最常用的就是delete命令.truncate命令,甚至是删除表空间重建,具体操作都很简单,不是本文的重点 下面,总结几个垃圾数据清理常见的几个问题 1.查找数据量最大的表 可以直接执行下面的SQL语句 select t.table_name, t.num_rows, t.blocks, t.empty_blocks from user_tables t where t.num_rows is not null order by t

Hadoop基础-HDFS数据清理过程之校验过程代码分析 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 想称为一名高级大数据开发工程师,不但需要了解hadoop内部的运行机制,还需要掌握hadoop在写入过程中的报文分析.当然代码的调试步骤是一个开发必须得会的技能!想要掌握这三个技能,我们就可以拿HDFS写入过程来练练手,了解一下平时就几行的代码在它的内部是如何帮我们实现数据传输的. 一.Idea代码调试简介 1>.编写测试代码 /* @author :yinzhengjie

好久好久没有更新博客了,之前自学的估计也都忘记差不多了.由于毕业选择从事的行业与自己的兴趣爱好完全两条路,心情也难过了很久,既然入职了就要好好干,仍要保持自己的兴趣,利用业余时间重拾之前的乐趣. 从基本的数据清理学起吧 讲一下drop函数的用法 删除表中的某一行或者某一列更明智的方法是使用drop,它不改变原有的df中的数据,而是可选择性的返回另一个dataframe来存放删除后的数据. 删除无效项 df[df.isnull()] #返回的是个true或false的Series对象(掩码对象),

原创文章,转载请注明:转载自 听风居士博客(http://www.cnblogs.com/zhouyf/) 本期内容: 一.Spark Streaming 数据清理总览 二.Spark Streaming 数据清理过程详解 三.Spark Streaming 数据清理的触发机制 Spark Streaming不像普通Spark 的应用程序,普通Spark程序运行完成后,中间数据会随着SparkContext的关闭而被销毁,而Spark Streaming一直在运行,不断计算,每一秒中在不断运行都

关于这次总结还是要从一个bug说起....... 场景描述:项目的基本处理流程为:从文件系统读取每隔一分钟上传的日志并由Spark Streaming进行计算消费,最后将结果写入InfluxDB中,然后在监控系统中进行展示,监控.这里的spark版本为2.2.1. Bug:程序开发完成之后,每个batch处理时间在15~20s左右,上线之后一直在跑,监控系统中数据也没有什么异常,sparkui中只关注了任务处理时间,其他并没有在意.后来程序运行了2天18个小时之后,监控系统发出报警NO DATA

本讲从二个方面阐述: 数据清理原因和现象 数据清理代码解析 Spark Core从技术研究的角度讲 对Spark Streaming研究的彻底,没有你搞不定的Spark应用程序. Spark Streaming一直在运行,不断计算,每一秒中在不断运行都会产生大量的累加器.广播变量,所以需要对对象及 元数据需要定期清理.每个batch duration运行时不断触发job后需要清理rdd和元数据.Clinet模式 可以看到打印的日志,从文件日志也可以看到清理日志内容. 现在要看其背后的事情: Sp