可能存在的原因，仅供参考1、可以查看ES的日志elasticsearch.log2、ES中可能没有相关索引3、logstash默认不处理一天前的文件，注意文件的时间4、导入的文件的访问权限

es的叫倒排索引。词频统计的。他里面没有反转索引，你说的反向索引是oracle中有的。就是从字段最右侧开始匹配。我们一般的数据库中索引都是最左开始的。

3个节点都是好的才是绿色的。2个能用是黄色的。1个只能是红了。只是表示健康度，有点危险。不影响使用。

可以使用curlXDELETE的方式对ES中的索引进行清理。

从mysql解析归档日志到es，也算是能做到差不多一致。只是不是实时的。绝对意义上的一致不能保证。

https://blog.csdn.net/ctwy291314/article/details/82754652

最好是mysql单表映射到es里的单个index,如果多表确有关联且关联检索更高效，可以在mysql里先把多表关联做成view，再把这张视图映射到es里。

ES的字段类型不能直接改，需要使用reindex功能，其实就相当于是重建了

是的，需要的

filebeat就是个agent，分别部署在需要监控的服务器就可以了，当然需要filebeat里的配置项都指向ES/logstash的机器。