high-availability

比邻东方上云 从零开始完成压测和监控高可用体系建设

假如想象 提交于 2020-05-09 12:04:57
云栖号案例库: 【点击查看更多上云案例】 不知道怎么上云?看云栖号案例库,了解不同行业不同发展阶段的上云方案,助力你上云决策! 公司介绍 新东方教育科技集团,由1993年11月16日成立的北京新东方学校发展壮大而来,目前集团以语言培训为核心,拥有短期培训系统、基础教育系统、文化传播系统、科技产业系统、咨询服务系统等多个发展平台,是一家集教育培训、教育产品研发、教育服务等于一体的大型综合性教育科技集团。新东方教育科技集团于2006年9月7日在美国纽约证券交易所成功上市,成为中国大陆首家海外上市的教育培训机构。 比邻东方是新东方旗下独资在线外教直播公司,根据新东方23年教学体系反馈,与国际资深教材编写团队共同打造国际小学课程体系,为5~12岁中国学生量身定做国际小学3人在线外教课程。 为了响应教育部保障防控疫情期间学生“停课不停学”的号召,2020年2月,新东方快速整合集团内外优质教师资源和课程资源,面向新东方所有中小学学员推出免费的全年级全学科同步线上课程及心理课程,面向中小学生家长推出免费的家庭教育线上课程,为社会提供更多样的公益性优质学习资源,助力学生及家长在延长的假期里共同进步和成长。 业务痛点 新东方青少外教直播品牌比邻东方,2月10日晚8点开始在线选课及促销活动,预计在活动期间会有严重的流量压力。 除流量压力外,还需要保证活动期间主流程的可用性及系统的稳定性。

【云栖号案例 | 教育与科研机构】比邻东方上云 从零开始完成压测和监控高可用体系建设

冷暖自知 提交于 2020-05-07 13:25:47
云栖号案例库: 【点击查看更多上云案例】 不知道怎么上云?看云栖号案例库,了解不同行业不同发展阶段的上云方案,助力你上云决策! 公司介绍 新东方教育科技集团,由1993年11月16日成立的北京新东方学校发展壮大而来,目前集团以语言培训为核心,拥有短期培训系统、基础教育系统、文化传播系统、科技产业系统、咨询服务系统等多个发展平台,是一家集教育培训、教育产品研发、教育服务等于一体的大型综合性教育科技集团。新东方教育科技集团于2006年9月7日在美国纽约证券交易所成功上市,成为中国大陆首家海外上市的教育培训机构。 比邻东方是新东方旗下独资在线外教直播公司,根据新东方23年教学体系反馈,与国际资深教材编写团队共同打造国际小学课程体系,为5~12岁中国学生量身定做国际小学3人在线外教课程。 为了响应教育部保障防控疫情期间学生“停课不停学”的号召,2020年2月,新东方快速整合集团内外优质教师资源和课程资源,面向新东方所有中小学学员推出免费的全年级全学科同步线上课程及心理课程,面向中小学生家长推出免费的家庭教育线上课程,为社会提供更多样的公益性优质学习资源,助力学生及家长在延长的假期里共同进步和成长。 业务痛点 新东方青少外教直播品牌比邻东方,2月10日晚8点开始在线选课及促销活动,预计在活动期间会有严重的流量压力。 除流量压力外,还需要保证活动期间主流程的可用性及系统的稳定性。

ViewFs的多Replication模式:Nfly link模式

我的梦境 提交于 2020-05-05 15:35:26
文章目录 前言 Nfly link模式的由来 Nfly link实现细节分析 引用 前言 在多集群模式下,为了保证数据的一定冗余性要求,我们有时会跨集群或跨data center去备份一些重要的数据。这样可以避免某天一旦一个cluster或者data center处于不可用状态时,从而影响集群正常的数据服务。如果在不额外实现此功能代码的情况下,我们可以采用简单直接的Distcp工具来做集群间的数据拷贝。不过这种方式无法做到实时的数据replication,我们可以按照实际的使用场景做到一天同步一次或者小时级别的同步。不过本文笔者要介绍与此相关的一个重要的ViewFs的新特性:Nfly link模式。 Nfly link模式的由来 社区在JIRA HADOOP-12077:Provide a multi-URI replication Inode for ViewFs 中提出了在ViewFs模式下能够通过多uri地址的方式做跨集群的replication。而这里提到的multi-URL mount point link即Nfly模式,这里的N指的是N个data center。 在社区JIRA里,将数据冗余备份在不同的data center(cluster)里,保持high availability是一方面,可以到时出问题时应以可以做failover到下一个URI地址读写数据

Hadoop ViewFs允许hdfs schema的重载

蹲街弑〆低调 提交于 2020-05-04 19:07:07
文章目录 前言 Hadoop ViewFs的问题痛点 Hadoop ViewFs的重载hdfs schema方式 ViewFs的mount point中心化管理问题 引用 前言 在大数据时代,随着业务的迅速扩张,很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题,比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-based的功能在一定程度上能优化这块的管理。但是上述2个方案还不能完全cover住HDFS的多cluster管理的痛点问题,比如在一些用户写死在code中的地址,如何能做到纹丝不动的适配到viewfs多集群模式?本文我们来谈论谈论这个话题以及目前社区对此的解决方案。 Hadoop ViewFs的问题痛点 Hadoop ViewFs功能实现的时间可以说是非常早的了,当时最初解决的问题是在client端构建一个视图逻辑上统一的文件系统,ViewFs下不同的路径实际指向的具体的物理cluster地址。简单来说,就是我们在client端添加了一个类似mount point的映射表mapping关系。 因为是基于client side的改动,因此这会导致一个很容易出现的问题,ViewFs的重新部署更新会变得极为的麻烦,在这里面至少会涉及到如下相关服务的变更:

