elasticsearch索引分片存储配置更新不成功问题

问题描述 需求描述 ES版本:5.2.2 集群节点:node_main,nodemain1,nodeleaf1,nodeleaf2 需求:因为几个集群主机上所拥有的硬盘容量大小不统一,其中nodeleaf2最大。要导入的数据量跟除了nodeleaf2之外的其他节点硬盘容量差不多,我们都知道es索引数据后,占用空间会至少是数据容量的double(由配置的索引分片数量决定)。所以希望导入的数据之索引后分片只存储在nodeleaf2节点上。 阻碍所在 按照官方的文档,先创建索引,然后设置即可,参考链接: https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-filtering.html 昨晚按照文档进行配置: 1)创建索引

2)排除分配节点

设置后导入数据是成功的,在排除掉的两个节点的data目录中对应索引文件夹,查看容量: 文件夹都是12k:

但是今天中午,排除三个节点的时候遇到了问题: 发现排除掉的三个节点,在创建索引并配置排除后,这三个被排除的节点上,对应索引文件夹大小不一样。导致导入数据也存到排除掉的三个节点上! 解决思路 排查 在排查前我的思路是: 配置的有问题 网络问题 其他 第二点的网络问题很好排查,在创建配置某索引的设置后,其他节点也会更新,并且生成文件了。 这样我觉得是我配置的问题,我又仔细的按照官网来来回回配置,并重新导入数据一个下午啊。结果还是不行。一路谷歌也不行。 饭还没做了,在准备6点的时候,想了下,去索引后存储的文件夹看看,结果发现建立索引并配置排除分配节点后,配置更新不成功的节点上,其索引存储文件夹除了“_state”文件夹还有其他文件夹(0、1、2等),然后对比了昨晚更新成功的排除节点,发现更新成功并不会存在其他文件夹(其实就是存储的索引的文件夹)。 解决方法 既然能有对比,我们创建索引后,配置排除节点后,手动删除更新不正确的节点中的索引目录下文件夹的除“_state”文件夹外的其他文件夹即可。 声明一下,这个解决办法可能会导致bug,目前暂未给ES官方提bug。本来想自己研究下问题,暂时没时间去看其源码。。。。。 1 0

Python_Map多线程的使用

很多次写脚本验证一些东西总会遇到需要多线程,目前最简单的是map。 1、单线程 含参数的情况:

无参数:

函数内部可以做你想做的,不做过多介绍. 2、多线程单参数 但是到了多线程:我们需要“并行”做一些事以便提高效率 用Map可以这样写:

以上线程数为4个线程并发。 以上传的是单个参数到并发线程函数中。 满足并发提高效率需求,棒! 3、多线程多参数 假如有这么一个需求:读取网页的信息,并统一存数据到某个文件夹中,以url作为文件名。 第2点的实例中只见传有一个参数,现在是传两个参数,一个是爬去的url,一个是文件夹路径。 可以这么写:

    0 0

Python模块:python-user-agents(解析浏览器用户代理User Agent)

user_agents提供了一个简单的方法来判断用户设备(手机、平板..)和使用什么类型的浏览器。它是基于ua-parser的。 安装:

使用:

它还提供了属性判断: is_mobile:判断是不是手机 is_tablet:判断是不是平板 is_pc:判断是不是桌面系统 is_touch_capable:有没有触屏功能 is_bot:是不是搜索引擎的爬虫 例如:

0 0

SSL Renegotiation中的Secure Renegotiation与Client-initiated Renegotiation问题

SSL Renegotiation是SSL的一个机制,主要用于对使用的加密算法、密钥进行重协商,SSL Renegotiation主要用于三个场景。 场景一:双向认证时要求客户证书。在理想情况下,服务器在第一次和客户端握手时将会要求客户端提供证书,但实际情况下,由于种种原因,客户证书仅在必要时(如重要操作等)才会被请求,所以没有在第一次握手时请求客户端证书但在后续需要提供证书时,服务器将会发起Renegotiation。 场景二:服务器使用了不同的加密算法。在某些情况下,服务器可能对不同的资源采取不同的加密算法,当客户端请求的资源被不同的算法加密保护时,服务器将会发起Renegotiation。 场景三:客户端主动发起Renegotiation。 总得来说,SSL Renegotiation是一个使用不太频繁但却在某些场景发生重大作用的一个机制,同时这个机制由于历史原因和客观原因,成为一个经常被发现存在漏洞的机制。CVE-2011-1473   SSL Renegotiation DoS和 CVE-2009-3555   SSL Renegotiation vulnerability就是SSL Renegotiation中的两个漏洞,如工作上的一个case,同事的反馈将这两个弄混了,导致在后期处理时出现了诸多不畅。 CVE-2009-3555是SSL协议设计考虑不周导致的一个漏洞,利用这个漏洞能够在受保护的TLS/SSL连接上引入信息,从而发送流量来欺骗经验证的客户端,造成中间人攻击。openssl对于CVE-2009-3555的修复方式是推出了基于RFC5746的修复方式,即Secure Renegotiation的方式。 CVE-2009-3555需要升级openssl来进行修复,openssl-0.98m之后的版本就已经修复了该漏洞,使用了Secure Renegotiation。 可以通过 openssl s_client –connect IP:port的方式来进行检查,在输出中如果存在 Secure Renegotiation IS supported则可以确认该漏洞已经修复。 CVE-2011-1473 是由于SSL协议的客观因素引起的。因为服务器在进行密钥的计算时,其消耗的计算资源是客户端的数十倍,所以如果可以允许客户端主动发起Renegotiation,那么将可以造成DoS攻击。 当然,由于计算资源对比的这一特性,即便不开启Renegotiation,客户端不断发起大量的SSL连接也会造成服务器大量的计算,同样也可以造成DoS攻击。 CVE-2011-1473的修复方式就是禁用SSL Renegotiation的Client-initiated Renegotiation。在这个漏洞的修复上,对于Apache而言,基本上所有的说法都是升级到Apache 2.2.15 及其以后集成openssl的版本,并且配置 SSLInsecureRenegotiation off选项。如某厂扫描器的报告所言: 但是在实际测试中,发现了奇怪的问题。 SSLInsecureRenegotiaton 为 on 或者 off 都不影响Client-initiated Renegotiation被关闭的结果。使用thc-ssl-dos进行测试,一直都提示 Target has disabled renegotiations。 通过查看Apache给到的官方文档(http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslinsecurerenegotiation), SSLInsecureRenegotiation只是用来打开或者关闭SecureRenegotiation,并没有说明其可以用来打开或者关闭Client-initiated Renegotiation。 同时,在stackoverflow中一个歪果仁也提出过这个问题,在回复中看到有如下回复“I […]

awk除去重复行

awk去除重复行,思路是以每一行的$0为key,创建一个hash数组,后续碰到的行,如果数组里已经有了,就不再print了,否则将其print

  0 0

python实现sift算法提取两张图片的共同特征

一、环境 1、python 2.7 (Anaconda2 64位) 2、opencv 2.4.9 点我下载 下载后,针对系统的位数将对应文件夹中的cv2.pyd拷贝到对应Anaconda的安装目录(Anaconda2\Lib\site-packages)文件夹中。 二、python实现找出两张图的共同特征

效果图如下(连接线为共同特征): 0 0

Python生成16位和32位Md5

2 1

py脚本在telnet协议下设备banner信息

通过socket去抓telnet返回的banner信息:

由于不同设备返回的echo信息(即可banner信息),暂时只考虑一下四种方式读banner信息 以下并不够处理其他情况,故可不适用。

1 0

py爬虫解决各式各样编码问题

2 0