展开

关键词

Hadoop集群

3.1 磁盘故障导致datanode进程down 本次(2019-05-29日)采取措施: 修改hadoop集群配置,增加datanode进程对磁盘的容错能力,磁盘容错数量设置为3. 总结: 这样既能及时发现磁盘故障,也能将磁盘故障对hadoop集群的影响降至最低。 日后正常维护: 磁盘故障报警后联系sa更换磁盘,更换完记得调整磁盘权限,然后重启datanode进程。 3.2、datanode down后,hadoop集群的容错处理 模拟datanode进程down故障,观察hadoop集群的容错处理: 首先hadoop集群不会马上认定datanode已经dead, 注:这部分请参考spark on yarn故障https://blog.csdn.net/qq_35488412/article/details/91041983 1.1 磁盘故障对yarn nodemanager 场景4部分:具体细节请参见:spark on yarn故障:https://blog.csdn.net/qq_35488412/article/details/91041983 相关资料参考: NameNode

91710

Hadoop集群日常

(二)数据备份 对于重要的数据,不能完全依赖HDFS,而是需要进行备份,注意以下几点 (1)尽量异地备份 (2)如果使用distcp备份至另一个hdfs集群,则不要使用同一版本的hadoop,避免hadoop The general command line syntax is bin/hadoop command [genericOptions] [commandOptions] 详细解释请见《hadoop hadoop-jediael-balancer-master.out 查看日志如下: [jediael@master hadoop]$ pwd /var/log/hadoop [jediael@master hadoop]$ ls hadoop-jediael-balancer-master.log  hadoop-jediael-balancer-master.out [jediael@master hadoop : 0 under utilized nodes: (2)均衡器将每个DN的使用率与整个集群的使用率接近,这个“接近”是通过-threashold参数指定的,默认是10%。

8820
  • 广告
    关闭

    【玩转 Cloud Studio】有奖调研征文,千元豪礼等你拿!

    想听听你玩转的独门秘籍,更有机械键盘、鹅厂公仔、CODING 定制公仔等你来拿!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    MongoDB集群笔记

    前面的文章介绍了MongoDB副本集和分片集群的做法,下面对MongoDB集群的日常维护操作进行小总结:         MongDB副本集故障转移功能得益于它的选举机制。 MongoDB集群最多12个副本集节点,是因为没必要一份数据复制那么多份,备份太多反而增加了网络负载和拖慢了集群性能;而最多7个节点参与选举是因为内部选举机制 节点数量太多就会导致1分钟内还选不出主节点 2)MongoDB心跳        整个MongoDB集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。 就算挂掉其中一台,只要还有存货, mongodb集群就不会挂掉。 shard,这就是传说中的分片了。 因为只有Primary才能接收Writes的操作,所以Primary在一个mongoDB的集群中是必须的。

    3.3K101

    Hadoop之NameNode重启

    /Hadoop-daemon.sh start namenode -checkpoint 3.等待30-40分钟,待checkpoint 完成后。 /hadoop-daemon.sh stop namenode ,停止second Namenode 4.修改主节点的conf 目录下的 hadoop-env.sh 文件,修改其中的JVM参数。 /hadoop-daemon.sh stop namenode,如果不成功就 kill -9 PID 6.重启NameNode . /hadoop-daemon.sh start namenode 1).加载元数据文件fsimage(~10 min) 2).加载操作日志edits(1~2 min) 3).存储元数据到fsimage( 3~4 min) 7.查看nameNode 日志,等待块汇报信息完成(10~15 min) 8.手动触发一次Full GC ,将重启过程中old区临时对象回收 9.服务正常后,发送邮件说明集群恢复正常

    12320

    Hadoop HBASE集群相关笔记 及hdfs参数设置调优等

    [toc] 本篇博客将持续更新一些遇到过的Hadoop大数据集群的问题,包括HBASE HDFS的常见问题及相关的解决方案 ## 1. HDFS ### 1.1 DataNode服务经常僵死 #### 描述 集群一共设置了8个DataNode,经常不知道什么原因会导致其中3 4 个一直处于僵死状态,重启可以恢复单身过一段时间又会有同样的问题 ### 1.3 优化Hadoop Balancer平衡的速度 Hadoop的HDFS集群在使用一段时间后,各个DataNode节点的磁盘使用率肯定会出现不平衡的情况,也就是数据量层面的数据倾斜。 如果集群中有多台RegionServer宕机的情况,小文件更是会成倍增加,恢复的过程还是会比较慢。 > >master服务启动失败原因应该是因为集群region数量较多,生产的小文件数量太多,导致处理失败。

    37331

    046.集群管理-日常

    一 Node管理 1.1 Node隔离——方式一 在硬件升级、硬件维护等情况下,我们需要将某些Node隔离,使其脱离Kubernetes集群的调度范围。 指定为当前Kubernetes集群Master的地址,最后启动这些服务。 通过kubelet默认的自动注册机制,新的Node将会自动加入现有的Kubernetes集群中。 通过这种机制,Kubernetes实现了集群中Node的扩容。 示例1:基于kubeadm部署的Kubernetes扩容Node。 [root@k8smaster01 ~]# kubectl config use-context ctx-dev #将当前运行环境设置为ctx-dev 注意:如上设置,当前的运行环境被设置为开发组所需的环境

    44210

    HBase高可用集群实践

    随着越来越多的业务选择HBase作为存储引擎,对HBase的可用性要求也越来越高,对于HBase的也提出了新的挑战。 目前集群超过30+,而且接入的业务类型繁多,对于性能要求也不完全一样,这是今年面临的问题。从15年开始,结合京东的业务情况,基于大数据平台,实现用户接入使用全流程自动化。 之前的经验,一般的做法就是stop balance,然后通过move region的方式把有影响的表移到某些机器上。 由于存在这个原因和业务的压力,往往只能采用拆分集群的方式,在一个HDFS 上往往运行几个HBase集群,但是带来的是成本的增加。 ? 最后我们把分组功能接入了BDP平台。DBA在配置实例的时候,根据业务选择不同的分组。通过rsgroup 解决拆分集群问题,可运性也得到了提升。

    77550

    Hadoop–HA抛出journalnode can not write

    Hadoop版本cdh4.3.2 异常描述 journalnode提示不能写入,后端抛异常 1.6.232:50854: error: org.apache.hadoop.hdfs.qjournal.protocol.JournalNotFormattedException : Journal Storage Directory /data/hadoop/journalnode/journaldata/jn/mycluster not formatted org.apache.hadoop.hdfs.qjournal.protocol.JournalNotFormattedException : Journal Storage Directory /data/hadoop/journalnode/journaldata/jn/mycluster not formatted         at org.apache.hadoop.hdfs.qjournal.server.Journal.checkFormatted(Journal.java:451)         at org.apache.hadoop.hdfs.qjournal.server.Journal.getEditLogManifest (RPC.java:1002)         at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1701)         at org.apache.hadoop.ipc.Server

    6820

    Ceph集群的搭建与

    >pool->pg->osd->disk 文件被分片成对象 对象存放于特定的pool pool由多个pg组成 pg对应多个osd osd直接对应disk 机器环境 4台centos7机器 默认最小集群是一个 release.asc 在admin节点部署 在admin节点安装部署工具 yum -y install ceph-deploy 创建部署文件目录 mkdir -p /etc/ceph cd /etc/ceph 创建一个集群 ceph-node2 ceph-node3 给每一个节点的keyring 增加 r 权限(各节点执行) chmod +r /ect/ceph/ceph.client.admin.keyring 检查集群状况

    12810

    400+节点的Elasticsearch集群

    截止目前我们选择了不升级集群。当然我们希望可以升级,但目前有更为紧迫的任务。实际上该如何实施升级尚未有定论,很可能选择创建另一个新的集群,而不是升级现有的。 每个月的硬件开销远大于运行在COLO中,但是云服务支持扩容集群到2倍,而几乎不用花费多少时间。 你可能会问,为何选择自己管理维护ES集群。 有了这么多的分片和节点,集群操作有时变得更特殊。比如,删除索引似乎成为集群master的能力瓶颈,它需要把集群状态信息推送给所有节点。 我们的集群状态数据约100 MB,但通过TCP压缩可减少到3 MB (可以通过curl localhost:9200/_cluster/state/_all 查看你自己集群的状态数据)。 我们必须尝试公平分享ES集群的性能测试,从下列引文就可以看出。 不幸的是,当集群宕机的时候,不到三分之一的查询能成功完成。我们相信测试本身导致了集群宕机。

    33020

    Rancher 2.2.2 发布:优化 Kubernetes 集群

    通过 UI 轮换集群证书 在 Rancher 2.2.2 中,用户通过 UI 操作即可完成集群证书轮换了! 在 Rancher 2.0 和 2.1 中,Rancher 配置集群的自动生成证书的有效期为 1 年。 这意味着如果您在大约 1 年前创建了 Rancher 配置集群,那么 1 年后需要轮换证书,否则证书过期后集群将进入错误状态。 出于稳定性考虑,暂时移除了项目级别的监控,将在下一个版本中重新添加;集群级别的监控不受此影响。 修复了发布目录模板可能因证书错误而失败的问题。 修复了 Rancher 配置集群状态在带有前缀补丁的集群中被错误提取的问题。

    33120

    400+节点的Elasticsearch集群

    截止目前我们选择了不升级集群。当然我们希望可以升级,但目前有更为紧迫的任务。实际上该如何实施升级尚未有定论,很可能选择创建另一个新的集群,而不是升级现有的。 每个月的硬件开销远大于运行在COLO中,但是云服务支持扩容集群到2倍,而几乎不用花费多少时间。 你可能会问,为何选择自己管理维护ES集群。 有了这么多的分片和节点,集群操作有时变得更特殊。比如,删除索引似乎成为集群master的能力瓶颈,它需要把集群状态信息推送给所有节点。 我们的集群状态数据约100 MB,但通过TCP压缩可减少到3 MB (可以通过curl localhost:9200/_cluster/state/_all 查看你自己集群的状态数据)。 我们必须尝试公平分享ES集群的性能测试,从下列引文就可以看出。 不幸的是,当集群宕机的时候,不到三分之一的查询能成功完成。我们相信测试本身导致了集群宕机。

    27930

    400+节点的Elasticsearch集群

    截止目前我们选择了不升级集群。当然我们希望可以升级,但目前有更为紧迫的任务。实际上该如何实施升级尚未有定论,很可能选择创建另一个新的集群,而不是升级现有的。 每个月的硬件开销远大于运行在COLO中,但是云服务支持扩容集群到2倍,而几乎不用花费多少时间。 你可能会问,为何选择自己管理维护ES集群。 有了这么多的分片和节点,集群操作有时变得更特殊。比如,删除索引似乎成为集群master的能力瓶颈,它需要把集群状态信息推送给所有节点。 我们的集群状态数据约100 MB,但通过TCP压缩可减少到3 MB(可以通过 curl localhost:9200/_cluster/state/_all 查看你自己集群的状态数据)。 我们必须尝试公平分享ES集群的性能测试,从下列引文就可以看出。 不幸的是,当集群宕机的时候,不到三分之一的查询能成功完成。我们相信测试本身导致了集群宕机。

    36160

    snova篇(四):GP集群扩容

    本节主要从集群扩容的角度,进一步了解gp集群的日常工作。 目录: 集群扩容的一般性原则 扩容规划 准备增加新节点 初始化新的segment 重分布表 ---- 基本概念: 图片.png ---- 1.集群扩容的一般性原则 弹性伸缩容量和性能 扩容期间服务不中断 回滚一个失败的扩展 gpstart -m //进入master-only模式 重启数据库 gpexpand --rollback -D database_name //执行回滚操作 5.重分布表 重分布时集群必须处于生产模式中

    67930

    利器-ClusterShell集群管理操作记录

    在运实战中,如果有若干台数据库服务器,想对这些服务器进行同等动作,比如查看它们当前的即时负载情况,查看它们的主机名,分发文件等等,这个时候该怎么办?一个个登陆服务器去操作,太傻帽了! 写个shell去执行,浪费时间~~ 这种情况下,如果集群数量不多的话,选择一个轻量级的集群管理软件就显得非常有必要了。 ClusterShell就是这样一种小的集群管理工具,原理是利用ssh,可以说是Linux系统下非常好用的利器! 很多集群管理软件都需要在所有的服务器上都安装软件,而且还要进行很多的连接操作,clustershell就相当的方便了,仅仅需要所有机器能够ssh无密码登录即可,然后只在一台服务器上安装clustershell ,等于-c --rcopy 表示从远程集群节点上拷贝文件或目录到本机上 --dest 前面表示本地要复制的文件或目录路径,后面表示远程机器的存放路径。

    1.2K70

    PostgreSQL集群篇——常用的SQL

    PostgreSQL集群篇——常用的SQL 简述 本文主要是我日常使用的一些SQL和整理于互联网上的SQL,为了方便日常的使用,特把其汇总起来,遇到常用的时将会进行补充该文,欢迎大家在评论区进行提出一些常用的

    22520

    Zookeeper集群脑裂问题 - 总结

    脑裂通常会出现在集群环境中,比如ElasticSearch、Zookeeper集群,而这些集群环境有一个统一的特点,就是它们有一个大脑,比如ElasticSearch集群中有Master节点,Zookeeper 集群中有Leader节点。 zookeeper集群有这样一个特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的。 二、 Zookeeper 集群中的"脑裂"场景说明 对于一个集群,想要提高这个集群的可用性,通常会采用多机房部署,比如现在有一个由6台zkServer所组成的一个集群,部署在了两个机房: ? 这就相当于原本一个集群,被分成了两个集群,出现了两个"大脑",这就是所谓的"脑裂"现象。

    98041

    400+节点的 Elasticsearch 集群

    截止目前我们选择了不升级集群。当然我们希望可以升级,但目前有更为紧迫的任务。实际上该如何实施升级尚未有定论,很可能选择创建另一个新的集群,而不是升级现有的。 每个月的硬件开销远大于运行在COLO中,但是云服务支持扩容集群到2倍,而几乎不用花费多少时间。 你可能会问,为何选择自己管理维护ES集群。 有了这么多的分片和节点,集群操作有时变得更特殊。比如,删除索引似乎成为集群master的能力瓶颈,它需要把集群状态信息推送给所有节点。 我们的集群状态数据约100 MB,但通过TCP压缩可减少到3 MB (可以通过 curl localhost:9200/_cluster/state/_all 查看你自己集群的状态数据)。 我们必须尝试公平分享ES集群的性能测试,从下列引文就可以看出。 不幸的是,当集群宕机的时候,不到三分之一的查询能成功完成。我们相信测试本身导致了集群宕机。

    27050

    高级架构师分享Linux 集群和自动化心得

    下面,@抚琴煮酒(余洪春)将为大家解答关于Linux集群和自动化方面的问题。 内容多多,干活多多,分享给有需要的网友们交流、学习。 【嘉宾介绍】 余洪春(抚琴煮酒),高级架构师、资深系统管理员,在电子商务领域及云计算领域工作10多年,在Linux集群、自动化、DevOPS及高并发高流量网站架构设计等方面进行了深入的研究;在大量一线实践中积累了丰富的经验 Q:集群化的云计算相比传统,所需要掌握的新技术点在哪 A:关注点不一样,比如拿AWS云平台来说,像传统,面临着安装系统、系统上架,分配机房等问题,但这些基础的活云平台都自动做了;如果想往云计算方向发展 A:Jenkins是持续集成,跟自动化是属于两个不同的方向吧。 Q:1.分布式网站系统,如何 用集群自动更新代码和同步代码(实现那种秒更新的方案?) Q:你好,我发现这本书,名称是 Linux集群和自动化

    1.4K20

    Rainbond集群的安装和的原理

    本文将解读Rainbond集群的安装和的原理,使用户基本了解Rainbond的安装机制和重点,便于用户搭建大型Rainbond集群。 SDN服务,为应用提供网络支持 node Rainbond节点控制器,提供服务守护、自动、日志收集、服务发现等服务。 节点服务 Rainbond集群安装的所有组件有两种运行方式:node组件和docker组件是直接二进制运行,其他组件全部采用容器化运行。两种运行方式都是直接采用systemd守护进程进行守护。 在集群自动化的需求下,我们需要对节点(特别是计算节点)进行实时全面的健康检查,以确认节点是否可用。 另外Rainbond安装Ansible默认使用的SSH端口是22,严格时需要设置。

    64320

    扫码关注腾讯云开发者

    领取腾讯云代金券