精尽 Kafka 学习指南【优秀学习指南汇总】

我只是一个虾纸丫 提交于 2020-04-26 08:15:16
1. 视频 炼石成金 《中间件之 Kafka》 一共有 19P 。概念部分讲的蛮细的。 尚硅谷 《大数据视频_Kafka视频教程》 一共 24P 。讲的还不错的。 书生小四 《Kafka 流处理平台》 一共 1 小时 16 分钟。简单的入门,时间也不长。 2. 书籍 《Kafka 书单整理》 宇宙级预告,厮大的 Kafka 书籍也要出了,高能预警!!!! 入门进阶的话,推荐 《Kafka 权威指南》 豆瓣评分 9 分,恐怖。 原理源码的话,推荐 《Apache Kafka 源码剖析》 豆瓣评分 8.3 分 3、个人总结优秀推荐文章 郭俊Jason 【推荐,也是炼数成金网站Kafka视频作者】 Kafka设计解析(八)- Exactly Once语义与事务机制原理 Kafka设计解析(七)- Kafka Stream Kafka设计解析(六)- Kafka高性能架构之道 Kafka设计解析(五)- Kafka性能测试方法及Benchmark报告 Kafka设计解析(四)- Kafka Consumer设计解析 Kafka设计解析(三)- Kafka High Availability (下) Kafka设计解析(二)- Kafka High Availability (上) Kafka设计解析(一)- Kafka背景及架构介绍 Kafka深度解析 厮大 《Kafka 各种文章》 【】

Replication(副本,主从模式)

对着背影说爱祢 提交于 2020-03-09 17:27:41
At the base of Redis replication (excluding the high availability features provided as an additional layer by Redis Cluster or Redis Sentinel) there is a very simple to use and configure leader follower (master-slave 主从模式) replication: it allows replica Redis instances to be exact copies of master instances. The replica will automatically reconnect to the master every time the link breaks, and will attempt to be an exact copy of it regardless of what happens to the master. This system works using three main mechanisms(主从节点之间的数据复制,有以下三种机制): When a master and a replica instances are well

rhel 7安装oracle 11gr2 rac 遇到的问题

 ̄綄美尐妖づ 提交于 2020-02-29 15:41:03
rhel7 安装11g r2 rac的方法跟之前的还是有很大的区别,以至于遇到很多坑,这里汇总下: 1、共享磁盘udev 绑定方式 这个跟rhel7 之前的版本不一样,特别是磁盘uuid命令方式变化了很多,udev启动方式也发生了变化, for disk in `ls /dev/sd*` do echo $disk /usr/lib/udev/scsi_id --whitelisted --replace-whitespace --device=$disk done 映射文件: cat /etc/udev/rules.d/99-oracle-asmdevices.rules KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", RESULT=="36000c298981418c7e8a25a89d0f836c9", SYMLINK+="asm-diskb", OWNER="grid", GROUP="asmadmin", MODE="0660" KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$parent", RESULT==

新特性解读 | MySQL 8.0.16 组复制通讯协议的设置

浪子不回头ぞ 提交于 2020-02-29 03:38:20
原创作者: 管长龙 标签:Group Communication System, Group Replication, High Availability 背景 在上一篇推文中,我们介绍了 MySQL Group Replication 8.0.16 支持信息碎片化功能来增强大型事务处理能力。 如果您想在组复制中使用该功能,则任何组成员的版本都不能低于 8.0.16! 简单地说就是由于低版本协议上不支持。MySQL 8.0.16 的组通讯开始支持新协议,简称**“分段协议” ,之前的版本中只有一种 “压缩协议”**。 如果多个成员想加入复制组,那么在协议匹配上遵循以下原则: 现有复制组成员和新加入成员版本相同,加入成功。 低版本成员想加入高版本的组会被驱逐,加入失败。 高版本的成员想加入低版本的组,单独加入成功,多个加入失败。 例如: 一个 MySQL Server 8.0.16 实例可以成功加入使用通信协议版本 5.7.24 的组。 一个 MySQL Server 5.7.24 实例无法成功加入使用通信协议版本 8.0.16 的组。 两个 MySQL Server 8.0.16 实例无法同时加入使用通信协议版本 5.7.24 的组。 两个 MySQL Server 8.0.16 实例可以同时加入使用通信协议版本 8.0.16 的组。 新增 UDF

CM6.3 High Availability

[亡魂溺海] 提交于 2020-02-26 00:53:29
HDFS High Availability YARN High Availability HBase High Availability Most aspects of HBase are highly available in a standard configuration. A cluster typically consists of one Master and three or more RegionServers, with data stored in HDFS. To ensure that every component is highly available, configure one or more backup Masters. The backup Masters run on other hosts than the active Master. Enabling HBase High Availability Using Cloudera Manager Go to the HBase service. Follow the process for adding a role instance and add a backup Master to a different host than the one on which the active

Normalize or Denormalize in high traffic websites

浪子不回头ぞ 提交于 2020-01-22 05:30:50
问题 What are the best practices for database design and normalization for high traffic websites like stackoverflow? Should one use a normalized database for record keeping or a normalized technique or a combination of both? Is it sensible to design a normalized database as the main database for record keeping to reduce redundancy and at the same time maintain another denormalized form of the database for fast searching? or Should the main database be denormalized but with normalized views at the