Run Blessed-contrib on windows

  With blessed-contrib it is easy to create terminal dashboards using ascii-art: blessed-contrib uses Braille fonts which are available by default on Linux and Mac distributions but not on Windows: In order to run such dashboards on windows you need to perform the following steps: 1. Download, open and install the FreeMono font.2. Follow these

Elasticsearch vs. Hadoop For Advanced Analytics

A Tale of Two Platforms Elasticsearch 是卓越的文档索引以及全文检索工具。其基于JSON的DSL(Domain Specific query Language)简单而又强大(我觉得比SQL还差得远,好在近期新的版本发布了Elastic SQL :),使得其成为web app中集成搜索引擎的事实上的标准。那么作为analytics 后端是否胜任呢? 我们是否真的找到了一个“Hadoop”杀手呢? 首先来回忆一下一个高级“分析”系统一般都是如何构建的。开始的时候,你的app可能只需要像“mixpanel”或者“Google Analytics”这样的功能就够了,随着系统发展,产品经理的问题变得越来越难以回答: “What's the completion rate for femail Chinese users in my newly defined cohort X through the revamped user action funnel Y?” 这一问题需要cohort X的用户数据被摄取、标记出来后,再执行自定义查询来回答。为解答此问题,你需要开始收集访问日志数据,构建一个完全的“分析流水线”。经过一番调研后你会发现,有不少已有的解决方案是构建于Hadoop基础之上的,但是越来越多的开发者开始考虑使用Elasticsearch来做这件事情。怎么会这样的?一个搜索引擎真的会适合“分析”工作么? Elasticsearch For Analytics Elastic的ELK分析套件,包括Logstash(负责搜集服务器端日志)、Kibana(可视化窗口)在web分析应用中,得到了很多应用,因为: 1. 首先你非常容易运行起一个Elasticsearch实例 2. Elasticsearch 基于JSON的查询语言比Hadoop的MapReduce要容易操作的多 3. 对于应用开发者,Elasticsearch是工具箱中的一个已有工具,而Hadoop套件可能需要他们去全新的学习 这些原因,导致那些需要快速启动、运行分析需求解决方案的,会更倾向于选择Elasticsearch。但是一个搜索引擎,用他们执行“数据摄取”、数据分析工作,比起像Hadoop这样的具备高度扩展能力的分布式数据处理平台,其表现如何呢? Streaming Ingestion(流式数据摄取) 很多团队,会被Elasticsearch

删除Oracle Undo表空间

近期处理了一次删除、重建Undo表空间的事情,有些细节还是值得记下来备忘。事情的起因是工程师需要将分布在不同ASM磁盘组里的Oracle数据库文件,迁移到新建的ASM磁盘组,操作过程中,错误的删除了Undo磁盘组的所有文件。版本 11.2.0.4, RAC环境——测试、准生产环境;下文操作不保证在“生产环境”无害。 Step 1: 考虑新建Undo Tablespace,然后修改各个实例(Instance)的Undo_Tablespace 参数,使用新的Undo,然后删除老的Undo 表空间。 Step 2: 发现,此时无法新建表空间,报错Undo表空间的数据文件不可访问。 分析:我没有去细究原因,我想原因可能有两个,1是因为使用自动Undo管理,创建表空间的操作也需要获取Undo,所以报错??2是因为新建表空间,会触发类似checkpoint之类操作,有Active Tx还需要访问Undo?? Step 3:   修改undo_management=manual,再重试之前步骤 alter system set undo_management=manual sid=‘*’; Step 4: drop tablespace undotbs1 including contents and datafiles; Step 5: drop tablespace UNDOTBS2 including contents and datafiles * ERROR at line 1: ORA-01548: active rollback segment ‘_SYSSMU1_3780397527$’ found, terminate dropping tablespace

Node.js Step 的使用

## 解决的问题 在Node.js中,绝大多数实际业务操作都是异步调用,比如文件IO,数据库操作,网络IO等等…… 当这些“耗时”操作完成后,会调用特定的操作,进行后续处理(这个后续的操作被称作callback 函数,作为之前的异步操作调用的最后一个参数)。 如果一个后台调用包含如下步骤: 1. 读取数据库,成功后, 2. 调用ERP接口,下生产订单,成功后, 3. 发送Email通知,成功后, 4. 写入数据库 这样的话,第一个调用的最后一个参数是步骤2对应的callback方法,这个方法再调用步骤3方法、再调用步骤4方法…… 整个效果,就是代码缩进后,越来越往右偏。Step就是为了解决这个问题,以一种“非嵌套”的方式,实现之前的这种调用结构。 ## 如何使用 step 库对外提供唯一的函数——Step。这个函数接受多个函数作为输入参数,这些参数对应的函数,其callback函数(*最后一个参数*)如果是 _this_,Step就会把下一个参数对应的函数,作为前一个函数调用的callback方法。 Step ( function readSelf() { fs.readFile(__filename, this); }, function capitalize(err, text) { if (err) throw err; return text.toUpperCase(); }, function showIt(err, newText) { if (err) throw err; console.log(newText); } ); 上例,第一个参数readSelf,包含一个异步调用readFile,我们在该传入callback 函数的位置,传入this。这就保证在异步操作完成后(readFile结束),Step会将读取的文件内容传递到下一个参数对应的函数(这个函数的格式像是普通的callback函数,第一个参数是err,第二个参数表示操作成功后获取的data)。本例中,第二个参数内执行的是“同步”操作,只需要直接return 结果。Step 会将结果,传递到下一个参数对应的函数showIt。

