5 weekend01、02、03、04、05、06、07的分布式集群的HA测试 + hdfs--动态增加节点和副本数量管理 + HA的java api访问要点

简介:

eekend01、02、03、04、05、06、07的分布式集群的HA测试

1)  weekend01、02的hdfs的HA测试

2)  weekend03、04的yarn的HA测试

 

 

1)  weekend01、02的hdfs的HA测试

首先,分布式集群都是正常的,且工作的

 

然后呢,

 

以上是,weekend01(active)、weekend02(standby)

当weekend01给kill,

变成weekend01(standby)、weekend02(active)

 

模拟weekend02断电

 

以上是weekend01(standby)、weekend02(active)

当weekend02断电后,再启动

weekend01(active)、weekend02(standby)

 

 

 

 

 

以上是weekend01(active)、weekend02(standby)

当weekend01在传文件时,weekend02杀掉namenode进程,

依然还是weekend01(active)、weekend02(standby)

 

 

 

以上是weekend01、02的hdfs的HA测试

 

下面,

 

 

 

现在,用指令来切换

 

 

这样,是告诉我们,有时候会碰到,如weekend01、02都是standby时,来命令将其中一个切换成active

 

 

 

 

2)  weekend03、04的resourcemanger的HA测试

 

 

现在,来测试

会发现,yrcrm1 变成  yrcrm2

 

只是,resourcemanger的HA仅限于此,跟hdfs的HA不一样,

如weekend01(active)在上传文件,突然中断,weekend02(standby)

 

 

 

 

对于,weekend03、04的resourcemanager的HA,

现在是,weekend03(standby)提交作业,weekend04(active)

weekend07上,共有8个yarnchild,

 

Weekend05、06、07一起,是20个yarnchild,跑作业的节点。

 

对于,weekend03、04的yarn的HA,

现在是,weekend03(standby)提交作业,weekend04(active)

现在依然还是,weekend03(standby)提交作业,weekend04(active)

 

 

以上是Weekend03、4的yarn的HA测试

 

总结:

以上是weekend01、02的hdfs的HA测试

Weekend03、4的yarn的HA测试

Weekend05、06、07是用来跑作业的,

 

 

 

关于hdfs的动态增加节点和副本数量管理,在视频里….

 暂时,不赘述。

 

 

 

 

 

说明,下面是HA的java API访问,

所以,ns1和ns2,这里,是用ns1来访问。

而我,自己当时想在weekend110里玩玩,出现了有错误。还没解决。

当然,这知识点,是要在ns1里的。

 

如果是视频里的话,则

 

 

 

 

如果是自己玩玩的话,则

 

 

 

 

Exception in thread "main" java.net.ConnectException: Call From WIN-BQOBV63OBNM/192.168.56.1 to weekend110:8020 failed on connection exception: java.net.ConnectException: Connection refused: no further information; For more details see:  http://wiki.apache.org/hadoop/ConnectionRefused

    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

    at java.lang.reflect.Constructor.newInstance(Unknown Source)

    at org.apache.hadoop.net.NetUtils.wrapWithMessage(NetUtils.java:783)

    at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:730)

    at org.apache.hadoop.ipc.Client.call(Client.java:1414)

    at org.apache.hadoop.ipc.Client.call(Client.java:1363)

    at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)

    at com.sun.proxy.$Proxy14.getFileInfo(Unknown Source)

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

    at java.lang.reflect.Method.invoke(Unknown Source)

    at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:190)

    at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:103)

    at com.sun.proxy.$Proxy14.getFileInfo(Unknown Source)

    at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getFileInfo(ClientNamenodeProtocolTranslatorPB.java:699)

    at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1762)

    at org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1124)

    at org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1120)

    at org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)

    at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1120)

    at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1398)

    at org.apache.hadoop.fs.FileUtil.checkDest(FileUtil.java:496)

    at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:348)

    at org.apache.hadoop.fs.FileUtil.copy(FileUtil.java:338)

    at org.apache.hadoop.fs.FileSystem.copyFromLocalFile(FileSystem.java:1903)

    at org.apache.hadoop.fs.FileSystem.copyFromLocalFile(FileSystem.java:1871)

    at org.apache.hadoop.fs.FileSystem.copyFromLocalFile(FileSystem.java:1836)

    at cn.itcast.hadoop.hdfs.HdfsUtilHA.main(HdfsUtilHA.java:15)

Caused by: java.net.ConnectException: Connection refused: no further information

    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)

    at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)

    at org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)

    at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:529)

    at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:493)

    at org.apache.hadoop.ipc.Client$Connection.setupConnection(Client.java:604)

    at org.apache.hadoop.ipc.Client$Connection.setupIOstreams(Client.java:699)

    at org.apache.hadoop.ipc.Client$Connection.access$2800(Client.java:367)

    at org.apache.hadoop.ipc.Client.getConnection(Client.java:1462)

    at org.apache.hadoop.ipc.Client.call(Client.java:1381)

    ... 24 more

 


本文转自大数据躺过的坑博客园博客,原文链接:http://www.cnblogs.com/zlslch/p/5902871.html,如需转载请自行联系原作者

