cnamam的博客

近期因为生产上es集群出现了内存快速占用满、频繁gc、集群无响应的现象，查看集群日志和满查询日志，发现都是因为频繁gc集群无响应后出现的报错、gc高频的警告以及平时不慢的查询报文出现在慢查询日志里。看kibana的监控，发现内存几乎是在几秒内就占用满，并且满了以后，由于可用内存不足就开始频繁的full gc，cpu居高不下，集群此时基本在无法响应的状态，有遇到这种情况，只能重启才能解决，无法自己恢复，内存虽然已经占用满，但是集群日志中没有OOM的异常，而且出现的概率比较随机。由于之前没有遇到过这个问题，

elasticsearch的基本操作与常见问题增删改查新增带ID新增PUT /test20210628/_doc/1{ "name": "zhangsan"}POST /test20210628/_doc/2{ "name": "zhangsan"}不带ID新增POST /test20210628/_doc{ "name": "zhangsan"}POST 可以适用带ID及不带ID的新增，但是PUT只能用于带ID的新增修改覆盖更新PUT /test20

elasticserach备份和恢复方法es可以使用自身的快照备份，但是需要依赖es 设置快照仓库。这里我们使用第三方的elasticsearch-dump，依赖nodejs10+的环境。以下只简单描述elasticsearch-dump的简单使用方法，其他方法可以看该项目的githubhttps://github.com/elasticsearch-dump/elasticsearch-dump备份# output就是输出的备份文件，如果es没有账号密码，es账号:es密码可以不填，端口位

使用snapshot方式迁移es数据版本兼容性：快照包含索引的数据结构，所以只能还原到可以兼容索引结构的es版本在5.x中创建的索引快照可以恢复到6.x在2.x中创建的索引快照可以恢复到5.x在1.x中创建的索引快照可以恢复到2.x如果两个es版本无法兼容，但是http可以通信，可以使用reindex-from-remote方式，使用api远程reindex，但是如果数据量大，可能要比较久。源es集群中创建repository可以先记录一下当前的数据量GET /_cat/indices?