Linux 工具介绍:pidstat

# Linux工具介绍: pidstat 相较于传统、老旧的top,ps命令,pidstat能解决那些问题? 查看指定进程的stats 查看指定进程的磁盘操作(读、写)stats 查看指定进程所有线程(threads)的stats 查看每一个活动进程的CPU stats报告 获取: 进程触发了多少次 Context Switches (cs) 获取: 指定进程的内存使用、page faults 确认指定进程有无内存泄露 由上可知,pidstat提供了很多新能力,象查看进程的IO读写、内存使用等等,在分析诊断问题的时候都是关键的判断因素。 安装  不是最基础的Unix工具集成员,需要单独安装,属于 sysstat 包 ~ yum install sysstat ~ 用法: 查看指定进程的I/O stats ~ # pidstat -d -p interval count ~ ~ # pidstat -d -p 6417 2 10 ~ 6417 是我系统中OpenShift的进程ID, 2表示间隔2秒,10 表示采样10次,下面的输出显示,虽然这个进程是我系统中最消耗CPU的,但是并没有什么I/O操作。 _ ccwr: canceled writes

Linux 扩展ROOT文件系统

  Step 1: 确认磁盘分区使用 df -h Step 2: 格式化磁盘为LVM分区 fdisk /dev/sdb # 主分区 # 修改分区的系统类型为8e(Linux LVM) # 保存修改 Step 3: 创建pv(物理卷) pvcreate /dev/sdb1  pvdisplay  Step 4: 将新创建的pv添加到vg中 显示系统中已有vg vgdisplay  添加pv vgextend /dev/name-of-volume-group /dev/sdb1  Step 5: 修改root lv的大小,以占用所有分配空间 lvextend -l 100%FREE /dev/name-of-volume-group/root  确认修改 lvdisplay  Step 6: 应用修改到filesystem 查看 df -h  扩展文件系统 ext4 filesystem resize2fs /dev/name-of-volume-group/root  xfs

Aix平台查看进程打开的文件

最近刚好处理了一个Oracle数据库因为file descriptor耗尽,不能继续工作的案例。Oracle的MNL进程,打开了太多的文件,导致了这个错误。 背景: Unix中一切皆文件,socket,file… /proc 虚拟文件系统可以方便查看进程信息,包括打开的文件(fd,file descriptor) 大多数linux系统可以使用lsof来查看、使用/proc中包含的信息 Aix环境查看进程打开的文件 进入/proc/<mnl_process_pid>目录,查看fd子目录,可以查看所有打开的fd(file descriptor) # cd /proc/184422/fd# ls -l 这个文件夹下都是一些数字(fd),接下来使用相关工具,找到打开的都是什么文件 procfiles 命令 procfiles <process_pid> —— 命令使用方式 # procfiles 184422 Current rlimit: 2147483647 file descriptors    4: S_IFREG mode:0444 dev:10,5 ino:13407 uid:0 gid:0 rdev:0,0       O_RDONLY size:4811  会显示如上所示的信息,4 是 fd,文件在设备10,5上,文件系统的inode是13407下面我们来查看dev:10,5 对应哪块磁盘 # cd /dev # ls -l

ORACLE_HOME的设置与conn / as sysdba

最近发现了这一挺有意思的内容,以前没遇见过这个问题,或者遇见了,但是没有去思考、解决。 先回忆一下过程: 我是为了配置database vault,所以需要重新配置数据库的dbconsole(之前使用EM管理,但是后来EM服务器没人维护……这是另一个故事了)。 使用emca 配置dbconsole时,会要求输入ORACLE_SID 之类的,按说应该使用OS认证,完成数据库操作后,配置oc4j,一切ok……但是我操作的时候,提示我,不能连接到Oracle Instance,可能是实例未启动或者是ORACLE_HOME环境变量设置不正确——emca非常友好,还特别指出,可能ORACLE_HOME设置为以 / 符号结尾了,这样会导致emca不能连接到实例。 我查看了一下ORACLE_HOME,确实是以 / 符号结尾的(比如/oracle/app/product/11.2/),这时我并没有思考,只是简单想,有没有 / 符号,其实应该没区别的,既然emca认为不要有 / ,那我们就去除 / (如 /oracle/app/product/11.2)。 修改完环境变量后,重新运行emca,错误没有进展…… 这时有点挠头,用sqlplus / as sysdba 登陆数据库实例,检查一下哪有问题,这时候,我们发现 会显示为 connect to idle instance…… 这时我才意识到,启动Oracle Instance时的ORACLE_HOME,跟现在运行sqlplus时的ORACLE_HOME是不一样的,区别是少了一个 / 符号。这种情况下可能就没法连上实例了(这时候通过TNS连接还是可以的)。 总结一下来说,就是ORACLE_HOME设置不能以 / 结尾,否则emca没法设置。 这事有点坑人,如果是生产库,修改ORACLE_HOME,还得重启Instance…… 代价太大了。