相关文章
|
2月前
|
人工智能 监控 安全
API安全测试工具:数字经济的免疫防线
API安全面临漏洞盲区、配置错误与合规碎片三大挑战,传统手段难抵新型风险。破局需构建智能漏洞探针、配置审计中枢与合规映射引擎三位一体防御矩阵。Burp Suite、Noname Security、Traceable AI与板栗看板等工具助力企业实现自动化检测、精准响应与高效合规,打造API安全免疫体系。
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
6月前
|
缓存 监控 负载均衡
如何提升 API 性能:来自 Java 和测试开发者的优化建议
本文探讨了如何优化API响应时间,提升用户体验。通过缓存(如Redis/Memcached)、减少数据负载(REST过滤字段或GraphQL精确请求)、负载均衡(Nginx/AWS等工具)、数据压缩(Gzip/Brotli)、限流节流、监控性能(Apipost/New Relic等工具)、升级基础设施、减少第三方依赖、优化数据库查询及采用异步处理等方式,可显著提高API速度。快速响应的API不仅让用户满意,还能增强应用整体性能。
|
5月前
|
监控 测试技术 数据库连接
RunnerGo API 性能测试实战:从问题到解决的全链路剖析
API性能测试是保障软件系统稳定性与用户体验的关键环节。本文详细探讨了使用RunnerGo全栈测试平台进行API性能测试的全流程,涵盖测试计划创建、场景设计、执行分析及优化改进。通过电商平台促销活动的实际案例,展示了如何设置测试目标、选择压测模式并分析结果。针对发现的性能瓶颈,提出了代码优化、数据库调优、服务器资源配置和缓存策略等解决方案。最终,系统性能显著提升,满足高并发需求。持续关注与优化API性能,对系统稳定运行至关重要。
|
2月前
|
人工智能 自然语言处理 测试技术
AI时代,Apipost和Apifox如何利用AI技术赋能API研发测试管理所需?
在数字化转型加速背景下,API成为企业互联互通的关键。Apipost与Apifox作为主流工具,在AI赋能方面差异显著。Apipost通过智能参数命名、接口设计自动化、测试用例生成、断言自动化等功能大幅提升研发效率和质量,尤其适合中大型企业及复杂业务场景。相比之下,Apifox功能依赖手动操作较多,适用性更偏向初创或小型项目。随着AI技术发展,Apipost展现出更强的智能化与前瞻性优势,为企业提供高效、稳定的API管理解决方案,助力其在竞争激烈的市场中实现创新突破。
90 0
|
5月前
|
监控 测试技术 数据库连接
利用 RunnerGo 深度探索 API 性能测试:从理论到实践
API性能测试是保障应用稳定性和用户体验的关键环节。本文详细探讨了如何使用RunnerGo全栈测试平台进行高效API性能测试,涵盖测试计划创建、场景设计、参数配置到执行与分析全过程。通过电商平台促销活动案例,展示了高并发下的测试策略与优化措施,如代码与数据库查询优化、数据库连接池扩容、服务器资源配置调整及缓存策略实施等。最终显著提升系统性能,满足高并发需求。API性能测试需持续关注与优化,以适应业务发展和用户需求变化。
198 33
|
5月前
|
数据可视化 测试技术 API
JMeter、Apipost 与 Postman 的 API 测试对比:为什么 APIPost 是更聪明的选择
API测试如同筹备一场晚宴,选对工具至关重要。JMeter功能强大但上手难,适合专业用户;Postman简单易用,但在复杂场景和团队协作中表现有限;而Apipost则是一款智能高效的“厨房神器”。它性能测试轻松、结果清晰、学习门槛低,并且能一键集成CI/CD流程。对于追求效率与便捷的团队而言,Apipost无疑是更优选择,让API测试如同五星大厨烹饪般丝滑流畅。
|
5月前
|
存储 前端开发 数据可视化
Postman vs. Apifox 用于 API 测试全面对比
寻找一款可靠的 API 测试工具?这份对比分析将深入探讨 Postman 和 Apifox 的功能和特性。了解哪款工具最适合您的 API 测试需求。
|
5月前
|
jenkins 测试技术 Shell
利用Apipost轻松实现用户充值系统的API自动化测试
API在现代软件开发中扮演着连接不同系统与模块的关键角色,其测试的重要性日益凸显。传统API测试面临效率低、覆盖率不足及难以融入自动化工作流等问题。Apipost提供了一站式API自动化测试解决方案,支持零代码拖拽编排、全场景覆盖,并可无缝集成CI/CD流程。通过可视化界面,研发与测试人员可基于同一数据源协作,大幅提升效率。同时,Apipost支持动态数据提取、性能压测等功能,满足复杂测试需求。文档还以用户充值系统为例,详细介绍了从创建测试用例到生成报告的全流程,帮助用户快速上手并提升测试质量。
|
5月前
|
监控 安全 测试技术
选择Postman免费版还是付费版,进行 API 测试呢?
深入了解 Postman 免费版和付费版的细节,看看哪一个更适合您的 API 需求。