数据丢失及恢复

elasticsearch

近乎实时，文档存储，搜索与分析，PB级数据。
写入原理

1. 数据写入buffer缓冲和translog
2. 每隔1s将buffer中的数据写入 segment file，并写入os cache，buffer被清空，此时就可以供search，所以说是近乎实时的
3. 重复上面写入，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"
}

集群脑裂
原因

1. 网络
2. 由于某些节点之间的网络通信出现问题，导致一些节点认为master宕机，重新选举新的master，导致信息混乱
3. 节点负载过大，停止对data节点响应

发现

1. 出现查询非常缓慢
2. 查看集群状态，如果集群状态为red
3. 较大规模的内存回收操作也能造成es进程失去响应

解决

1. 减少脑裂发生的参数设置

discovery.zen.ping_timeout(默认值是3秒)：默认情况下，一个节点会认为，如果master节点在3秒之内没有应答，那么这个节点就是死掉了，而增加这个值，会增加节点等待响应的时间，从一定程度上会减少误判。

discovery.zen.minimum_master_nodes(默认是1)：这个参数控制的是，一个节点需要看到的具有master节点资格的最小数量，然后才能在集群中做操作。官方的推荐值是(N/2)+1，其中N是具有master资格的节点的数量，节点数量最少为3

2. 给所有数据重新索引
3. 停掉所有节点并决定哪一个节点第一个启动。

redis数据丢失

1. 缓冲区内存使用过大，导致大量键被LRU淘汰。合理预留，监控内存使用大小
2. 主从复制不一致，发生故障切换后，出现数据丢失
3. 网络分区，导致短时间的写入数据丢失
4. 主库故障后自动重启，可能导致全部数据丢失，主要是重启时间低于集群或哨兵主从切换时长，而主库一般不做持久化设置，尽量不要设置redis自动重启。