RMAN backup copy 在DataGuard中的使用

DataGuard环境中,在Standby端,由于使用OMF的原因,在restore、recover等等操作之后,可能导致数据文件位置与Control File中记录不一致情况:1. 由于使用ASM,以及使用了不同于Primary的db_unique_name,数据文件在不同的DiskGroup位置2. ASM中的OMF文件,可能出现文件名不一致 File Size(MB) Tablespace RB segs Datafile Name ---- -------- ----------------- ------- ------------------------1    0         SYSTEM            ***     +DG1/prod/datafile/system.423.756840583 2    0         UNDOTBS1          ***     +DG1/prod/datafil/undotbs1.258.667475049 3    0         SYSAUX       

对比Kubernetes和OpenShift 2/2

6. A different approach to deployments 像前文Ingress/Router类似,OpenShift选择采用不同的方式管理部署。在Kubernetes中,有Deployment对象(您也可以在OpenShift中使用它们与所有其他Kubernetes对象一起使用)负责以滚动更新方式更新pod,并在控制器内部实现。 OpenShift有一个名为DeploymentConfig的类似对象,不是由控制器实现的,而是由基于专用pod控制整个过程的复杂逻辑实现的。它有一些缺点,但相对Kubernetes Deployment也有一个显著优势 - 你可以使用钩子(Hook)来准备你的环境以进行更新 - 例如通过更改数据库架构。这是一个很难用Deployment实现的功能(不,InitContainers不是一回事,因为它很难与许多运行的实例协调)。但是,在处理多个并发更新时,Kubernetes Deployment更好--DacementConfig根本不支持并发更新,而在Kubernetes中,您可以拥有许多并发更新,并且它将设法正确地扩展它们。 哪一个更好? OpenShift DeploymentConfig有更多选项并支持ImageStream,所以我选择它来替代传统的Kubernetes Deployment。 7. Better management of container images 这是我在Kubernetes中非常想要的,也是我个人最喜欢的OpenShift功能。 用于管理容器镜像的ImageStreams。 你知道在传统容器注册表中更改镜像的标签(Tag)有多“简单”吗? 如果没有skopeo等外部工具,您需要下载整个镜像,在本地更改并将其推回Registry。 通过更改容器标记和更新Deployment对象定义来提升应用程序也不是一种愉快的方法。 这就是我喜欢ImageStreams的原因,以下是主要原因和特点: 使用ImageStream,您可以上传一个容器镜像,然后在OpenShift内部管理它的虚拟标记(tag) - 在一个项目中,您将始终使用devel标记并仅在内部更改对它的引用,在prod上您将使用stable或prod标记并在内部管理它 在OpenShift中,不需要对注册表进行处理操作! 当使用带有DeploymentConfig的ImageStream时,您可以设置一个触发器(触发器/Hook),当新镜像出现或标签更改其引用时自动开始部署操作 - 它非常适合开发环境,其中app会在构建新版本时自行部署(无需任何CICD操作!) 使用触发器,您可以实现更多 - 当基础镜像发布新版本时,使用链式构建来创建我们的应用程序/工具的更新版本  您可以通过将镜像曝光为ImageStream来隐藏镜像本身 - 例如 jenkins指向一个原始的官方镜像,当你想要修改一些东西时,你构建自己的,将它推入你的注册表并仅需要更改ImageStream中的引用,而不是像传统的docker镜像那样部署配置 哪一个更好? OpenShift中的ImageStreams更赞! 8. Integrated CI/CD with Jenkins Red Hat在创建Kubernetes项目之前很久就创建了OpenShift,从一开始,它就是一个PaaS平台。 通过从他们的自定义解决方案(他们使用称为gears而不是容器的东西)切换到Kubernetes,更容易带来更多功能,其中最令人兴奋的是集成Jenkins。 有多种CI / CD软件解决方案,但Jenkins仍然是最大,使用最广泛,通用和成熟的解决方案。 它还经常与Kubernetes集群一起用于构建容器镜像,对它们执行持续集成任务,并将它们作为容器部署在具有Continuous