elasticsearch
近乎实时,文档存储,搜索与分析,PB级数据。
写入原理
- 数据写入buffer缓冲和translog
- 每隔1s将buffer中的数据写入 segment file,并写入os cache,buffer被清空,此时就可以供search,所以说是近乎实时的
- 重复上面写入,segment file不断增加,translog不断变大,一定时间或translog到一定大小,就发生commint,将os cache数据强制刷新到os disk,清空translog,创建新的translog。
当服务宕机了,会将translog的变更记录进行回放,重新写入buffer,刷入segment,os cache,等待translog的再次commit发生。
refresh
es接收数据请求时先存入内存中,默认每隔一秒会从内存buffer中将数据写入filesystem cache,这个过程叫做refresh;
fsync
translog会每隔5秒或者在一个变更请求完成之后执行一次fsync操作,将translog从缓存刷入磁盘,这个操作比较耗时,如果对数据一致性要求不是跟高时建议将索引改为异步,如果节点宕机时会有5秒数据丢失;
flush
es默认每隔30分钟会将filesystem cache中的数据刷入磁盘同时清空translog日志文件,这个过程叫做flush。
translog的作用就是给所有还没有flush到硬盘上的数据提供持久化记录;默认fsync到translog是每个写请求的发生后进行,为了性能,我们可以设置每次请求或一定时间进行fsync。
PUT /my_index/_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}
集群脑裂
原因
- 网络
- 由于某些节点之间的网络通信出现问题,导致一些节点认为master宕机,重新选举新的master,导致信息混乱
- 节点负载过大,停止对data节点响应
发现
- 出现查询非常缓慢
- 查看集群状态,如果集群状态为red
- 较大规模的内存回收操作也能造成es进程失去响应
解决
- 减少脑裂发生的参数设置
discovery.zen.ping_timeout(默认值是3秒):默认情况下,一个节点会认为,如果master节点在3秒之内没有应答,那么这个节点就是死掉了,而增加这个值,会增加节点等待响应的时间,从一定程度上会减少误判。
discovery.zen.minimum_master_nodes(默认是1):这个参数控制的是,一个节点需要看到的具有master节点资格的最小数量,然后才能在集群中做操作。官方的推荐值是(N/2)+1,其中N是具有master资格的节点的数量,节点数量最少为3
- 给所有数据重新索引
- 停掉所有节点并决定哪一个节点第一个启动。
redis数据丢失
- 缓冲区内存使用过大,导致大量键被LRU淘汰。合理预留,监控内存使用大小
- 主从复制不一致,发生故障切换后,出现数据丢失
- 网络分区,导致短时间的写入数据丢失
- 主库故障后自动重启,可能导致全部数据丢失,主要是重启时间低于集群或哨兵主从切换时长,而主库一般不做持久化设置,尽量不要设置redis自动重启。